Skip to content

BIP32 recommends a 256 bit seed. Why do most Bitcoin wallets only use a 128 bit seed?

According to BIP32's "Master key generation" section, "256 bits is advised".

See BIP32

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?

Question Link


Answer

Answered by: Pieter Wuille

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.


Comment 1 (OP): 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.

Comment 2 (Pieter): Well, 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.