symmetric encryption session keys in SSL/TLS

Question

This question concerns the session send and receive keys used in SSL/TLS protocol. my understanding is that this key uses symmetric encryption (DES, AES, BlowFish, etc.) I'm wondering, if public-private key pairs are superior to symmetric keys regarding key exchange security, why don't use asymmetric encryption for the session keys too?

this is an extension of an existing question: security of PKI, Certificates, certificate authorities, forward secrecy

Answer 1

3 reasons (now):

1. Asymmetric encryption is slower, much slower, than symmetric encryption. Orders of magnitude slower.
2. Given the same keylength, asymmetric is much weaker than symmetric, bit-for-bit. Therefore, you need a much larger key to provide equivalent protection. This also contributes to the slowness mentioned in 1.
3. (As per @ThomasPornin's comment:) Asymmetric encryption carries with it an increase in size of output. For instance, if you use RSA, encrypted data is at least 10% larger than the cleartext. Symmetric encryption, on the other hand, has a fixed size overhead even when encrypting gigabytes of data.

Answer 2

Asymmetric encryption algorithms are far less efficient than symmetric algorithms. So essentially all use of encryption via asymmetric keys involves encrypting a symmetric session key, with which the actual message is encrypted.

Besides AviD's helpful notes about key length, note that if quantum computing attacks become feasible, they will render all mainstream public-key algorithms (and thus SSL/TLS) ineffective. But straight AES-256 would remain strong even given a quantum computer attack. See Key size - Effect of Quantum Computing Attacks - Wikipedia. The question would then be back to how to exchange those keys and establish trust in them.

Answer 3

This is a standard approach, called a hybrid cryptosystem. Symmetric cryptography and asymmetric cryptography each have their strong and weak points. In particular:

• Asymmetric cryptography allows anyone to encrypt messages that only one participant will be able to decrypt, and allows anyone to verify messages that only one participant can have signed.
• Symmetric cryptography is a lot faster than asymmetric cryptography. Really, a lot.

Security isn't really a concern in the choice between symmetric and asymmetric cryptography. Asymmetric cryptography solves problems that symmetric cryptography cannot; for everything else, symmetric cryptography is used, because it's so much faster.

(As a consequence of being faster, symmetric cryptography does tend to have a higher security margin: common key sizes — 128-bit AES — are large enough that barring a completely novel mathematical breakthrough, all the computers currently existing on earth working for as long as the universe has existed would only have a tiny chance of breaking the encryption. Asymmetric cryptography runs on smaller margins due to its poor performance and there are occasional mathematical improvements in cracking methods that make commonly used key sizes ok for a few years but not necessarily for a few decades. But this is a secondary concern compared to the capabilities/performance alternative.)

Hybrid cryptosystems resolve the dilemma by using asymmetric cryptography only where it's needed:

• To verify the signature of a message, the message is hashed, and asymmetric cryptography is used only on the hash, not directly on the variable-length message.
• To encrypt some data, a symmetric session key is generated. Asymmetric cryptography is used to share this symmetric key between the participants (the client and the server). The “real” data is encrypted and authenticated using this symmetric key.

In HTTPS as it is commonly used on the web, the server has a public key, but the client doesn't — any browser can contact the server, the server doesn't care who the client is. (Client-side certificates are used where it makes sense.) A very high-level and incomplete view of an HTTPS session establishment is:

1. The server sends its certificate to the client. The certificate contains the public key of the server, and a signature of that public key by a certificate authority. The client verifies that the certificate authority is a known one (browsers ship with a list of certificate authorities' public keys).
2. The client and the server arrange to choose a symmetric key, in such a way that an attacker will not be able to reconstruct the key merely by inspecting the traffic or even by modifying it (or at least an active attacker will be detected and the client or the server will then abort the session). A Diffie-Hellman key exchange plus a signature by the server (to let the client verify that the exchange was conducted with the server, and not with a man-in-the-middle attacker) is one possibility to generate the symmetric key. It's also possible to rely solely on the server's private key (at the expense of not ensuring forward secrecy).
3. All subsequent communication uses that symmetric key.

Note that I made a lot of simplifications above. For more details, read:

• How does SSL/TLS work?
• How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?