user15378: 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?

user9382: 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.  

15378: <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>
 9382: <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>
