2
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.
1
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)
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).
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 – 2016-07-01T00:31:03.687
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 – 2016-07-07T08:59:13.033
It probably is given future optimizations. My calculations are based on current hardware and that SHA512 is random enough. – Jimmy Song – 2016-07-07T22:06:18.437
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 – 2016-07-08T01:13:20.217
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 – 2016-07-08T13:31:48.480