4
$\begingroup$

Say there are 2 sides that wish to communicate: side A and side B. Let's say we are looking at side A sending messages.

When establishing connection in SSL protocol, does the protocol always require that the message is first encrypted using side A's private key (so side B knows that only A could have encrypted it) and then is encrypted with B's public key ? So that only B could decrypt it ?

In what case would side A encrypt the message only with B's public key and then just send it ?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
6
$\begingroup$

You cannot "encrypt" with a private key.

Encryption provides confidentiality of the encrypted message.

If the public key performs decryption, and the public key is public, then anyone can decrypt the message. So "encrypt with the private key" is not possible.

This notion may be popular, but it is incorrect.

It stems from the fact that signing a message with textbook RSA is equivalent to public key encryption done in reverse. However, there are many problems with this:

  • Textbook RSA does not provide a secure signature/encryption scheme, and is not used
  • Padding and hashing ensure that the signature process is in fact not the same as the encryption process done in reverse.
  • Few, if any, other algorithms even operate in a similar manner. E.g. there exist signature schemes that you cannot encrypt with, and therefore signatures being "encrypting with the private key" is not even a vaguely correct analogy.

So your questions can be translated to something more accurate:

When establishing a connection in the SSL protocol, does the protocol always require that the message is first signed using side A's private key (so side B knows that only A could have signed it) and then is encrypted with B's public key so that only B could decrypt it?

When establishing a connection, it is assumed that A's public key is already signed by a certificate authority (that has vetted A's identity). First the certificate and public key are presented to B. B has the public verification key of the certificate authority pre-installed, and can use it to verify the signature on the certificate and public key. There is a nice outline of the process on our information security sister site.

In what case would side A encrypt the message only with B's public key and then just send it?

Situations where the message is not signed include:

  • Broken protocols vulnerable to man-in-the-middle attacks
  • When A and B already share public keys with each other
    • The initial key exchange could use signatures, but the actual messages sent back and forth may only use MACs rather than signatures.
  • When A desires deniability about having sent the message to B
Improve this answer
$\endgroup$
3
  • $\begingroup$ Note: The final list of situations may not be exhaustive $\endgroup$
    – Ella Rose
    Commented Dec 8, 2018 at 16:43
  • 1
    $\begingroup$ In that case, if there's a side C that performs man-in-the-middle attack and sends to B his public key (wishing to fool B into thinking it is A's public key) how can the CA know that C's generated fake key is not really A's public key ? How can the CA distinguish between side C (man in the middle) and side A if both A and C are not registered organizations but simply private home users ? Chances are, CA doesn't know A neither C so how can it sign at all ? $\endgroup$
    – caffein
    Commented Dec 8, 2018 at 16:57
  • $\begingroup$ @caffein I could have worded that part better: It should read that A's public key is already signed by the CA before any connections are ever established, I didn't mean to imply that it is signed by the CA when the connection is established. $\endgroup$
    – Ella Rose
    Commented Dec 8, 2018 at 22:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.