0

I'm just struggling to get my head around this.

In certificate signing with static Diffie Hellman the public key and certificate information is sent to the CA who verifies the certificate information, and encrypts the certificate information including the public key with his private key. The public key of the CA is distributed such that a encrypted certificate can be verified by performing the decryption, and checking the contents of the certificate.

However in DHE the Private Public key is always regenerated for each handshake. I understand that this now means the authorisation can now no longer be achieved and that other methods of authorisation are required e.g. ECDSA. So what does the CA now sign (e.g the public key part), to give authentication?

1

(Certificates are not "encrypted", they are signed. Signatures are not the same as encryption. Describing signatures as "encryption with the private key" is a flawed analogy which does not work with non-RSA signature algorithms, and does not work well with RSA either, and it only leads to confusion. Let's use the proper terminology.)

In DHE, the SSL server has a certificate, issued (signed) by a CA, and containing a public key which is apt for signatures (e.g. RSA, DSA, ECDSA...). The server sends that certificate to the client, along with the newly-generated DH parameters, that the server signs with that key.

In static DH, the client verifies that the DH public key is part of a certificate signed by the CA, and bearing the intended server name. With DHE, the client verifies that the DH public key is signed relatively to a signature public key, which is contained in a certificate signed by the CA and bearing the intended server name. DHE implies one more level of signing, but it still ultimately links to the CA system.

(In practice, static DH is exceedingly rare; everybody uses RSA for certificates.)

0

It may be more reasonable to refer to ElGamal at this point, which you can think of as "delayed Diffie-Hellman" an does what you describe as "static Diffie-Hellman". The way it works is basically as follows

You generate secret/public long-term keypair LTsec and LTpub

You send LTpub to a CA, which may contact you by telephone or anything else to verify that you are really you. Once the verification is done they sign LTpub. That means you get a signed certificate which consists of your public key and the CA's signature:

(new) LTpub = (LTpub, CAsig of LTpub)

You can then use that to authenticate yourself or your server or whatever you want. You may for example let your webserver at www.example.com authenticate with that certificate. When John connects to that server and wants to use DH Key Agreement that happens (simplified):

John generates a new ephemeral DH keypair (Jpub, Jsec) and sends the public part to the webserver

 John  -----       Jpub     -----> Webserver

The webserver generates a new ephmeral DH keypair (Wsec, Wpub) and sends the public part to John. It also signs Wpub with LTsec from above.

                   Wpub
 John  <---- SIGN_LTsec(Wpub) ---- Webserver
                   LTpub

Now John can now do certain things:

  • John can now verify that Wpub was generated from someone who possesses LTsec (important!).
  • John can also verify that the one who possesses LTsec is the one who generated LTpub.
  • John can also verify that LTpub was verified by a CA.
  • John can now assume that a CA once verified the information in LTpub by a telephone call (or whatever) and that the issuer is who he proposes to be (here: www.example.com)
  • Finally John can resonably assume that he shares a key (Wpub^Jsec) with www.example.com

Of course this is only a very basic overview of the trust relationship and technical details.

After all, take a closer look at ElGamal for more technical information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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