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

Question

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 this bad practice?

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)

Answer 1

Is this bad practice?

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).