How to treat/hash ECDH shared secret to use as keys for AES?

Question

I'm doing some studies/development for a security system that would use ECDH with ephemeral keys.

In my code I'm currently using a 256-bit EC, so when the two parts compute the shared secret, I get a 32B (256bit) array containing the shared secret.

Now, I would like to use this shared secret to compute a key for a symmetric key encryption algorithm, such as AES-128 (with a key size of 128 bits).

So my question is how to reduce the 256-bit shared secret to a 128-bit AES key? I have read that is better to hash the shared secret before using it as key for symmetric encryption, but with wich hashing algorithm? If I use SHA-256 I still get a 256-bit key. Is there any standard way to proceed to build a symmetric encryption key from a ECDH shared secret?

Answer 1

In general, producing symmetric keys from some "secret" is called key derivation and uses a key derivation function. There are several KDF designs out there; many protocols define their own (e.g. in SSL/TLS). In fact, exploring the details of SSL/TLS would be a good idea (pedagogically speaking).

There is a current "push" for defining a standard construction, backed by the IETF, and it is called HKDF; if you are in need of a KDF then you could do worse than choosing HKDF (though it is relatively recent, it benefits from a robust cryptographic foundation and appears at least as safe as any other competitor).

If you need only a limited amount of key material (e.g. 128 bits), then you can simply use one of the usual hash functions (say SHA-256) and truncate the output. That truncation is fine is not a consequence of the hash function being, say, resistant to collisions; however, it is still believed to be adequately secure with non-pathological hash function designs, in particular SHA-256.

---

As for standards, yeah, there is one. It is called ANSI X9.63. Since it is not a free standard (legally speaking, you must pay so see it), amateurs and students don't usually consider it, so it does not percolate to opensource software. Its KDF is based on SHA-1; it basically computes SHA-1(secret || counter) for successive values of the counter, which, as far as KDF go, is not a very attractive design, though not trivially weak (I only have an old draft; newer versions of X9.63 might use SHA-256).

Answer 2

There's nothing wrong with just truncating SHA-256 output to whatever number of bytes you need.

Also, even if you're using AES-128, you might benefit from extra available bytes, e.g. to initialise a IV (if you're using AES in a mode utilising IV) or to use as a MAC key (if you're using separate primitive to authenticate data).