Support hardened keys. - Githubissues

MicahZoltu commented 6 years ago

MetaMask uses BIP32 HD keys, which means a single root seed phrase can result in many wallets. Unfortunately, it calls deriveChild(i) where i is a small number which means the additional keys it generates are not hardened. A non-hardened key (as I understand it) is one that could be associated with other un-hardened keys correlated with the account. This means if someone knows one of your MetaMask accounts, they can correlate it with your other MetaMask accounts.

I recommend adding a way for users to derive hardened keys. Using the current library, this is done by passing in a very large number for i to deriveChild(i). You can see the hdkey library for details.

GriffGreen commented 6 years ago

Yes, from what i understand, there might be a false sense of privacy.... that if a send is made from the root address, the public key can be found and that can be linked to all other accounts generated by the public key... so if i have 20 accounts on metamask, effectively they can all be linked... this is unnecessary and can be fixed with a small change to this library.

I would love to see that happen.

Would not using the root address at all be enough to avoid this privacy leak? Talking with my buddy Polto, I assume that is how it is done now... the master pub key is just never exposed to the network?

MicahZoltu commented 4 years ago

Worth noting that my understanding above was incorrect. You still need a shareable secret from the keyholder to link un-hardened accounts.

seresistvanandras commented 4 years ago

Thanks for the clarification, Micah! Although this does not hold anymore, if the group is pairing-friendly. In that case one could easily deduct whether two derived child public keys belong to the same root public key or not (assuming that they were derived in a non-hardened way). Let's assume that we have $\mathbb{G}$ , a pairing friendly group and a symmetric pairing $e(\mathbb{G},\mathbb{G})\rightarrow \mathbb{G}_T$ . Let $g \land g_T$ be the generators of the corresponding groups.

Furthermore let's assume that the root public key is $Q=g^{sk}$ and we have two public keys (e.g. obtained from two different transactions) $Q_1=g^{sk+h_{1}}$ and $Q_2=g^{sk+h_{2}}$ , where $h_{i}=hash(i,Q)$ for the sake of brevity. From these two public keys we can also obtain the following auxiliary variables: $g^{h_1-h_2},g^{h_2-h_1}$ using the available group operation in $\mathbb{G}$ .

Then we can decide whether the public keys belong to the same root public key WITHOUT knowing the root public key. We need to calculate the following 3 pairings: $e(g^{sk+h_1},g^{h_2-h_1})=g_{T}^{sk\cdot h_2+h_1 \cdot h_2 -h^{2}_1-sk\cdot h_1}$

$e(g^{sk+h_2},g^{h_1-h_2})=g_{T}^{sk\cdot h_1+h_1 \cdot h_2 -h^{2}_2-sk\cdot h_2}$

$e(g^{h_1-h_2},g^{h_2-h_1})=g_{T}^{2\cdot h_1\cdot h_2-h^{2}_2-h^{2}_1 }$

If we denote the results of the previous pairings in the target group as A,B and C correspondingly, then we just need to check whether: $A\cdot B\cdot C^{-1}=1_{T}$

Clearly this relation for two randomly chosen addresses would hold with negligible probability.

Do you have any insights @MicahZoltu how this would affect ZCash privacy model, or whether this linkage is relevant for ZCash or not? Do they use non-hardened key derivation?

MicahZoltu commented 4 years ago

ZCash's privacy system is not rooted in HD Wallets, it is quite different (uses zkSNARKs IIRC).

If you believe that you have a mechanism for associating two public keys from an HD Wallet without an extended key then you should probably bring that up with some cryptographic experts (certainly above my pay grade). https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security indicates that such a thing should not be possible and being able to do that would mean having cracked the HD Wallet's security guarantees.

seresistvanandras commented 4 years ago

You're certainly right, although this simple trick would allow one to nullify the privacy benefits of zkSNARKs by allowing them to link t- and/or z-addresses, if they were generated using non-hardened key derivation.

I think in the original BIP they did not have in mind a pairing-friendly group. The added capabilities of a pairing changes the picture significantly (if my calculation above was correct).

seresistvanandras commented 4 years ago

Sean Bowe (@ebfull) has just clarified to me that "the curve we use for keying material in zcash is not pairing-friendly"

MetaMask / eth-hd-keyring

Support hardened keys. #9