Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I understand that when you want to encrypt and sign data with RSA the generally recommended approach is sign-then-encrypt.

However, I have encrypted data that I need to sign, to prove the author of the encrypted data.

  1. Encrypt wth recipient's public key
  2. Sign with author's private key
  3. Concatenate cipher text with signature

From reading papers such as this, it seems that the problems with sign-then-encrypt are quite subtle, but solutions are quite straightforwrd.

I haven't been able to turn up much on issues with encrypt-then-sign. I guess one problem is that someone could simply strip off the signature and replace it with their own. My first thought was to prefix the data with the author's public key before encrypting, but then the signature can only 'really' be verified by the recipient (public verification is more desirable for me).

What are the issues associated with encrypt-then-sign, and what solutions exist?

** Edit **

I thought of another potential solution to the problem of someone replacing the original signature with their own - using X.509 certificates. So in step 3 above we also concatenate the certificate of the author. When verifying the signature we check that the public key matches that of the certificate, and we also verify that the certificate was issued by a particular, trusted CA. With this scheme, not just anyone can replace the signature, only those who are issued a certificate from the trusted CA. Any issues with this approach?

share|improve this question
Another problem is that the recipient's public key needs to go into what's signed. $\hspace{1.32 in}$ – Ricky Demer Apr 27 '13 at 20:21
@RickyDemer I mention that in my question as a possible solution to the problem of someone replacing the signature – MurrayA Apr 27 '13 at 20:23
I see where you mention putting the author's public key into what's encrypted, $\hspace{1.62 in}$ but I don't see where you mentioned what I said. $\:$ – Ricky Demer Apr 27 '13 at 20:52
@RickyDemer sorry, I mis-read your comment - BTW, what is going on with the formatting of your last comment? – MurrayA Apr 27 '13 at 21:19
That's my attempt at making the lines have approximately the same length. – Ricky Demer Apr 27 '13 at 21:22

The primary problem with encrypt-then-sign (signing the ciphertext) relates to the difference between signing for the purpose of assigning responsibility vs for the purpose of taking credit. Encrypt-then-sign is OK for the former but not for the latter. The issue is quite subtle.

In particular, in your protocol, the recipient has no reason to believe the sender (signer) was ever aware of the contents of the plaintext. The signer must have been aware of the contents of the ciphertext and approved signing the ciphertext, but this does not mean that the signer knows or created the original message.

For instance, suppose we're using this to log into a site. Suppose Alice, who is a system administrator, is going to authenticate to Sam, who is a server. Suppose that, to authenticate, Alice is going to use your scheme to send a copy of the root password to Sam (encrypted and then signed); if everything checks out, Sam will conclude that Alice knows the root password and should be granted full access to the server. Sounds reasonable, right? But now look what can go wrong. Mallet can intercept Alice's encrypted-and-then-signed packet, strip off Alice's signature, append her own signature, and forward it to Sam. Sam will receive it and everything will check out: Sam can see that this was signed by Mallet and decrypts to contain the correct root password, so Sam will conclude that Mallet should be granted full access to the server. That's bad.

The reason why an attack is possible in the latter example is that Alice and Sam were using the signature as a basis for taking credit: Alice was trying to take credit for knowledge of the root password, and Sam was willing to accept the signature as evidence for that. However, encrypt-then-sign does not provide a basis for allowing the sender to take credit for knowledge of the contents of the message.

So, whether this scheme is adequate will depend upon the particular application you have. Many applications only need authentication for the purpose of assigning responsibility: if something goes wrong, we know who to hold responsible (or, we know whose account to charge or whose quota to decrement), and encrypt-then-sign is fine for that. But a few applications (the password authentication example I mentioned; auctions; and some others) use authentication to additionally allow the parties to take credit for knowledge of a message. For those applications, vanilla encrypt-then-sign can be problematic.

There are ways to fix encrypt-then-sign so it doesn't have this shortcoming. See the research literature below for details.

For more details on all of this, including what can go wrong as well as how to avoid these problems, you can read the following detailed explanation in the research literature:

share|improve this answer
Interesting papers that I hadn't come across before, thanks – MurrayA May 3 '13 at 17:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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