I'm playing around with ECC, trying to encrypt traffic between my webapp and backend (its not a product, im trying to learn and understand more about ECC)

I managed to generate keys, successful run key exchange and got same point on both ends.

Now I wonder how I should convert my point which has 2 coordinates into AES key.

  • 1
    $\begingroup$ Are you using ECDH for key exchange? Not a clear question. $\endgroup$
    – kelalaka
    Commented Jun 21, 2020 at 9:59
  • 2
    $\begingroup$ SEC1 codifies ECDH, and uses a Key Derivation Function. $\endgroup$
    – fgrieu
    Commented Jun 21, 2020 at 10:05
  • $\begingroup$ @kelalaka i did ECDH, i multiply alices public key(which i haf as point) by bobs private key (and vice versa) and i got shared point on curve. now my question is, how i should convert tuple (x,y) into 256bit key. $\endgroup$
    – user902383
    Commented Jun 21, 2020 at 11:56
  • 1
    $\begingroup$ KDF's as fgrieu pointed. $\endgroup$
    – kelalaka
    Commented Jun 21, 2020 at 12:22

1 Answer 1


Most symmetric cryptographic algorithms requires a key that is indistinguishable from random. This means that the process used to generate the key must have a uniform, independent distribution over all bit-strings of the appropriate length. Using a non-uniformly-random key not only reduces the brute force needed to guess it, but may also open the door to related-key attacks.

The expressions “key agreement” and “key exchange” are often used to mean a mechanism like (elliptic curve) Diffie-Hellman, but (EC)DH itself does not produce a key, it only produces a shared secret. This secret is in some numerical range that depends on the curve: not all $2^n$-bit values are possible. Even within this range, it is not uniformly distributed (it can't be since there isn't the same number of private points and public coordinates).

To go from the shared secret to a key, you need to use a key derivation function. A KDF takes a secret which has a cryptographically high number of possible values but may not be uniformly distributed, and has output that is indistinguishable from random to anyone who doesn't know the secret.

In a pinch, if you only need one symmetric key from the key exchange, hashing the shared secret with a cryptographic hash such as SHA-256 or SHA-512 is fine. If you need more key material than one hash's length, or if you prefer to use a standard construction that may be more robust in case a partial weakness is discovered in a hash function, there are (too) many standardized key derivation functions, for example HKDF (robust and popular), the TLS 1.2 PRF (a variant of HKDF which is specific to TLS), the NIST SP 800-56C key derivation functions (some hash-based like HKDF, some AES-based), etc.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.