1

I am designing a secure protocol (for academic/learning purposes) and I am at the point where I need to (re)design the key exchange step.

In my previous implementation, I used to rely on RSA to encrypt then sign a couple of randomly generated AES keys that I would then use for traffic encryption.

It has been brought to my attention that using Diffie Hellman for the key exchange could suit my needs better but I'm not too comfortable using an algorithm I don't understand well enough, hence the questions:

I'd like to use EC-DHE and I read that the generated key was not random (read: it has some structure, that I suppose comes from the underlying mathematical concepts). I always heard that using randomly generated keys was highly recommended for symmetric cipher algorithms. Even if I hash the resulting DHE key, it still won't be "random". Is it still okay to use it for that purpose?

I understood (please correct me if I'm wrong), that in EC-DHE, the choice of the elliptic curve is basically an easy way of choosing DH parameters. Is there anything I should be aware of when picking the elliptic curve? Should I let the users decide what EC they can use?

TildalWave
  • 10,801
  • 11
  • 45
  • 84
ereOn
  • 134
  • 5
  • 1
    You should feed the shared to a KDF which will eliminate the structure. I recommend HKDF. If you want something simpler, use a plain hash. I also recommend only using the x-coordinate of the shared secret as input to the KDF, – CodesInChaos Mar 04 '14 at 08:39

3 Answers3

1

DH (be it with elliptic curves or not) results in a shared secret. That secret is a numerical value with some algebraic properties; however, all the secrecy is contained in it. You just need to distill it, the same way you turn potatoes into vodka.

Suppose that you are using a 256-bit elliptic curve, e.g. NIST's standard P-256 curve. The elements sent over the wire are curve points, each being, formally, a pair of coordinates (X,Y) in a 256-bit field. The DH result is another curve point, and, per the standard, the X coordinate of that final point is the shared secret. It is a 256-bit value. With such a curve, ECDH is supposed to offer "128-bit security" (which is good), so the shared secret somehow contains 128 bits worth of secrecy. That secrecy is "spread" over the actual 256 bits. So there is room for structure as well in that 256-bit value.

Using the resulting 256 bits "as is" is usually considered unwise because it is not easy to determine the extent of that extra structure, and how it could be exploited externally. To turn these 256 bits into a sequence of bits that you may truncated and split into keys for AES/HMAC/whatever, the simplest method is to hash them with some hash function. E.g., apply SHA-256, and you get again 256 bits, which can then be safely split and used as you wish. For a more generic case, use a key derivation function.

As for the curve choice: since there are performance benefits to hardcode the exact curve in the implementations, most existing libraries will support only a handful of specific curves. In SSL/TLS, when using elliptic curves, the client sends a list of symbolic designations for the curves it supports, and then the server chooses one of these curves. In practice, everybody uses P-256. Of course, in a custom protocol, you can choose some other curve; you could even mandate that arbitrary curves may be used, dynamically, but then you would have to make provisions for sending the curve parameters, and this will be burdensome for implementations since most EC libraries don't offer support for arbitrary curves.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • What would the problem be with just folding these 256 bits in half (since it only provides 128 bits of entropy anyway) and feeding the resulting value to AES128, for example? Or even feeding it directly to AES256? I can't think of any (modern, well-established) cipher that can be weakened by a particular structure in the key. – forest Dec 09 '17 at 10:10
0

Constructing elliptic curves is computationally more expensive than choosing DH parameters. Constructing an elliptic curve is not a trivial task.

I would recommend taking a look at the following question and the responses: Can custom elliptic curves be used in common TLS implementations?.

As is mentioned in that thread, you are likely to run into compatibility and implementation issues if you stray too far from some of the more well accepted 'named curves' in OpenSSL. Allowing your users to specify arbitrary curves would seem to be impractical.

Community
  • 1
Lysimachas
  • 11
  • 3
-1

First and foremost, DHE/ECDHE allows two person to establish a shared secret key but does not incorporate in authentication. Hence, DHE/ECDHE should be used together with RSA (or DSS) signatures whereby the public value transmitted over the communication channel would be signed by the private key of the RSA (or DSS). To verify the authenticity, the recipient would 'unsign' using the public key of the sender.

As you can see in the Wiki article for EC-DH, the parameters to be defined are (p,a,b,G,n,h) where:

  1. p - underlying field of the Elliptic Curve (eg. prime field, binary field
  2. a,b - coefficient of the Elliptic Curve
  3. G - sample base point (Gx, Gy)
  4. n - group order
  5. h - cofactor (where h = #E(Field_p)/n)

However, based on my understanding of practical EC-DH, there is a set of recommended parameters for different suites. The reference can be found here by NIST.

Generally, the parameters used is decided by the server.This is generally so in SSL/TLS protocol.

edmund2008
  • 33
  • 3
  • In a new protocol I wouldn't mix add DSA or RSA for authentication. I'd just use long term DH keys. That way you don't need to implement a second scheme and you get better deniability. ECDHE_RSA is an artifact of SSL's history. – CodesInChaos Mar 04 '14 at 08:33
  • Does this answer the question? – Rory Alsop Mar 04 '14 at 10:21
  • I guess it depends on the requirements of the project. Using long term DH keys might be easier but it doesn't provide perfect forward secrecy. – edmund2008 Mar 04 '14 at 11:55
  • @edmund2008 I said long term DH keys for authentication. You obviously should still use short term DH keys for confidentiality. – CodesInChaos Mar 04 '14 at 13:40
  • I got what you mean! So what algorithm would you use to sign with the long term DH keys? – edmund2008 Mar 04 '14 at 15:45