DH is vulnerable to a man-in-middle attack due to no server authentication; and RSA does not have forward secrecy.

People suggest used Ephemeral DH but what are the differences between Ephemeral DH and ordinary DH? Why it is more suitable? How about using the secure remote password protocol for key exchange?

In summary, which of these is better, and why:


  • 1
    @user236501 - it was mentioned in some of the other answers indirectly, but it is worth addressing directly. DH isn't vulnerable to a MitM attack as long as the server's public key is signed by a trusted third party (typically a certificate authority, but could also be a web of trust). Since the client encrypts their initial communication with the server's private key, only the genuine server (that holds the public key) can respond and only the client and server know that shared secret. – AJ Henderson Feb 8 '13 at 14:15

Perfect Forward Secrecy, in the context of TLS, means that the key used to actually decrypt things is not saved anywhere, and thus is immune to ulterior theft.

In plain DH suites, the server certificate contains the DH public key, and the corresponding private key is the one saved in a file somewhere on the server. If someone steals that key (e.g. from an old decommissioned hard disk, or a misplaced backup tape), then he can use it to decrypt past connections which he recorded (by passive eavesdropping on the line) before the theft of the key. The same issue applies to plain RSA cipher suites, which are much more common than plain DH (certificates containing a DH key are quite rare).

With DHE suites, the server certificates contains a RSA or DSA public key. When it starts (or upon every new connection), the server creates a new DH key pair which it keeps in RAM only. The server sends the DH public key as part of the TLS handshake, and it signs that public key with its DSA or RSA key (the one which it stores in a file). Our thieving attacker, once he got a copy of the RSA or DSA key, can forge signatures of his own, but he will not obtain the DH private key, since that one was not stored anywhere. Thus, DHE prevents the key thief from decrypting past sessions -- which is the point of PFS.

PFS is a desirable property (if only for public relations) so use DHE (or its elliptic curve variant ECDHE) when possible. It may use a little more CPU and bandwidth, but it would take hundreds or even thousands of new TLS sessions per second to notice the difference.

SRP is something completely different. It is a key exchange mechanism where there is no certificate at all. Instead, client and server share a common secret value, and mutually authenticate to each other with regards to that secret value. It is very nifty in that it tolerates quite well shared secrets of low entropy also known as "passwords" (contrary to "PSK" cipher suites which are simpler but need a high entropy shared secret). The main downside of SRP is that usual browsers do not support it (yet).

  • Hi, thanks for your answer, but said if I want create a remote desktop application using Java and I establish a TLS connection with SRP as key exchange mechanism. Is it possible since remote desktop application is not in web form, sound like SRP more suitable to use in web form authentication – user236501 Feb 8 '13 at 12:37
  • If you want to perform password-based authentication, you control both client and server code, and you can get TLS implementations which support SRP on both sides, then yes, by all means, use SRP. It will avoid all the certificate business. – Thomas Pornin Feb 8 '13 at 14:30
  • One more thing to clarify is that, said i using TLS-SRP connection, does this include authentication client already (I suppose it does since SRP) or just establish the secure channel only. I had studied about the RDP Protocol, it first establish a TLS channel and then using kerberos to authenticate user. I was thinking using SRP to authenticate the client and TLS to secure the channel prevent eavesdropping, man-in-middle attack. Some people suggested the TLS can used DHE_RSA to achieve forward secrecy. JSSE doesn't support TLS_SRP key exchange. Please correct me. Thanks – user236501 Feb 8 '13 at 14:58

For web applications I'd go with ECDHE_RSA as preferred exchange with DHE_RSA as fallback.

ECDHE is forward secure, efficient, and gives you a high confidentiality level (128 bit using P-256). DHE is slower and has a lower security, but some browsers (such as Opera) don't support ECC.

I'd still use RSA for authentication. The security level required for authentication is lower, 1024 bit RSA is good enough when used together with ECDHE. You might want to increase it a bit beyond 1024, but that's mostly about PR, and not about actual security.

With such suites you use PKI with RSA to ensure you're talking to the right server preventing MitM, and (EC)DH for the key exchange, giving you forward secrecy.

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.