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

3 Answers 3


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.
  • 14
    Another important point is that asymmetric encryption implies an increase in data length. 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. Commented May 8, 2011 at 12:06
  • 14
    asymetric encryption is about 1000 times slower, according to B.Schneier. math.uchicago.edu/~mann/encryption.pdf
    – ling
    Commented Nov 27, 2014 at 8:52
  • @ThomasPornin, Isn't that also part of point number 1?
    – Pacerier
    Commented Mar 28, 2015 at 21:04
  • @AviD, So are your three points basically saying 1) it's slow, 2) it's slow, and 3) it's slow
    – Pacerier
    Commented Mar 28, 2015 at 21:06
  • 1
    @Pacerier heh, no, I would say more 1) overhead, 2) not as strong, and 3) overhead :-)
    – AviD
    Commented Mar 29, 2015 at 7:45

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.

  • 3
    LOL, though this is true enough, Quantum computing always makes me laugh... Though of course I realize that it's probably just a question of time...
    – AviD
    Commented May 8, 2011 at 7:20
  • 1
    Shor's algorithm sounds quite remarkable! Best quote from the wikipedia article on it: another way to explain Shor's algorithm is by noting that it is just the quantum phase estimation algorithm in disguise... well, of course! :-)
    – Rory Alsop
    Commented May 10, 2011 at 8:23
  • 1
    Reading this approximately 17 months latter, coincidentally i just read this morning that at University of New South Whales, Australia, a major break through has been made in production of quantum computers. It is said a key component has been successfully designed using the existing development methods used by semiconductor industry
    – fkl
    Commented Sep 30, 2012 at 19:51
  • @fayyazkl, Oh my, what's the progress now after 3 years already?
    – Pacerier
    Commented Mar 28, 2015 at 21:07
  • 1
    @Pacerier Good point. I'm not suggesting that the current SSL/TLS design would work if quantum computing broke public key cryptography. I edited the answer.
    – nealmcb
    Commented Mar 29, 2015 at 16:30

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:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .