# Does hashing a secret/seed make it effectively 2X less secure?

In many cryptocurrency projects I noticed that 32-byte seeds/secrets are hashed to arrive at new 32-byte keys.

The reason why is because you can then, with the addition to an index, use the same seed to generate multiple keypairs/addresses/wallets under one seed/secret.

For example:

seed1 = hash(seed,0); // abc..
seed2 = hash(seed,1); // def..
seed3 = hash(seed,2); // ghi..


Is a unique secure 32-byte random seed for each keypair much better and worth the additional computation?

Or will you lose absolutely no entropy(?) by hashing a 32-byte value to a new 32-byte value?

(assuming for all of the above that the hash functions and keypair functions are secure)

• Seems like getting rid of the hash function would definitely remove one possible weak chain anyway? Jun 19, 2022 at 15:09
• You'll lose a tiny amount of entropy due to the risk of hitting a short cycle (as the link Maarten provides in his answer explains). But it's a very tiny amount. The amount of "effective" entropy you gain by slowing down the operation is greater than the loss. Note that there are KDFs which do not suffer from this (very slight) loss in entropy. Jun 20, 2022 at 1:05

Not necessarily, but it uses the hash function as a poor-man's key derivation function. For common hash functions this won't introduce any exploitable vulnerability, but using a modern KDF such as HKDF would be a better design.

Is a unique secure 32-byte random seed for each keypair much better and worth the additional computation?

Usually the fact that the secrets/seeds are derived from one master secret/seed is considered a fundamental feature. When it comes to the strength of the algorithm, this answer might give some indication of strength.

If you just want to have a randomized secret then yes, using a tested / secure CSPRNG could give you better security - but it of course would depend on the comparison of the two algorithms.

When the algorithm is used as a KDF (where another party is able to perform the same calcuation) then HKDF has a somewhat better security model when a salt is being used.

Or will you lose absolutely no entropy(?) by hashing a 32-byte value to a new 32-byte value?

This question has been answered here. The conclusion is that the entropy (of 256 bits or smaller) is mostly retained for SHA-256 (or a similar 256 bit hash).