Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In Diffie Hellman key exchange technique both the parties aggree on a common parameter g then they generate their private parameters a and b . Then they exchange g^a and g^b. now they can calculate the common secret key g^ab.
But my question is how do they agree on the parameter g. Is it specified in the certificate? If yes does it require a special type of certificate and what infomation is there in this type of certificate?

share|improve this question
add comment

migrated from stackoverflow.com Apr 25 '12 at 16:53

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 1 down vote accepted

There are two natural ways to do it.

  1. The specification can identify a set of pre-defined groups. The group parameters for each one are hard-coded in the software used by both endpoints. The public key then specifies which of those groups it is intended for use with. In the case of Diffie-Hellman, the group parameters are g and p, so the group identifier in the public key determines the value of g. Since the group identifier is in the public key, it is included within the certificate.

  2. Alternatively, the group parameters themselves (g and p) can be included in the certificate, as part of the public key.

Either way works. Either way, the information in the certificate allows you to determine the proper value of g and p to use. Beyond that, there's nothing special required.

share|improve this answer
    
Can you just show how such a certificate looks like. A link pointing to it will be fine. –  Ashwin Apr 27 '12 at 11:59
add comment

You don't need a special certificate for Ephemeral Diffie-Hellman key exchange, but you need the Server Key Exchange message. You need a special certificate for fixed DH. As the TLS specification says:

  The server key exchange message is sent by the server only when
  the server certificate message (if sent) does not contain enough
  data to allow the client to exchange a premaster secret.  This is
  true for the following key exchange methods:

       DHE_DSS
       DHE_RSA
       DH_anon

  It is not legal to send the server key exchange message for the
  following key exchange methods:

       RSA
       DH_DSS
       DH_RSA

Meaning of this message:

  This message conveys cryptographic information to allow the client
  to communicate the premaster secret: either an RSA public key with
  which to encrypt the premaster secret, or a Diffie-Hellman public
  key with which the client can complete a key exchange (with the
  result being the premaster secret).

The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...]

When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.

Note that certificates with DH parameters are rather rare anyway.

Stephen Henson (from OpenSSL) said the following (admittedly a long time ago):

I've asked all over the place and I've yet to see a single example of a DH certificate. From this I can conclude they aren't very common.

Nelson Bolyard (from Mozilla NSS) said the following more recently:

[...] I ask because I don't know of ANY public CA that issues such certs today. The last CA I knew of that did was the US DoD's CA that issued certificates for Fortezza cards.

I suspect there is little demand for these certificates. It would require more work from the CAs, it's just as easy to use EDH nowadays, and the cipher suites that can use them are not widely supported. The latest Java 7 list of supported cipher suites doesn't list any DH_RSA or DH_DSS cipher suites (only DH_anon and EDH).

share|improve this answer
    
For ephermal keyexchange I'd prefer ECDHE over DHE because it's significantly faster. So it's not really useful for that either. –  CodesInChaos Apr 26 '12 at 8:47
    
@CodeInChaos, you're right. What I said was more about the distinction between fixed and ephemeral DH, I would include ECDHE in the EDH family for this. –  Bruno Apr 26 '12 at 9:48
add comment

Your Answer

 
discard

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.