# Determining xprv from xpub and child private key

I'm confused by the wording in BIP0032:

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). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

The default recommended wallet layout is `m/0'/0/i`.

So if I leak the `xpub` of `m/0'/0` (which, in theory, my auditor has) and a private key in `m/0'/0/14`, then wouldn't all keys in `m/0'/0/i` be compromised? I understand that `m/1'` and `m` are safe but now you've lost an entire account when all that needed to be done was harden the index. What is the cause for this recommendation?

This recommendation comes directly from one of security considerations from the same document:

Note however that the following properties does not exist: (...) Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.

The reason for this recommendation is the fact all the non-hardened key derivation bases on some of the elliptic curve properties. One of them is that you can add some number to private key (which itself is ordinary number). When you convert the same number to the point on elliptic curve you can add it to public key (which itself is the point on elliptic curve). This new private key is exactly the private key for the new public key.

The problem is that this number we add (parse256(IL)) can be calculated from parent public key and parent private key.

So, if we know the child private key kchild and before mentioned number parse256(IL) (which we know, because we know parent public key), then we can rearrange the equation from which this key was derived:

kchild = parse256(IL) + kpar (mod n)

and find kpar which is the parent private key.