<p>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?</p>

<p>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.  </p>

CC BY-SA 3.0
2014-10-16T15:08:41.547Z
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
CC BY-SA 3.0
2014-10-16T15:20:52.913Z
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
CC BY-SA 3.0
2014-10-16T12:20:53.310Z
2014-10-16T12:20:53.310Z
Wizard Of Ozzie
<p>BIP 0032 "Security Implications" states</p>

<blockquote>
  <p>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).</p>
</blockquote>

<p>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?</p>

<bip32-hd-wallets>
Deterministic keys with one-way operation
tuxcanfly
# Deterministic keys with one-way operation

(Asked by: username_0 on 2014-10-16)

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?

**Tags:** bip32-hd-wallets


---

## 1 answers

### Answer by username_1 on 2014-10-16. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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  
> **username_1**: 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.  

---

