73

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

Community
  • 1
lurscher
  • 1,200
  • 1
  • 11
  • 15

3 Answers3

86

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.
user
  • 103
  • 4
AviD
  • 72,708
  • 22
  • 137
  • 218
  • 13
    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. – Thomas Pornin May 08 '11 at 12:06
  • 13
    asymetric encryption is about 1000 times slower, according to B.Schneier. http://math.uchicago.edu/~mann/encryption.pdf – ling Nov 27 '14 at 08:52
  • @ThomasPornin, Isn't that also part of point number 1? – Pacerier Mar 28 '15 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 Mar 28 '15 at 21:06
  • 1
    @Pacerier heh, no, I would say more 1) overhead, 2) not as strong, and 3) overhead :-) – AviD Mar 29 '15 at 07:45
  • If TLS used asymmetric encryption, would that mean it would necessarily have non-repuditiation (ie you could mathematically prove that some packet came from some specific server or a client)? https://security.stackexchange.com/questions/103645/does-ssl-tls-provides-non-repudiation-service? – Boris Verkhovskiy Oct 12 '17 at 03:44
  • @boris no, those points are not connected. See the accepted answer on your linked question. – AviD Oct 12 '17 at 19:43
35

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.

nealmcb
  • 20,693
  • 6
  • 71
  • 117
  • 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 May 08 '11 at 07: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 May 10 '11 at 08: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 Sep 30 '12 at 19:51
  • @fayyazkl, Oh my, what's the progress now after 3 years already? – Pacerier Mar 28 '15 at 21:07
  • @nealmcb, If the public key cryptography has already been broken, what use would having a quantum-resistant AES-256 do, since the attacker already has the key? – Pacerier Mar 28 '15 at 21:08
  • 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 Mar 29 '15 at 16:30
14

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:

Community
  • 1
Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180