<p>This recommendation comes directly from one of security considerations from the same document:</p>

<blockquote>
  <p>Note however that the following properties does not exist:
  (...) Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.</p>
</blockquote>

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

<p>The problem is that this number we add  (parse<sub>256</sub>(I<sub>L</sub>)) can be calculated from parent public key and parent private key.</p>

<p>So, if we know the child private key k<sub>child</sub> and before mentioned number parse<sub>256</sub>(I<sub>L</sub>) (which we know, because we know parent public key), then we can rearrange the equation from which this key was derived:</p>

<p>k<sub>child</sub> = parse<sub>256</sub>(I<sub>L</sub>) + k<sub>par</sub> (mod n)</p>

<p>and find k<sub>par</sub> which is the parent private key.</p>

CC BY-SA 3.0
2017-12-02T09:18:29.720Z
2017-12-02T09:18:29.720Z
Michał Zabielski
<p>I'm confused by the wording in BIP0032:</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). 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.</p>
</blockquote>

<p>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#The_default_wallet_layout" rel="noreferrer">default recommended wallet layout</a> is <code>m/0'/0/i</code>.</p>

<p>So if I leak the <code>xpub</code> of <code>m/0'/0</code> (which, in theory, my auditor has) and a private key in <code>m/0'/0/14</code>, then wouldn't all keys in <code>m/0'/0/i</code> be compromised? I understand that <code>m/1'</code> and <code>m</code> 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?</p>

CC BY-SA 4.0
2024-01-10T21:55:39.667Z
Does this answer your question? [Derivation of parent private key from non-hardened child](https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child)
Antoine Poinsot
<bip32-hd-wallets><deterministic-wallets>
Determining xprv from xpub and child private key
maletor
# Determining xprv from xpub and child private key

(Asked by: username_0 on 2017-10-28)

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](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#The_default_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?

**Tags:** bip32-hd-wallets, deterministic-wallets

> **Comments:**
> **username_1**: Does this answer your question? [Derivation of parent private key from non-hardened child](https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child)  

---

## 1 answers

### Answer by username_2 on 2017-12-02. Score: 4 | Accepted answer

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.


---

