App private keys should use longer derivation paths

[kantai]

App private keys should use a longer derivation path to take advantage of all the bits of entropy in the SHA256 hash: (see https://github.com/blockstack/blockstack-browser/blob/master/app/js/utils/account-utils.js#L55)

This PR hirosystems/stacks.js#433 adds a function which will generate such a lengthened key, and it includes a function for generating the old derivation as well (using the hashCode function).

To address this in a backwards compatible fashion, we should:

1. On authentication with multi-player apps, check whether an entry already exists for the app (and uses the legacy derived app key), and if so, use the legacy path, otherwise use the new path.
2. On authentication with single-player apps, check whether the app is in a whitelisted set of legacy apps (use the current set of single-player apps in the browser as the whitelist) and if so, use the legacy path, otherwise use the new path.

[kantai]

This is implemented in feature/long-app-derivation-paths -- depends on the wallet feature branch of blockstack.js.

[kantai]

After discussing this with @shea256, there's another approach we could take -- which is roughly:

1. Instead of using a non-secret salt, we can use a salt which is something like ECDSA_SIGN(private_key = appsNode, message = "app-salt"). This prevents malicious discovery of a collision, because that would require access to the salt (which they would not be able to find without the appsNode key).
2. To guard against accidental collision, we can increase the derivation path by an additional index.

The above strategy doesn't change the backwards-compatibility issues or required migration strategy, but it would result in a shorter derivation path (meaning a faster key derivation).

Thoughts -- @jcnelson @larrysalibra ?

[larrysalibra]

The above strategy doesn't change the backwards-compatibility issues or required migration strategy, but it would result in a shorter derivation path (meaning a faster key derivation).

This sounds good to me.

Faster key derivation is a big plus for mobile.

[jcnelson]

I'm in favor of the longer derivation path by default. I think we have determined that derivation performance is a non-issue.

[kantai]

I'm in favor of the longer derivation path by default.

Me too -- this is from a bias towards "a new cryptographic technique is bad by default"

I think we have determined that derivation performance is a non-issue.

I don't feel comfortable making that conclusion yet, but would tend towards saying it's not a problem. I set up a "benchmarker" (emphasis on the quotes, there) at (https://aaron.blankstein.com/test.html) -- if you load that page it will use blockstack.js to generate an app private key using the full SHA256 derivation path and tell you how many ms it takes to compute. On an iPhone 8, it took ~200 ms (page takes much longer to load because it downloads blockstack.js).

[jcnelson]

but would tend towards saying it's not a problem

That's what I meant :) We could easily add a "loading..." dialog on the sign-in page, or do the key derivation once the user is presented with the login dialog (so it occurs before the user clicks "sign-in"), etc.

On an iPhone 8, it took ~200 ms (page takes much longer to load because it downloads blockstack.js).

On my Pixel 2 XL, it took 693 ms. On my laptop, it took 340 ms.