# Why must curve25519 shared secret be hashed?

When using the curve25519 DH function, D.J. Bernstein recommends hashing the shared secret before using it as a session key for a symmetric block cipher. Why is that?

Hashing won't increase the entropy. Do the shared secrets from a curve25519 have some non-random properties that could be exploited if the shared secret isn't hashed?

I am puzzled...

-

## migrated from security.stackexchange.comSep 30 '13 at 21:54

This question came from our site for information security professionals.

Shared secret resulting from the Diffie-Hellman step is a mathematical object; namely, the X coordinate of a curve point. It is a value in a non-binary range; moreover, it is indistinguishable from randomness only up to the security against discrete logarithm, i.e. about 128 bits. Thus, it is at least debatable that parts of the key might be guessable from the public DH values.

In other words, there are at least 128 bits of entropy ("entropy" here used as a loose meaning for "resistance to guessing attacks") in the 256-bit output of the DH, but you don't know really where. If you extract, for instance, the first 128 bits with basic truncation, then you don't know if you got your 128 entropy bits, or less, possibly much less.

No exploitable bias is really known at that point, but we know enough to be wary. Hashing the DH output is a simple and safe way to gather all the entropy and spread it around as needed, hence the recommendation.

-
The shared secret obviously won't be communicated to other parties. It is typically used as the key for a symmetric cipher. Why is spreading out entropy over the bits of a key important? Or it this only relevant if the key is truncated to shorter lengths (thus potentially using only the bits that have less entropy)? – Jason Smith Oct 1 '13 at 7:24
If you use a block cipher with a 256-bit key then using the complete raw DH result as key is fine, as long as the block cipher is ideal. However, we know that existing block ciphers are not ideal, and interactions between DH and, for instance, related-key attacks for some block ciphers, are not well studied. "Better safe than sorry": a hash function invocation has negligible cost (with regards to the DH at least) and provides a nice "isolation layer" which voids such concerns, hence the recommendation. – Thomas Pornin Oct 1 '13 at 10:51
If the output of DH is used as material for multiple keys (protocols like IKE use it to derive keys for both peers), it could be preferable to use value from DH as input to key derivation function, such as HMAC-based Extract-and-Expand Key Derivation Function (HKDF). NIST SP 800-56C is based on that RFC, but the official source is currently unreachable because NIST web site is closed. – user4982 Oct 1 '13 at 20:15