Understanding BIP 32: private derivation and public keys

Sarchar

member

Activity: 88

Merit: 10

Quote from: Sarchar on January 10, 2014, 01:21:31 AM

Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation. As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard.

Nevermind - I've figured it out. Chain codes aren't private, so even if someone has M (the public key of m), they cannot derive m/i'. This is important: it means that even with knowledge of the master public key, you cannot see any privately derived keys, public or private.

Sarchar

member

Activity: 88

Merit: 10

Quote from: WeMeetAgain on January 09, 2014, 03:18:00 PM

Quote from: Sarchar on January 09, 2014, 12:03:00 PM

I don't know how to interpret M/i'.

I'd say its trying to mean the public key of m/i'.

OK, this makes sense. The big/little M at the beginning describes whether the goal is to obtain/use/share the public or private extended keys in the result?

Quote

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

It looks like its assuming that you are, by default, protecting the master private key by always making the first generation of children through private derivation.

Can you explain this more? I don't think I fully grasp the security implications of public vs. private key derivation. As far as I can tell, even when deriving via public key, you still use the chain_code from the parent private extended key, which should make derivation by 3rd parties hard.

WeMeetAgain

newbie

Activity: 3

Merit: 11

Quote from: Sarchar on January 09, 2014, 12:03:00 PM

I don't know how to interpret M/i'.

I'd say its trying to mean the public key of m/i'.

Quote

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

It looks like its assuming that you are, by default, protecting the master private key by always making the first generation of children through private derivation.

Quote

2) If the primed lines cannot be derived from public keys, is it true that M alone cannot be used for complete auditing? If so, then every primed node has to share its public key with the auditor for access, and whoever holds M can never be sure that the holder of m didn't create hidden wallets

Yes.

Quote

Can it be that parts of the document are not in line with each other after some changes in the ideas/notes/text?

That's what it looks like to me.

Sarchar

member

Activity: 88

Merit: 10

I'm saddened that nobody has responded yet. I just put up http://bip32.org/ and I, too, had this exact concern while implementing it. I don't know how to interpret M/i'. In fact, it seems to me that you don't need private key derivation at all, just the ability to derive new private keys (from public key derivation) seems sufficient.

imrehg

newbie

Activity: 23

Merit: 0

I was checking the BIP32 description at https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki and playing with pycoin which does implement it, but some of the things are not totally clear to me.

1) In the document's notation m/i' means the ith first level wallet using private derivation using the private master node key (e.g. "Per-office balances"). M means public master node key (e.g. "Audits"). What does M/i' mean then? Isn't that true that primed wallets cannot be derived from public keys so it cannot be "ith first level wallet using private derivation using the public master node key"? Or would it my any chance mean "the public key of ith first level wallet using private derivation using the public master node key" (ie. the public counterpart of m/i')? But then I don't quite get the the logic of the notation.

2) If the primed lines cannot be derived from public keys, is it true that M alone cannot be used for complete auditing? If so, then every primed node has to share its public key with the auditor for access, and whoever holds M can never be sure that the holder of m didn't create hidden wallets.

3) Based on these, what would be actual the derivation of M/i'/0 (e.g. "Unsecure money receiver" & "Recurrent business-to-business transactions")?

My guess is that some of these issues stem from the particular weakness outlined there:

Quote

One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

but then e.g. how would M / Audits example be ever be correct? Can it be that parts of the document are not in line with each other after some changes in the ideas/notes/text?

Topic: Understanding BIP 32: private derivation and public keys (Read 4621 times)