What is the best way to sign a message using RSA?











up vote
5
down vote

favorite
1












I was preparing for competitive exam, and I came across this question. I had a lot of discussion with my friends before I resorted to posting it here and I wanted myself to be clear on this.





Let $M$ be a confidential email that Alice wants to send to Bob, $K_B$ be Bob’s encryption public key, and $K_A^{-1}$ be Alice’s private key for signing. Which of the following options would be the best choice for protecting confidential emails?



(A) Send $E_{K_{B}}(M),Sign_{K_A^{-1}}(K_B)$



(B) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(M)$



(C) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(E_{K_B}(M))$



(D) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(K_{A}^{+1}(M))$





I marked (B), but correct answer is given to be (C).



I understand the first part, that we are encrypting the message with Bob’s public key, but my understanding says, that we sign the message using Alice’s private key and send it to Bob along with the encrypted message.



But seems like option (C) says that along encrypted message, Alice should sign the encrypted message and then should send this signature along with the encrypted message to Bob.



My query is as per option (C), Why are we signing the whole encrypted message instead of the original message as shown in (B).










share|improve this question









New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
    – kelalaka
    Nov 28 at 11:20










  • @Kelalaka-didn't get you.
    – user3767495
    Nov 28 at 11:23






  • 1




    The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
    – kelalaka
    Nov 28 at 11:24








  • 2




    @user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
    – Maarten Bodewes
    Nov 28 at 12:42















up vote
5
down vote

favorite
1












I was preparing for competitive exam, and I came across this question. I had a lot of discussion with my friends before I resorted to posting it here and I wanted myself to be clear on this.





Let $M$ be a confidential email that Alice wants to send to Bob, $K_B$ be Bob’s encryption public key, and $K_A^{-1}$ be Alice’s private key for signing. Which of the following options would be the best choice for protecting confidential emails?



(A) Send $E_{K_{B}}(M),Sign_{K_A^{-1}}(K_B)$



(B) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(M)$



(C) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(E_{K_B}(M))$



(D) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(K_{A}^{+1}(M))$





I marked (B), but correct answer is given to be (C).



I understand the first part, that we are encrypting the message with Bob’s public key, but my understanding says, that we sign the message using Alice’s private key and send it to Bob along with the encrypted message.



But seems like option (C) says that along encrypted message, Alice should sign the encrypted message and then should send this signature along with the encrypted message to Bob.



My query is as per option (C), Why are we signing the whole encrypted message instead of the original message as shown in (B).










share|improve this question









New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
    – kelalaka
    Nov 28 at 11:20










  • @Kelalaka-didn't get you.
    – user3767495
    Nov 28 at 11:23






  • 1




    The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
    – kelalaka
    Nov 28 at 11:24








  • 2




    @user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
    – Maarten Bodewes
    Nov 28 at 12:42













up vote
5
down vote

favorite
1









up vote
5
down vote

favorite
1






1





I was preparing for competitive exam, and I came across this question. I had a lot of discussion with my friends before I resorted to posting it here and I wanted myself to be clear on this.





Let $M$ be a confidential email that Alice wants to send to Bob, $K_B$ be Bob’s encryption public key, and $K_A^{-1}$ be Alice’s private key for signing. Which of the following options would be the best choice for protecting confidential emails?



(A) Send $E_{K_{B}}(M),Sign_{K_A^{-1}}(K_B)$



(B) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(M)$



(C) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(E_{K_B}(M))$



(D) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(K_{A}^{+1}(M))$





I marked (B), but correct answer is given to be (C).



I understand the first part, that we are encrypting the message with Bob’s public key, but my understanding says, that we sign the message using Alice’s private key and send it to Bob along with the encrypted message.



But seems like option (C) says that along encrypted message, Alice should sign the encrypted message and then should send this signature along with the encrypted message to Bob.



My query is as per option (C), Why are we signing the whole encrypted message instead of the original message as shown in (B).










share|improve this question









New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I was preparing for competitive exam, and I came across this question. I had a lot of discussion with my friends before I resorted to posting it here and I wanted myself to be clear on this.





Let $M$ be a confidential email that Alice wants to send to Bob, $K_B$ be Bob’s encryption public key, and $K_A^{-1}$ be Alice’s private key for signing. Which of the following options would be the best choice for protecting confidential emails?



(A) Send $E_{K_{B}}(M),Sign_{K_A^{-1}}(K_B)$



(B) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(M)$



(C) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(E_{K_B}(M))$



(D) Send $E_{K_B}(M),Sign_{K_{A}^{-1}}(K_{A}^{+1}(M))$





I marked (B), but correct answer is given to be (C).



I understand the first part, that we are encrypting the message with Bob’s public key, but my understanding says, that we sign the message using Alice’s private key and send it to Bob along with the encrypted message.



But seems like option (C) says that along encrypted message, Alice should sign the encrypted message and then should send this signature along with the encrypted message to Bob.



My query is as per option (C), Why are we signing the whole encrypted message instead of the original message as shown in (B).







rsa






share|improve this question









New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Nov 28 at 12:40









Maarten Bodewes

51.9k675189




51.9k675189






New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 28 at 11:14









user3767495

261




261




New contributor




user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






user3767495 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
    – kelalaka
    Nov 28 at 11:20










  • @Kelalaka-didn't get you.
    – user3767495
    Nov 28 at 11:23






  • 1




    The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
    – kelalaka
    Nov 28 at 11:24








  • 2




    @user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
    – Maarten Bodewes
    Nov 28 at 12:42


















  • perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
    – kelalaka
    Nov 28 at 11:20










  • @Kelalaka-didn't get you.
    – user3767495
    Nov 28 at 11:23






  • 1




    The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
    – kelalaka
    Nov 28 at 11:24








  • 2




    @user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
    – Maarten Bodewes
    Nov 28 at 12:42
















perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
– kelalaka
Nov 28 at 11:20




perefer to use $pub_A$ and $priv_B$ or $A_{pub}, A_{prv}$ to represent the keys?
– kelalaka
Nov 28 at 11:20












@Kelalaka-didn't get you.
– user3767495
Nov 28 at 11:23




@Kelalaka-didn't get you.
– user3767495
Nov 28 at 11:23




1




1




The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
– kelalaka
Nov 28 at 11:24






The inverse, -1, is not comment to represent the private and public keys, and what is +1 then. and you can use numbered lists
– kelalaka
Nov 28 at 11:24






2




2




@user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
– Maarten Bodewes
Nov 28 at 12:42




@user3767495 You are completely fine with asking such questions here, as long as you've shown incentive to solve the issue, which you clearly did. It is a good sign that you questioned the given answer.
– Maarten Bodewes
Nov 28 at 12:42










2 Answers
2






active

oldest

votes

















up vote
5
down vote













Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.



Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt unauthenticated ciphertext.



Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.



Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it.





Option B is an encrypt-and-sign scheme, option C is an encrypt-then-sign scheme.



Generally we use a (missing) sign-then-encrypt scheme where we send $E_{K_B}(M, text{Sign}_{K_{A}^{-1}}(M))$. Obviously sign-then-encrypt should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.



Now that you know the terms you can look up Q/A and discussions such as the one here. Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.





EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C marginally better.






share|improve this answer























  • A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
    – kasperd
    Nov 28 at 17:27










  • True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
    – Maarten Bodewes
    Nov 28 at 17:36








  • 1




    I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
    – fgrieu
    Nov 28 at 17:50












  • @fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
    – Maarten Bodewes
    Nov 28 at 21:34




















up vote
1
down vote













Most common symmetric-key modes of operations and AEAD algorithms operates in Encrypt-the-MAC fashion, so similarly, one better use encrypt-then-sign paradigm.



All of the choices correctly stated that one should use Bob's public key to encrypt, so the only question remains is how to sign.



Remove A from consideration immediately as you realize that protects not the integrity&authenticity of $M$ but Bob's public key. Also remove D from consideration as that's a bad case of reusing signing key for encryption.



Choice B may have some problem if the signature can be used to recover the message (e.g. Unhashed), so it may be bad for confidentiality in some cases.



So go with C.






share|improve this answer





















  • @DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
    – user3767495
    Nov 28 at 11:30










  • @user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
    – DannyNiu
    Nov 28 at 14:28











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',
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
});


}
});






user3767495 is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64383%2fwhat-is-the-best-way-to-sign-a-message-using-rsa%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote













Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.



Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt unauthenticated ciphertext.



Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.



Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it.





Option B is an encrypt-and-sign scheme, option C is an encrypt-then-sign scheme.



Generally we use a (missing) sign-then-encrypt scheme where we send $E_{K_B}(M, text{Sign}_{K_{A}^{-1}}(M))$. Obviously sign-then-encrypt should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.



Now that you know the terms you can look up Q/A and discussions such as the one here. Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.





EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C marginally better.






share|improve this answer























  • A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
    – kasperd
    Nov 28 at 17:27










  • True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
    – Maarten Bodewes
    Nov 28 at 17:36








  • 1




    I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
    – fgrieu
    Nov 28 at 17:50












  • @fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
    – Maarten Bodewes
    Nov 28 at 21:34

















up vote
5
down vote













Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.



Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt unauthenticated ciphertext.



Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.



Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it.





Option B is an encrypt-and-sign scheme, option C is an encrypt-then-sign scheme.



Generally we use a (missing) sign-then-encrypt scheme where we send $E_{K_B}(M, text{Sign}_{K_{A}^{-1}}(M))$. Obviously sign-then-encrypt should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.



Now that you know the terms you can look up Q/A and discussions such as the one here. Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.





EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C marginally better.






share|improve this answer























  • A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
    – kasperd
    Nov 28 at 17:27










  • True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
    – Maarten Bodewes
    Nov 28 at 17:36








  • 1




    I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
    – fgrieu
    Nov 28 at 17:50












  • @fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
    – Maarten Bodewes
    Nov 28 at 21:34















up vote
5
down vote










up vote
5
down vote









Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.



Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt unauthenticated ciphertext.



Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.



Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it.





Option B is an encrypt-and-sign scheme, option C is an encrypt-then-sign scheme.



Generally we use a (missing) sign-then-encrypt scheme where we send $E_{K_B}(M, text{Sign}_{K_{A}^{-1}}(M))$. Obviously sign-then-encrypt should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.



Now that you know the terms you can look up Q/A and discussions such as the one here. Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.





EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C marginally better.






share|improve this answer














Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.



Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt unauthenticated ciphertext.



Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.



Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it.





Option B is an encrypt-and-sign scheme, option C is an encrypt-then-sign scheme.



Generally we use a (missing) sign-then-encrypt scheme where we send $E_{K_B}(M, text{Sign}_{K_{A}^{-1}}(M))$. Obviously sign-then-encrypt should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.



Now that you know the terms you can look up Q/A and discussions such as the one here. Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.





EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C marginally better.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 28 at 16:05

























answered Nov 28 at 12:01









Maarten Bodewes

51.9k675189




51.9k675189












  • A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
    – kasperd
    Nov 28 at 17:27










  • True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
    – Maarten Bodewes
    Nov 28 at 17:36








  • 1




    I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
    – fgrieu
    Nov 28 at 17:50












  • @fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
    – Maarten Bodewes
    Nov 28 at 21:34




















  • A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
    – kasperd
    Nov 28 at 17:27










  • True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
    – Maarten Bodewes
    Nov 28 at 17:36








  • 1




    I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
    – fgrieu
    Nov 28 at 17:50












  • @fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
    – Maarten Bodewes
    Nov 28 at 21:34


















A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
– kasperd
Nov 28 at 17:27




A drawback of (B) is that it doesn't prove who Alice intended to send the message to. Unless M itself contains additional information about sender and receiver the first receiver of the signed message could decrypt it and reencrypt it for a different recipient and the original signature from Alice would remain valid. As far as (D) goes I think the wording in the question is ambiguous but it's possible to interpret the two operations involving $K_A$ as cancelling out, which would be bad.
– kasperd
Nov 28 at 17:27












True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
– Maarten Bodewes
Nov 28 at 17:36






True, that's a good point. I was skipping that part as there seems to be no notion of ID here in the question either. Generally you would at least include a sender & receiver in the (encoding of) the message / protocol. Not such a big issue as the replacement of the signature, but still something to think about. I guess the question is kind of an oversimplification.
– Maarten Bodewes
Nov 28 at 17:36






1




1




I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
– fgrieu
Nov 28 at 17:50






I'm not sure about what you have in mind with "It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message". I see that the signature can be replaced and the message appear to be from other than Alice; and that a new public key could be crafted that also verifies the existing signature. However I see no case where Bob would wrongly accept a message as approved by the entity associated to the public key against which the message is verified, which is how an attack on authenticity is defined, right?
– fgrieu
Nov 28 at 17:50














@fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
– Maarten Bodewes
Nov 28 at 21:34






@fgrieu Possibly this is not how an attack is defined, but the fact that you can send a message from Alice and replace the signature to show that it was signed by Mallory can certainly be an issue in real life. Note that this would not be possible - or at least much harder - for sign-then-encrypt, in which the message and the signature stays confidential. Hopefully the message itself contains information that indicates who created the signature, making the resigning a moot point as the information in the message and the (certificate of) the public key would differ.
– Maarten Bodewes
Nov 28 at 21:34












up vote
1
down vote













Most common symmetric-key modes of operations and AEAD algorithms operates in Encrypt-the-MAC fashion, so similarly, one better use encrypt-then-sign paradigm.



All of the choices correctly stated that one should use Bob's public key to encrypt, so the only question remains is how to sign.



Remove A from consideration immediately as you realize that protects not the integrity&authenticity of $M$ but Bob's public key. Also remove D from consideration as that's a bad case of reusing signing key for encryption.



Choice B may have some problem if the signature can be used to recover the message (e.g. Unhashed), so it may be bad for confidentiality in some cases.



So go with C.






share|improve this answer





















  • @DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
    – user3767495
    Nov 28 at 11:30










  • @user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
    – DannyNiu
    Nov 28 at 14:28















up vote
1
down vote













Most common symmetric-key modes of operations and AEAD algorithms operates in Encrypt-the-MAC fashion, so similarly, one better use encrypt-then-sign paradigm.



All of the choices correctly stated that one should use Bob's public key to encrypt, so the only question remains is how to sign.



Remove A from consideration immediately as you realize that protects not the integrity&authenticity of $M$ but Bob's public key. Also remove D from consideration as that's a bad case of reusing signing key for encryption.



Choice B may have some problem if the signature can be used to recover the message (e.g. Unhashed), so it may be bad for confidentiality in some cases.



So go with C.






share|improve this answer





















  • @DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
    – user3767495
    Nov 28 at 11:30










  • @user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
    – DannyNiu
    Nov 28 at 14:28













up vote
1
down vote










up vote
1
down vote









Most common symmetric-key modes of operations and AEAD algorithms operates in Encrypt-the-MAC fashion, so similarly, one better use encrypt-then-sign paradigm.



All of the choices correctly stated that one should use Bob's public key to encrypt, so the only question remains is how to sign.



Remove A from consideration immediately as you realize that protects not the integrity&authenticity of $M$ but Bob's public key. Also remove D from consideration as that's a bad case of reusing signing key for encryption.



Choice B may have some problem if the signature can be used to recover the message (e.g. Unhashed), so it may be bad for confidentiality in some cases.



So go with C.






share|improve this answer












Most common symmetric-key modes of operations and AEAD algorithms operates in Encrypt-the-MAC fashion, so similarly, one better use encrypt-then-sign paradigm.



All of the choices correctly stated that one should use Bob's public key to encrypt, so the only question remains is how to sign.



Remove A from consideration immediately as you realize that protects not the integrity&authenticity of $M$ but Bob's public key. Also remove D from consideration as that's a bad case of reusing signing key for encryption.



Choice B may have some problem if the signature can be used to recover the message (e.g. Unhashed), so it may be bad for confidentiality in some cases.



So go with C.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 28 at 11:28









DannyNiu

997425




997425












  • @DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
    – user3767495
    Nov 28 at 11:30










  • @user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
    – DannyNiu
    Nov 28 at 14:28


















  • @DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
    – user3767495
    Nov 28 at 11:30










  • @user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
    – DannyNiu
    Nov 28 at 14:28
















@DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
– user3767495
Nov 28 at 11:30




@DannyNiu-As far as I Know, signature is one-way Hash of the message right? Can signature be used to recover message?How? And, wouldn't be it an overhead to first encrypt the message and then sign it?
– user3767495
Nov 28 at 11:30












@user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
– DannyNiu
Nov 28 at 14:28




@user3767495 Signature is actually a cryptographic so-called "binding" between the private signing key and the message, verifiable through the public key, it's not always the one-way hash of the message, as examplified in CRYSTAL-DILITHIUM. The recovery can be achieved as described by Maarten by guessing. The overhead is negligable in most real-world use cases.
– DannyNiu
Nov 28 at 14:28










user3767495 is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















user3767495 is a new contributor. Be nice, and check out our Code of Conduct.













user3767495 is a new contributor. Be nice, and check out our Code of Conduct.












user3767495 is a new contributor. Be nice, and check out our Code of Conduct.
















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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64383%2fwhat-is-the-best-way-to-sign-a-message-using-rsa%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

QoS: MAC-Priority for clients behind a repeater

Ивакино (Тотемский район)

Can't locate Autom4te/ChannelDefs.pm in @INC (when it definitely is there)