Return to Answer

Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for a variety of historical and economical reasons, among which the main one is the availability of a free standard for RSA (PKCS#1) while the corresponding standard for Diffie-Hellman (x9.42) costs a hundred bucks, which is not much, but sufficient to deter most amateur developers.

Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for a variety of historical and economical reasons, among which the main one is the availability of a free standard for RSA (PKCS#1) while the corresponding standard for Diffie-Hellman (x9.42) costs a hundred bucks, which is not much, but sufficient to deter most amateur developers.

There is a well-known asymmetric encryption algorithm called RSA, though. With RSA, the sender can encrypt a message M with the recipient's public key, and the recipient can decrypt it and recover M using his private key. This time, the sender can choose the contents M. So your question might be: in a RSA world, why do we bother with AES at all  ? The answer lies in the following points:

• There are constraints on M. If the recipient's public key has size n (in bytes, e.g. n = 256 for a 2048-bit RSA key), then the maximum size of M is n-11 bytes. In order to encrypt a longer message, we would have to split it into sufficiently small blocks, and include some reassembly mechanism. Nobody really knows how to do that securely. We have good reasons to believe that RSA on a single message is safe, but subtle weaknesses can lurk in any split-and-reassembly system and we are not comfortable with that. It is already bad enough with symmetric ciphers, where the mathematical situation is simpler.

• Even if we could handle the splitting-and-reassembly, there would be a size expansion. With a 2048-bit RSA key, an internal message chunk has size at most 245 bytes, but yields, when encrypted, a 256-byte sequence. This wastes our lifeforce, i.e. network bandwidth. Symmetric encryption incurs only a bounded overhead (well, SSL adds a slight overhead proportional to the data size, but it is much smaller than what would occur with a RSA-only protocol).

• Compared to AES, RSA is slow as Hell.

• We really like to have the option of using key agreement protocols like DH instead of RSA. In older times (before 2001), RSA was patented but not DH, so the US government was recommending DH. Nowadays, we want to be able to switch algorithms in case one becomes broken. In order to support key agreement protocols, we need some symmetric encryption, so we may just as well use it with RSA. It simplifies implementation and protocol analysis.

There is a well-known asymmetric encryption algorithm called RSA, though. With RSA, the sender can encrypt a message M with the recipient's public key, and the recipient can decrypt it and recover M using his private key. This time, the sender can choose the contents of M. 

So your question might be: in an RSA world, why do we bother with AES at all? The answer lies in the following points:

• There are constraints on M. If the recipient's public key has size n (in bytes, e.g. n = 256 for a 2048-bit RSA key), then the maximum size of M is n-11 bytes. In order to encrypt a longer message, we would have to split it into sufficiently small blocks, and include some reassembly mechanism. Nobody really knows how to do that securely. We have good reasons to believe that RSA on a single message is safe, but subtle weaknesses can lurk in any split-and-reassemble system and we are not comfortable with that. It is already bad enough with symmetric ciphers, where the mathematical situation is simpler,

• Even if we could handle the splitting-and-reassembly, there would be a size expansion. With a 2048-bit RSA key, an internal message chunk has the size of at most 245 bytes, but when encrypted, it yields to be a 256-byte sequence. This wastes our life energy, i.e. the network bandwidth. Symmetric encryption incurs only a bounded overhead (well, SSL adds a slight overhead proportional to the data size, but it is much smaller than what would occur with a RSA-only protocol),

• Compared to AES, RSA is slow as hell,

• We really like to have the option of using key agreement protocols like DH instead of RSA. In older times (before 2001), RSA was patented but DH was not, so the US government was recommending DH. Nowadays, we want to be able to switch algorithms in case one becomes broken. In order to support key agreement protocols, we need some symmetric encryption, so we may just as well use it with RSA. It simplifies implementation and protocol analysis.

See this answer for a detailed description of how SSL works.

See this answer for a detailed description of how SSL works.