# Can a raw ECDH shared secret be used directly for encryption?

If two parties calculate an ECDH shared secret can they (with no security weakness) use this raw value directly as an encryption key, assuming the underlying key and ECDH sizes match?

Also the situation I'm specifically looking at using static ECC keys, not ephemeral ones, but I would also be curious if using the raw ECDH value for encryption may be OK when using ephemeral keys. I do understand that it is ~trivial to apply a KDF to the ECDH secret but I am evaluating an existing system. The system uses p256r1 and is using the resulting x-coordinate as the shared secret.

• The output of ECDH is a point on the curve. But you did not specify, which encryption scheme you're looking at. And if you just use the binary representation of the points, then you might not have a uniformly distributed binary number.
– tylo
Jun 7 '17 at 15:37
• Do you define the shared secret as the output point or output x-coordinate ? That makes a lot of difference... Jun 7 '17 at 15:48
• p256r1, x-coord is used as the shared secret (edit applied to post to add this info) and the encryption method is XOR. The plain text in the XOR is a new random share key to be distributed to new nodes added to a network. Jun 7 '17 at 16:27

If two parties calculate an ECDH shared secret can they (with no security weakness) use this raw value directly as an encryption key?

If the ECDH curve size is large enough, then yes, there is no immediate security weakness. It would cause the theoreticians heartburn (as the symmetric key is supposed to be chosen uniformly, and it isn't in this case), however there is no practical way for an attacker to exploit this.

To give an example: suppose the ECDH is done over P256, and you use the x-coordinate as the shared secret; and you use that shared secret to key AES-256.

Then, the attacker knows that (approximately) half the possible AES-256 keys are impossible (as they cannot be the x-coordinate of a P256 point); however there still are approximately $2^{255}$ possible values the key could be, and it would still be impractical to search over that large of a space.

• Let's say approximately half the possible AES-256 keys are not possible as they cannot be the x-coordinate of a P256 point. Does an attacker that brute-forces keys know that as soon as he sees the x-coordinate or does he need to perform some coordinateIsOnCurve function to know that the x-coordinate can't be the one of a P256 point? In that case feeding the key to the AES system directly would be faster than validating if the x-coordinate can or cannot possibly belong to a valid point and we would again have $2^{256}$ right? Jun 7 '17 at 15:50
• @TrinityTonic By Kerckhoffs' theorem, the attacker knows already everything in the system except the actual key. And that includes the procedure how the key is chosen/generated. So no, you can't argue that way. Considering only brute-force attackers is a sure way to design an insecure system.
– tylo
Jun 7 '17 at 16:24
• I believe @TrinityTonic has a point. The attacker can't a priori known if a 256 bit string $x$ is or not a valid P256 x-coordinate. It has to compute $x^3+ax+b$ and check if it's a quadratic residue. That's much more complex than an AES encryption, so it's more convenient to just bruteforce the whole keyspace Jun 7 '17 at 16:34
• @Ruggero: actually, that point is actually irrelevant to the point I was making (and not because checking whether $x^3 + ax + b$ is a QR is not the only way to generate only possible EC points; you could also incrementally generate points $iG$ for successive integers $i$); the point I was making is that, even if we had a magic way of iterating only through the circa $2^{255}$ possible shared secret values, it's infeasible. If no such magic way exists, well, it's still infeasible. Jun 7 '17 at 17:11
• P256 doesn't give you 256 bits of security (en.wikipedia.org/wiki/… and github.com/ethereum/go-ethereum/blob/…), but rather half, so P256 is equivalent to 128-bit AES key. To get closer to 256-bit security for AES-256 you need P521 or P384 (if P521 is not available) and a key derivation function to make the curve's key match AES-256 key size. Oct 8 '20 at 12:37