SSL - encrypt with private key and then with public key?
up vote
2
down vote
favorite
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 ?
public-key tls openssl
add a comment |
up vote
2
down vote
favorite
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 ?
public-key tls openssl
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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 ?
public-key tls openssl
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 ?
public-key tls openssl
public-key tls openssl
asked 2 days ago
caffein
183
183
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
5
down vote
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
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
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
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
add a comment |
up vote
5
down vote
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
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
add a comment |
up vote
5
down vote
up vote
5
down vote
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
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
edited 2 days ago
answered 2 days ago
Ella Rose
14.5k44076
14.5k44076
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
add a comment |
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
Note: The final list of situations may not be exhaustive
– Ella Rose
2 days ago
1
1
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 ?
– caffein
2 days ago
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 ?
– caffein
2 days ago
@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.
– Ella Rose
2 days ago
@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.
– Ella Rose
2 days ago
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64677%2fssl-encrypt-with-private-key-and-then-with-public-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown