11

As far as I understand the workings of SSL - the client generates the pre-master secret and sends it to the server encrypted using the server's public key. Now, both parties perform some steps to generate the master secret and the session key. This session key is used for symmetric encryption from now on (e.g. communication in HTTPS).

My question is, given that we are sending the public key of the server to the client - and it is being authenticated and verified as well by using digital signatures of the Certificate Authorities - why don't we just use this public key for encryption?

Is it because asymmetric encryption is less efficient? Is this a trade-off between a one time less efficient operation (sending of pre-master secret and generating master secret) during handshake rather than multiple time asymmetric encryption? Any idea?

Clarification: My question doesn't suggest using asymmetric encryption for session keys instead i was asking about no session keys altogether, i.e. just use the public key sent to the client for encryption. See my answer to get what my question was.

RoraΖ
  • 12,317
  • 4
  • 51
  • 83
tapananand
  • 340
  • 3
  • 17
  • 1
    See also http://security.stackexchange.com/q/77260/971 and http://security.stackexchange.com/q/33434/971 and http://security.stackexchange.com/questions/3657/symmetric-encryption-session-keys-in-ssl-tls. You might also take a look at http://security.stackexchange.com/help/how-to-ask and take the opportunity to search the site for similar questions before asking next time. – D.W. Nov 09 '15 at 21:38
  • @D.W.: Sorry, but I am aware of the rules and etiquettes of stackexchange websites. None of the questions on this site addressed my doubt. – tapananand Nov 10 '15 at 03:41
  • 1
    While the referenced question are all about related topics, I don't think that any of them really addresses this question. – Neil Smithline Nov 10 '15 at 06:34
  • 1
    Let's look at the questions. "Is it because asymmetric encryption is less efficient?" Answered [here](http://security.stackexchange.com/a/3661/971): "Asymmetric encryption is slower, much slower..." [..] "Asymmetric encryption carries with it an increase in size of output". And answered [here](http://security.stackexchange.com/a/33438/971): "One reason that you normally don't see RSA used for larger amounts of data is because..." If you think there is some aspect of the question that isn't covered by those, please edit the question to clarify what this is asking and how it's different. – D.W. Nov 10 '15 at 07:22
  • @D.W.: The actual question has already been made bold via an edit. May be you should start from there. Is it because asymmetric encryption is less efficient? - This was just a guess towards a possible answer of my question. I already know it's slower. – tapananand Nov 10 '15 at 08:12

3 Answers3

17

There are several reasons for this. The main one is performance: asymmetrical encryption is SLOW.

In addition, many such algorythm have a fixed maximum size for the data they can encrypt (RSA, as defined in PKCS#1, has a maximum of 245 bytes for commonly used key size).

Also, you cannot implement forward security this way: anyone obtaining a copy of the private key will be able to decrypt any past message.

Finally, there is simply the fact that it is more flexible to negotiate the encryption scheme that to force it to use the one that was used to sign the certificate.

Community
  • 1
Stephane
  • 18,557
  • 3
  • 61
  • 70
6

We simply cant do this. Let me explain:

If we use the public key for encryption the following problems will occur:

  1. Everything will work just fine from client to the server - the client will send the encrpyted message - the server will decrypt using it's private key.
  2. The problem will occur when the server has to send something - which key will it use for encryption - it cant use it's private key as its public key is out in the open.

One solution could be that client can also send its public key and server will encrypt using client's public key. Well, then it's better to use the current method instead of adding more steps to authenticate the client's public key. Plus it is vulnerable as explained here

Community
  • 1
tapananand
  • 340
  • 3
  • 17
  • Far from all clients have a ready-made public/private key pair. – user Nov 09 '15 at 18:37
  • @MichaelKjörling One couldn't be generated on the fly? – jpmc26 Nov 10 '15 at 00:38
  • @MichaelKjörling: Even if all clients have public-private key pairs - the server needs to authenitcate if the client public key was actually sent by the client - even more overhead. – tapananand Nov 10 '15 at 03:28
  • @jpmc26 Technically yes, of course. In practice, generating a public/private (RSA) key pair of decent length is a rather lengthy operation that requires a fair bit of entropy, so it's not something you want to do if it isn't needed. – user Nov 10 '15 at 08:17
1

According to this answer, the point is not that asymmetric encryption would be "less efficient", it is just that it has different properties, and therefore different uses than symmetric encryption.

SSL requiring properties from both worlds, so it naturally combines asymmetric and symetric ciphers.

Community
  • 1
WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104