<p>It's a bit strange to use single digits for the entire HD path since the BIP32 spec allows you to pick numbers up to 2^31 (non-hardened). BIP32 key derivation is largely using SHA512. Current ASICS for SHA256 can calculate about 10 trillion SHA256's per second, so about 160 quintillion hash operations in about 6 months. Assuming an ASIC can be built with roughly the same hashing power, you would need to go about 20 levels deep to force a machine like that to find your address in about 6 months. Of course, more machines mean faster cracking.</p>

<p>A far simpler solution would be to use the entire space of each level instead of just 10. 3 levels then would be plenty (~10^28)</p>

CC BY-SA 3.0
2016-07-07T08:59:13.033Z
20 single-digit levels is around log(10^20)/log(2) = about 66 bits of entropy. That seems way too low to me.
Pieter Wuille
CC BY-SA 3.0
2016-07-07T22:06:18.437Z
It probably is given future optimizations. My calculations are based on current hardware and that SHA512 is random enough.
Jimmy Song
CC BY-SA 3.0
2016-07-08T01:13:20.217Z
The Bitcoin network as a whole does more than 2^66 hashes per minute. Sure, hashing is not EC operations and the existing hashing hardware can't be used for it. But you're not protecting against a known attacker. You want to be sure nobody currently or in the medium tine future has the ability to crack your keys. Given that operations of this magnitude already happen every minute, you should really look for a much larger safety margin. 2^128 is usually the minimum recommendation these days.
Pieter Wuille
CC BY-SA 3.0
2016-07-08T13:31:48.480Z
I agree. And certainly, if the attacker had the entire bitcoin network's worth of equipment, that wouldn't be secure. I did say "more machines mean faster cracking". This wasn't meant to be a future-proof answer, just an estimate based on current hashing rates and a reasonably cost-efficient crack.
Jimmy Song
CC BY-SA 3.0
2016-06-30T00:30:46.080Z
2016-06-30T00:30:46.080Z
Jimmy Song
<p>If you need to derive a random key from another (rather than one that can be found though iterative search), don't use BIP32.</p>

<p>If you want normal derivation (allowing the pubkeys to be derived without knowing the parent privkey), use the pay-to-contract scheme:
<code>
privkey = parent_privkey + H(parent_pubkey || id)
pubkey = parent_pubkey + H(parent_pubkey || id) * G
</code></p>

<p>If you want hardered derivation, just use the parent key as extra entropy source:
<code>
privkey = H(parent_privkey || id)
pubkey = H(parent_privkey || id) * G
</code></p>

<p>(where id is at least 16 bytes of randomness)</p>

<p>BIP32 <em>can</em> be used if you really need it, for this use case, but it is unnecessarily complicated. I would suggest no less than 5 levels of 31-bit integers (4 would be less than 128 bits of entropy) or no less than 39 levels for single-digit subpaths (129.55 bits of entropy).</p>

CC BY-SA 3.0
2016-07-01T00:31:03.687Z
Apparently if I used a picture of you as entropy to generate a random key it would be more random than if I had used any other picture ;)
derrend
CC BY-SA 3.0
2016-06-30T15:23:18.900Z
2016-06-30T15:38:35.067Z
2016-06-30T15:38:35.067Z
Pieter Wuille
<p>Using pycoin.</p>

<pre><code>ku &lt;ext_pri_key&gt; -s 1/4/6/2/8/4/2/5.......
</code></pre>

<p>How many levels deep into the tree would I need to go (using only single digits) before it would be infeasible for an attacker to find it using a systematic search.</p>

<p>Twenty levels deep I thought would be adequate:</p>

<pre><code>10**20 = 100000000000000000000
</code></pre>

<p>I know there are more effictive ways to obscure your address but I'm interested in this particular use case.</p>

<p>Thanks.</p>

<address><private-key><address-generation>
What would be a rational subkey depth to use so that my address is infeasible to locate via a systematic search?
derrend
# What would be a rational subkey depth to use so that my address is infeasible to locate via a systematic search?

(Asked by: username_0 on 2016-06-29)

Using pycoin.

```
ku <ext_pri_key> -s 1/4/6/2/8/4/2/5.......

```

How many levels deep into the tree would I need to go (using only single digits) before it would be infeasible for an attacker to find it using a systematic search.

Twenty levels deep I thought would be adequate:

```
10**20 = 100000000000000000000

```

I know there are more effictive ways to obscure your address but I'm interested in this particular use case.

Thanks.

**Tags:** address, private-key, address-generation


---

## 2 answers

### Answer by username_1 on 2016-06-30. Score: 1 | Accepted answer

It's a bit strange to use single digits for the entire HD path since the BIP32 spec allows you to pick numbers up to 2^31 (non-hardened). BIP32 key derivation is largely using SHA512. Current ASICS for SHA256 can calculate about 10 trillion SHA256's per second, so about 160 quintillion hash operations in about 6 months. Assuming an ASIC can be built with roughly the same hashing power, you would need to go about 20 levels deep to force a machine like that to find your address in about 6 months. Of course, more machines mean faster cracking.

A far simpler solution would be to use the entire space of each level instead of just 10. 3 levels then would be plenty (~10^28)

> **Comments:**
> **username_2**: 20 single-digit levels is around log(10^20)/log(2) = about 66 bits of entropy. That seems way too low to me.  
> **username_1**: It probably is given future optimizations. My calculations are based on current hardware and that SHA512 is random enough.  
> **username_2**: The Bitcoin network as a whole does more than 2^66 hashes per minute. Sure, hashing is not EC operations and the existing hashing hardware can't be used for it. But you're not protecting against a known attacker. You want to be sure nobody currently or in the medium tine future has the ability to crack your keys. Given that operations of this magnitude already happen every minute, you should really look for a much larger safety margin. 2^128 is usually the minimum recommendation these days.  
> **username_1**: I agree. And certainly, if the attacker had the entire bitcoin network's worth of equipment, that wouldn't be secure. I did say "more machines mean faster cracking". This wasn't meant to be a future-proof answer, just an estimate based on current hashing rates and a reasonably cost-efficient crack.  

---

### Answer by username_2 on 2016-06-30. Score: 0

If you need to derive a random key from another (rather than one that can be found though iterative search), don't use BIP32.

If you want normal derivation (allowing the pubkeys to be derived without knowing the parent privkey), use the pay-to-contract scheme:
`privkey = parent_privkey + H(parent_pubkey || id)
pubkey = parent_pubkey + H(parent_pubkey || id) * G`

If you want hardered derivation, just use the parent key as extra entropy source:
`privkey = H(parent_privkey || id)
pubkey = H(parent_privkey || id) * G`

(where id is at least 16 bytes of randomness)

BIP32 *can* be used if you really need it, for this use case, but it is unnecessarily complicated. I would suggest no less than 5 levels of 31-bit integers (4 would be less than 128 bits of entropy) or no less than 39 levels for single-digit subpaths (129.55 bits of entropy).

> **Comments:**
> **username_0**: Apparently if I used a picture of you as entropy to generate a random key it would be more random than if I had used any other picture ;)  

---

