SSL - encrypt with private key and then with public key?
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
asked Dec 8 '18 at 16:24
caffein
334
add a comment |
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
asked Dec 8 '18 at 16:24
caffein
334
add a comment |
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
asked Dec 8 '18 at 16:24
caffein
334
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 Dec 8 '18 at 16:24
caffein
334
asked Dec 8 '18 at 16:24
caffein
334
asked Dec 8 '18 at 16:24
caffein
334
asked Dec 8 '18 at 16:24
caffein
334
asked Dec 8 '18 at 16:24
caffein
334
334
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
add a comment |
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
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
add a comment |
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
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
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
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
edited Dec 8 '18 at 22:38
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
answered Dec 8 '18 at 16:43
Ella Rose♦
15.3k44279
15.3k44279
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
add a comment |
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
Note: The final list of situations may not be exhaustive
– Ella Rose♦
Dec 8 '18 at 16:43
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
Dec 8 '18 at 16:57
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
Dec 8 '18 at 16:57
@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♦
Dec 8 '18 at 22:37
@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♦
Dec 8 '18 at 22:37
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
