Quote from: gmaxwell on September 04, 2013, 11:21:30 PM

The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property. In some use-cases it could easily cause a total loss. E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.

Quote from: Crowex on September 10, 2013, 04:17:47 PM

I'm probably missing something here, but if I wanted to allow auditing of any branch without worrying about knowledge of a private key compromising other addresses can't I just generate another key pair, x,X, and derive all public addresses for that branch by using the group operation (i.e. point addition) on any public key K derived on that branch by defining the public addresses as X+K (here +is point addition) for all addresses generated on that branch. That way I could give away individual private keys x+k (and the extended key for generating K (and auditor easily generates X+K) without compromising any other private keys.
Why couldn't you do this for each branch adding extra protection against loss of the master extended key? Is it because of the extra key management? Or have I missed something?

In BIP32, say you have a master public key (Kpar, Cpar) which has an associated private key (kpar, cpar).

You derive a child private key (number i) through non-prime derivation using:

Code:

1) (L, R) = HMAC( Cpar, Kpar || i )
2) ki = L + kpar (mod n)
3) return (ki, R)

Looking at equation 2) you notice that the L component can be computed if you know (Kpar, Cpar). So, knowing any derived private key ki and the master public key Kpar completely leaks kpar:

Code:

kpar = ki - L (mod n)

Essentially, this means that if you gave M/i' to an auditor and you additionally give him m/i'/0 then you are essentially leaking m/i' and any keys derived from it.

plaprade

Posts

Merits