# How to correctly evaluate the security of DH in TLS

I'm trying to understand and evaluate the security impact of DH in TLS.

As far as I can tell, there are four major different implementations of DH in TLS.

• DH
• DHE
• ECDH
• ECDHE

With the ephemeral DH's, forward secrecy is possible, which I consider a huge bonus to security.

What I'm not too sure about is the elliptic curve part. With elliptic curves, the public certificate (?), used for DH, can be smaller than without elliptic curves and still be considered secure.

I have something in my mind like, non-elliptic-curve DH should have at least 2048 bit, to be considered secure.

Is my information correct?

How can I determine the key length (or public certificate size, I'm not sure what exactly I'm looking for here), of my server?

Can I use the information from the .pem file, used for DH (see comment below)?

openssl dhparam -inform PEM -in ./file.pem -check -text
DH Parameters: (4096 bit)
prime:
[...]
generator: 2 (0x2)
DH parameters appear to be ok.
-----BEGIN DH PARAMETERS-----
[...]
-----END DH PARAMETERS-----


So in this case the DH key length/public certificate size would be 4096, correct?

With elliptic curves, the public certificate (?), used for DH, can be smaller than without elliptic curves and still be considered secure.

Yes, you can achieve the same level of security with shorter keys and thus shorter certificates with EC-based crypto and as an additional bonus: we tend to encode the full field (ie order, prime, generator) for standard DH but only a name (an OID to be precise) for elliptic curves.

I have something in my mind like, non-elliptic-curve DH should have at least 2048 bit, to be considered secure.

Is my information correct?

Yes, standard key size considerations (based on the GNFS) apply to finite-field DH.

So in this case the DH key length/public certificate size would be 4096, correct?

Yes, the size of the public key / the field prime is 4096 bit, the size of an actual DH certificate would be quite a bit larger though, due to the additional encoding of owner information, issuing CA information, field information, ...

Chances are that you are actually looking at your server's DH parameters that are used for the ephemeral key exchange.

• Thank you for the elaboration! I've recently learned that with ECDH/ECHDE the DH parameters are not required, but the ECC key/certificate pair. Is that right? – SaAtomic Jul 26 '17 at 10:49
• @SaAtomic yes, with ECDHE you don't need a DH parameter file, because the server will just send the appropriate name of the curve instead. If you want to use static (EC)DH, you do need a static (EC)DH certificate (which are extremely rare!) signed by some CA. Note that the more common ECDSA certificates (which contain an ECC key pair) are unrelated and can be combined with DHE or ECDHE key exchange. – SEJPM Jul 26 '17 at 10:54
• How do these TLS cipher suites (with (EC)DH) work with OpenVPN? As far as I know, no static (EC)DH certificate is manually created/configured. In connection with ECDSA this is created by the ECDSA, correct? But what about TLS-ECDH-RSA-WITH-AES-256-CBC-SHA for example? – SaAtomic Jul 26 '17 at 11:30
• @SaAtomic I'd guess that the system will cache the (EC)DH key and re-use it for many connections, the ECDSA / RSA portion is then only there to assure the authenticity of the received (EC)DH public key. – SEJPM Jul 26 '17 at 11:45
• @SaAtomic normally, libraries and applications are designed such that you, as an end-user, need to supply at most key-pair and the certificate for the authentication key pair (ie the RSA / ECDSA one usually). However I wouldn't be surprised if it was at least optional to also supply your own ECDH keypair (eg for banks who need to monitor all their own traffic). – SEJPM Jul 26 '17 at 20:34