mimblewimble / grin-wallet

Grin Wallet
Apache License 2.0
182 stars 133 forks source link

Consider hardened BIP-32 derivation paths #78

Open lehnberg opened 5 years ago

lehnberg commented 5 years ago

What is the reason for Grin not using hardened derivation paths? Is it worth adding?

Context

lehnberg @lehnberg Mar 14 09:28 https://github.com/mimblewimble/grin/issues/2674#issuecomment-472541745 @mcdallas writes:

Let me remind you that we use bip32 HD wallets WITHOUT a hardened derivation path and leaking a single private key can lead to the whole chain being compromised. From BIP32:

One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts. I wasn’t aware that the BIP-32 support was done without hardened derivation paths. Does anyone remember the rationale for that? Simpler?

David Burkett @DavidBurkett Mar 14 15:06 Yea, I called this out in the past. Not sure why we do that, since we don’t offer public/view key functionality in the standard grin wallet.

lehnberg commented 5 years ago

@yeastplume just realised perhaps this issue better belongs in grin-wallet these days. Feel free moving if so, can't seem to do it myself.

yeastplume commented 5 years ago

Reason is either something to do with paths as stored in bulletproofs or nothing at all, I need to look into it again to remind myself (and will do)

mcdallas commented 5 years ago

We currently use m/account/0/index derivation path. As I understand this proposes to use m/account'/0'/index which eliminates the private key leak problem. One caveat would be that we won't be able to do watch only wallets for the whole tree in the future, only on an account basis. Also a wallet restore might become more expensive because it will have to check both hardened and non hardened paths for backwards compatibility.

DavidBurkett commented 5 years ago

@mcdallas That's not really how restores work - at least not at the moment. What you're saying about checking both paths is true of bitcoin, but not Grin. Currently, the master seed is hashed with the commitment to come up with the 'nonce' used to generate the bulletproof. Anyone with that nonce can 'rewind' the bulletproof to get both the path and the blinding factor (although having both seems excessive - really only one is needed). So you can use completely random paths, and it won't affect restore time.