Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Given that a TLS client and server have already agreed upon ECDHE for session key establishment, how does the selection of the actual elliptic curve ("domain parameters") being used for deriving the DH keys work?

Is the curve somehow negotiated and if so how does that work (in the context of TLS)?

share|improve this question
up vote 3 down vote accepted

As described in section 5.1 of RFC 4492, the client announces what curves it supports in an extension message, included in the ClientHello message. This gives the server the possibility to check whether client and server both support at least one specific curve, before choosing whether elliptic curves will be used at all.

Then the server chooses the curve. The curves named in the Supported Elliptic Curves extension are ordered by client preferences, so a courteous server may elect to follow the client's preferences, i.e. the first one in the client's list that the server also supports (where "supports" means "has the code for it, and deems it acceptable"). But, really, the server chooses.

share|improve this answer
Thanks for explaining! Regarding negotiation: what you describe refers to named curves (IANA registered) with domain parameters built into the implementation, right? Do you know any TLS implementation that supports arbitrary_explicit_prime_curves which the RFC also describes? Since, e.g., OpenSSL does not:, - I am asking since of and those NIST defined might be .. well, you know where I am heading;) – oberstet Oct 26 '13 at 23:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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