5
1
According to BIP32's "Master key generation" section, "256 bits is advised".
See https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Master_key_generation
Why did BIP32 consider 256 bits to be the recommended seed size, and why did the authors of so many Bitcoin wallet implementations consider 256 bits unnecessary?
5
The reasons for the 3 numbers:
Bitcoin uses 256-bit ECDSA signatures. These require in the order of 2128 steps to find a private key from the public key is known. This is Bitcoin's security level: we aim to always require an attacker to perform 2128 steps. If the seed has less than 128 bits of entropy, this inevitably leads to a faster algorithm, where an attacker can simply iterate through all possible seeds in less than 2128 steps. Because of that, BIP32 requires at least 128 bits of entropy.
When the seed has less than 256 bits of entropy (but more than 128), the resulting keys will also have less than 256 bits of entropy. As elliptic curve cryptography uses keys with a full 256 bits (despite there being a faster attacker than breaks it in 2128 steps), BIP32 also recommends 256 bits of entropy.
The combination of private key and chaincode (the "extended private key") in BIP32 are 512 bits in size. Because of that, using a seed with more entropy than 512 bits cannot possibly increase security more - it's just information that gets thrown away. Because of that BIP32 limits the seed to at most 512 bits of entropy.
0
Seems like a question best answered by the author(s) of BIP32.
Other than that it is the age old question of "how much entropy" do I need?!
This is a pretty interesting read re: 128 bits in general. https://crypto.stackexchange.com/questions/48256/how-much-entropy-do-you-need-for-a-secure-certificate-generation
Also as a rule of thumb: when you insert 128 bits of entropy in a system, then it also forms the upper boundary for the entropy of anything derived from it.
If I'm allowed to speculate the intent of the author, 256 bits is probably advised because the eventual keys have that exact size, and that way the entropy matches the keysize.
Thanks for the idea, I've emailed the author of BIP32 to ask if he would consider answering this question on stackexchange. – knaccc – 2018-03-20T23:19:42.603
Thanks for your answer, Pieter. I'm not quite clear though: As you say, both public keys (compressed representation EC points) and private keys (scalars) are each represented with 256 bits, but they both have an effective bit strength of just 128 bits. Therefore why is there any advantage at all in generating scalar keys from a seed that has any more than 128 bits of entropy? The only reason I can think of is that bit strength is reduced a little when the seed is hashed to derive subkeys, but that would explain a recommendation for a seed of e.g. 140 bits rather than of a full 256 bits. – knaccc – 2018-05-27T23:11:44.510
1Well, being able to break an EC key with just 2^128 steps is somewhat theoretical. In practice, these algorithms have significant memory/cpu tradeoffs, and in practice would still be much slower than a straight 2^128 exhaustive search on keys with just 128 bits of entropy. I guess the answer is defense in depth: less than 128 bits of entropy definitely hurts security. Less than 256 bits may hurt. More than 512 bits can't help. – Pieter Wuille – 2018-05-28T01:01:36.727