Deterministic keys with one-way operation

3

BIP 0032 "Security Implications" states

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).

From what I understand, the weakness is due to the reversible nature of the operation on extended public key (addition). Wouldn't it be possible to address this by using a one-way function like hashing instead of addition?

tuxcanfly

Posted 2014-10-16T11:44:42.623

Reputation: 365

Answers

2

If you use a one-way hash function (ie like hashing ECDSA public key with SHA256/RIPEMD160 into a hex public key) then how can you employ hierarchical deterministic functioning?

You can't. The whole point here is that if you lose your private key for a grandchild public key you can get it back again with the parent key. A two-way hashing function obfuscating the data would work but that's basically what's already in place.

Wizard Of Ozzie

Posted 2014-10-16T11:44:42.623

Reputation: 4 535

can you help me understand why hashing wouldn't be deterministic? I'm guessing something like sha256(extended_private_key, offset) where offset is 1...n could result in n deterministic keys – tuxcanfly – 2014-10-16T15:08:41.547

I may be wrong, but if the hash has no predictable outcome, then adding an offset to the random number is just saying random hashed output + offset, or more simply (since we ignore the random part) offset, which is what we have already with HD wallets. Hashing the offset is the only way but then how do you get it back? If there's a take home point it's that there is no way to predict a hashed output, and if there were, the encryption would be poor. Hashed output would be impossible to detect the offset added to it. – Wizard Of Ozzie – 2014-10-16T15:20:52.913

Asked: 2014-10-16T11:44:42.623

Viewed: 133 times

Active: 2015-04-22T18:17:21.727