Old BIP32 flaw lets you derive the master private key - WONTFIX?

[NotATether]

During my unrelated efforts of porting the blockstack wallet recovery source code to Python 3 (which uses what feels like a dozen abandoned dependencies) I found inside the Wallet class of bitmerchant, a pypi package (github repo) the following method:

Code:

def crack_private_key(self, child_private_key):
        """Crack the parent private key given a child private key.

        BIP32 has a vulnerability/feature that allows you to recover the
        master private key if you're given a master public key and any of its
        publicly-derived child private keys. This is a pretty serious security
        vulnerability that looks as innocuous as this:

        >>> w = Wallet.new_random_wallet()
        >>> child = w.get_child(0, is_prime=False)
        >>> w_pub = w.public_copy()
        >>> assert w_pub.private_key is None
        >>> master_public_key = w_pub.serialize_b58(private=False)
        >>> # Now you put master_public_key on your website
        >>> # and give somebody a private key
        >>> public_master = Wallet.deserialize(master_public_key)
        >>> cracked_private_master = public_master.crack_private_key(child)
        >>> assert w == cracked_private_master  # :(

        Implementation details from http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/  # nopep8

If I go to the Bitcoin magazine link it states how if you know a child private key and the master public key you can derive its master private key. And to me this sounds like a very serious bug that's apparently unfixable. Given how old it is (the fact that it's from 2013 is damning) and the severity of this have there been any efforts to deprecate BIP32 and introduce another key derivation BIP that doesn't have this flaw?

Perhaps more importantly, given that BIP44 and friends uses at least one hardened child key, are hardened keys resistant to this?

[1714858749]

1714858749

[1714858749]

1714858749

[j2002ba2]

Only non-hardened child with leaked private key, and leaked parent extended public key makes finding the parent private key easy.

k_par = k_i - parse₂₅₆(I_L) (mod n)
I = HMAC-SHA512(Key = c_par, Data = ser_P(K_par) || ser₃₂(i))

Hardened derivation uses the parent private key, which is unknown.
I = HMAC-SHA512(Key = c_par, Data = 0x00 || ser₂₅₆(k_par) || ser₃₂(i))

Bitcoin Core uses only hardened keys.

Non-hardened keys could be useful, when a system needs to generate new addresses, without having access to their private keys.

[pooya87]

I don't think we can refer to this as a bug, it is more of a feature (with side effects). Besides users are not supposed to reveal their private keys in first place whether it is one or all.

The feature (meaning the way child keys are derived in a non-hardened path) allows something like what Electrum does, you create your mnemonic offline and derive the (public + private) keys there. Then only copy the master public key and move it to your online wallet and derive the same (public) keys there too.
Without this feature, this option wouldn't have been possible.

[gmaxwell]

Fixed by harden keys.  Things that don't use harden keys shouldn't allow export of individual keys.

It's fundamentally impossible to 'fix' for non-hardened keys, the best you can do is make it tolerate leaking N keys for some N which the extended pubkey is linear in the size of... and most cases where you could leak one key you will also leak N for any small reasonable value of N.

It's like saying numbers are "flawed" because if I tell you I derived a number by adding a number known to you to some unknown number, you can then derrie the unknown number by subtracting.  In fact, that is _literally_ what is happening in this case:   Public derivation generates more keys by just adding known values to a master key.  You can get the other private keys from any private key just subtracting those numbers from one of the children.

This property was known from day one-- but people have applied public derivation far more widely than I ever expected it-- including in lots of places where its a liability.

It's really just a category error to think of there being multiple keys with public derivation. There is really just a single key.