7
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – tylo
    Jun 7, 2017 at 15:37
  • $\begingroup$ Do you define the shared secret as the output point or output x-coordinate ? That makes a lot of difference... $\endgroup$
    – Ruggero
    Jun 7, 2017 at 15:48
  • $\begingroup$ 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. $\endgroup$
    – big_fish_small_pond
    Jun 7, 2017 at 16:27

1 Answer 1

Reset to default
11
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ 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? $\endgroup$
    – TrinityTonic
    Jun 7, 2017 at 15:50
  • $\begingroup$ @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. $\endgroup$
    – tylo
    Jun 7, 2017 at 16:24
  • $\begingroup$ 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 $\endgroup$
    – Ruggero
    Jun 7, 2017 at 16:34
  • $\begingroup$ @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. $\endgroup$
    – poncho
    Jun 7, 2017 at 17:11
  • $\begingroup$ 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. $\endgroup$
    – joonas.fi
    Oct 8, 2020 at 12:37

Your Answer

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

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