# Why do we need asymmetric algorithms for key exchange?

In SSL protocols, both symmetric and asymmetric algorithms are used. Why is it so? The symmetric algorithms are more secure and easier to implement. Why are asymmetric algorithms usually preferred in key exchange?

-

Say you encrypt a message with a key $k$.

• With symmetric encryption (ie. symmetric ciphers), $k$ must be secret. The sender and recipient must agree (somehow) on $k$. No-one else can be allowed to find out $k$. Anyone else who finds out $k$, can decrypt all the messages encrypted with $k$. For that reason, symmetric ciphers are often called "secret key" ciphers - you have to keep the $k$s secret!

• Conversely - somewhat against common sense - with asymmetric encryption (ie. asymmetric ciphers), the encryption key $k$ is not secret. The recipient (not sender) chooses a so-called "public key" $k$, and a so-called "private key" $p$. Then they publish $k$ for all to see - perhaps on their website - but keep $p$ secret. Senders use $k$ to encrypt their messages to that recipient. You'd think, why can't other people use $k$ to decrypt all those messages? The answer is, that with asymmetric encryption, the public key $k$ will only encrypt - it won't decrypt. Only the private key $p$ will decrypt. And the recipient keeps $p$ secret. Since $k$ is not only public - but has to be public for all of this to work - asymmetric ciphers are often called "public key" ciphers.

The critical difference is this. Say you want to send me a message:

• With symmetric encryption, either (a) you choose a key, and send it securely to me, so I can decrypt the messsage with that key; or (b) I choose a key, and send it to you, so you can encrypt the message with that key. Either way, we need a secure communication channel, to get the key from one of us, to the other. But if we do have a secure communications channel, why encrypt the message at all? Why not just send it via that secure channel? If that channel is secure, we don't need to encrypt the message at all. But if that channel isn't secure, we can not safely share the encryption key $k$! This is called the "key exchange problem".

• With asymmetric encryption, we do not have that problem. I publish my public key for all to see. You encrypt your message with that key. Decrypting needs the private key. And only I have that! So we don't need a secure communication channel to exchange the encryption key.

In summary, symmetric encryption requires the sender and receiver to share a secret key. Achieving that safely, can be a real problem. Asymmetric encryption only requires the sender and receiver to share a public key. Achieving that safely, is much more straightforward.

Finally, as mikeazo said, asymmetric encryption is enormously slow, compared to symmetric encryption.

So, say you want to send me a very long message, using asymmetric encryption. Here's what you'd actually do:

(1) Pick a random key for use with a symmetric (fast) cipher. Encrypt your message using that (fast) cipher and key. Send me that encrypted message.

(2) Then use asymmetric (slow) encryption to encrypt the following message and send it to me:

 "Hi, I just sent you a message encrypted using the BLAH
symmetric cipher with key ABCDE123456."


Now I (the recipient) use my private key to decrypt (2). This gives me the information necessary to decrypt (1) - voila! Only a small amount of information was encrypted using asymmetric (slow) encryption. The bulk of the data was encrypted using symmetric (fast) encryption. And none of this data needed a secure channel. You could publish all of this data on the front page of the New York Times, with no loss of security.

-
Actually, you would normally send first the asymmetric message and then the symmetric one, so the recipient can start decrypting before she has to read the whole (long) encrypted message. –  Paŭlo Ebermann Feb 7 '12 at 8:37

To use a symmetric algorithm for encryption or key-exchange in a way that is secure (i.e. no observer can read the data), both parties (i.e. Alice and Bob) need to have some pre-existing common secret which is not known to any other party (i.e. Eve).

There are such pre-shared key algorithms, and they can be used with SSL. But they are not useful for the general internet SSL usage (i.e. HTTPS), since usually client and server don't have any common secrets.

Asymmetric algorithms like Diffie-Hellman or RSA key exchange allow the creation of such common secrets (and to be secure, only one of the partners - usually the server - needs an authenticated key, which can be done by the usual public-key infrastructure).

-

Actually there is a symmetric key exchange protocol named "Kerberos". It requires a trusted 3rd party, just like a Public Key Infrastructure (PKI) requires trusted certificate authorities (CA). There are some key differences:

1. A Kerberos server has to be online, serve requests and perform computations each time two peers are about to connect to each other. With a PKI the corresponding steps are performed by the peers themselves, once a year by the CA issuing certificates, and by the network OCSP server (or CRL repository).

2. To become a registered peer of a Kerberos network requires exchanging confidential information with the Kerberos ticket granting service. To become a peer of a network that is secured by a PKI requires exchanging authenticated information. It is often considered easier to establish an authentic communication channel than to establish a confidential communication channel, but even in the latter case it is more complicated than to just upload a public key to your web site.

-
In light of recent break-ins at root-level Certificate Authorities an effective argument could be made that Kerberos while less efficient is actually more secure than PKI because: (1). revoking trust is easier in Kerberos and (2). that Kerberos'es "online" requirements increase the complexity of attacks. Consider the case in which someone wishes to intercept a session secured by Kerberos. An impostor kerberos must be set up and it must quickly issue valid tickets for various domains or else cause very visible failures. –  Ethan Heilman Feb 10 '12 at 17:32

In addition to what Paulo said, symmetric encryption is much faster than asymmetric. Thus, it is typical to use asymmetric to exchange a symmetric key, then use the symmetric key to encrypt all the data. There is no way you could get over 15000 kbits/s (or over 8000 Mbits/s using a GPU) throughput using RSA.

Note that theoretically you could just use RSA to encrypt long messages, but it would be much less efficient for the reasons I stated above.

In summary, each type of encryption has its benefits. Asymmetric makes it quite easy to establish a shared key, but would be far to slow for encrypting large messages. Symmetric is very fast when encrypting large messages (comparatively), but cannot be used to share a secret key (unless you already have a shared secret key).

-

How would that work? I want to access Amazon securely using a symmetric algorithm. What do I use as the key?

Symmetric algorithms require a shared secret, something the two parties can know that no attacker can know. Without one, you need an asymmetric algorithm.

-