<p>A non-hardened private key is derived using the equations shown below. Here small case letter represents private keys and large case represents public keys. G is the generator point, c is the chain code and i is the index number of the key generated. <code>Kpar</code> and <code>cpar</code> together represent the extended public key. <code>kpar</code> and <code>cpar</code> together represents the extended privat key.</p>

<pre><code>k(i) = kpar + hash(Kpar, cpar, i)
rearranging you get, kpar = k(i) - hash(Kpar, cpar, i)
</code></pre>

<p>Now, let us say the attacker gets his hands on <code>k(i)</code> and <code>xpub</code>. You can generate public keys without the need of private keys using the <code>xpub</code> with the following equation: <code>K(i) = Kpar + hash(Kpar, cpar, i)*G</code> (check why this equation holds below in Appendix). The attacker is going to increment the index (i) in a loop until it generates the public key associated with <code>k(i)</code>. When <code>K(i) = k(i) * G</code> the attacker knows the index number.</p>

<p>Thus with the index in his hand, he can just calculate the kpar from the equation <code>kpar = k(i) - hash(Kpar, cpar, i)</code>.</p>

<p>Hardened keys prevent this by using the equation: <code>k(i) = kpar + hash(kpar, cpar, i)</code>. So, although you get your hands on the <code>xpub</code> and the <code>k(i)</code>, you will not be able to reverse engineer <code>kpar</code> as that variable is in the hash function which is one-way.</p>

<h2>Appendix:</h2>

<pre><code>we saw above that k(i) = kpar + hash(Kpar, cpar, i)
=&gt; k(i) *G = kpar*g + hash(Kpar, cpar, i)*G
=&gt; K(i) = Kpar + hash(Kpar, cpar, i)*G
</code></pre>

CC BY-SA 4.0
2021-07-06T14:30:36.697Z
Thanks, this is very helpful. It would be even better if you explicitly define `xpub`.
Adam Spiers
CC BY-SA 4.0
2019-05-19T09:54:52.120Z
2019-05-19T11:27:59.943Z
2019-05-19T11:27:59.943Z
Ugam Kamat
<p>I'm trying to better understand hardened keys and normal keys and how the former protects the rest of and HD wallet.</p>

<p>Following on from the answer provided here: <a href="https://bitcoin.stackexchange.com/questions/37488/eli5-whats-the-difference-between-a-child-key-and-a-hardened-child-key-in-bip3">ELI5: What&#39;s the difference between a child-key and a hardened child-key in BIP32</a></p>

<p>I'd like to know "how an attacker would be able to work out the private key of the extended public key, and therefore get every key that can be derived from that, hardened and non-hardened." should they manage to "1) gain access to  the extended public key and 2) one of the non-hardened private keys that was derived from it"</p>

<p>Thanks in advance!</p>

CC BY-SA 4.0
2021-07-06T14:53:49.697Z
Probably a duplicate of https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child ?
Adam Spiers
<private-key><bip32-hd-wallets>
Hardened Keys vs Normal Keys - A Simpler Explanation
Sach
# Hardened Keys vs Normal Keys - A Simpler Explanation

(Asked by: username_0 on 2019-05-19)

I'm trying to better understand hardened keys and normal keys and how the former protects the rest of and HD wallet.

Following on from the answer provided here: [ELI5: What's the difference between a child-key and a hardened child-key in BIP32](https://bitcoin.stackexchange.com/questions/37488/eli5-whats-the-difference-between-a-child-key-and-a-hardened-child-key-in-bip3)

I'd like to know "how an attacker would be able to work out the private key of the extended public key, and therefore get every key that can be derived from that, hardened and non-hardened." should they manage to "1) gain access to the extended public key and 2) one of the non-hardened private keys that was derived from it"

Thanks in advance!

**Tags:** private-key, bip32-hd-wallets

> **Comments:**
> **username_1**: Probably a duplicate of https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child ?  

---

## 1 answers

### Answer by username_2 on 2019-05-19. Score: 3 | Accepted answer

A non-hardened private key is derived using the equations shown below. Here small case letter represents private keys and large case represents public keys. G is the generator point, c is the chain code and i is the index number of the key generated. `Kpar` and `cpar` together represent the extended public key. `kpar` and `cpar` together represents the extended privat key.

```
k(i) = kpar + hash(Kpar, cpar, i)
rearranging you get, kpar = k(i) - hash(Kpar, cpar, i)

```

Now, let us say the attacker gets his hands on `k(i)` and `xpub`. You can generate public keys without the need of private keys using the `xpub` with the following equation: `K(i) = Kpar + hash(Kpar, cpar, i)*G` (check why this equation holds below in Appendix). The attacker is going to increment the index (i) in a loop until it generates the public key associated with `k(i)`. When `K(i) = k(i) * G` the attacker knows the index number.

Thus with the index in his hand, he can just calculate the kpar from the equation `kpar = k(i) - hash(Kpar, cpar, i)`.

Hardened keys prevent this by using the equation: `k(i) = kpar + hash(kpar, cpar, i)`. So, although you get your hands on the `xpub` and the `k(i)`, you will not be able to reverse engineer `kpar` as that variable is in the hash function which is one-way.

## Appendix:

```
we saw above that k(i) = kpar + hash(Kpar, cpar, i)
=> k(i) *G = kpar*g + hash(Kpar, cpar, i)*G
=> K(i) = Kpar + hash(Kpar, cpar, i)*G

```

> **Comments:**
> **username_1**: Thanks, this is very helpful. It would be even better if you explicitly define `xpub`.  

---

