Tell me more ×
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.
up vote 3 down vote favorite
2

We often want to send messages that are both (a) encrypted, so passive attackers can't discover the plaintext of the message, and (b) signed with a private-key digital signature, so active attackers can't trick Alice into thinking that some message came from Bob, when really the message is some (accidental or malicious) modification of a real message Bob sent, or a message that was forged out of whole cloth by an attacker.

Is it better to (a) generate the digital signature from the (hashed) plaintext, and then encrypt a file containing both the plaintext message and the digital signature? Or is it better to (b) encrypt the message first, and then generate a digital signature from the (hashed) encrypted file? Or (c) combine encryption and public-key digital signatures in some other way?

A closely related earlier question ( Should we MAC-then-encrypt or encrypt-then-MAC? ) seems to focus on symmetric-key MAC authentication. As Robert I. Jr. asked earlier, Do the same issues with (symmetric-key) MAC-then-encrypt apply to (public-key) sign-then-encrypt?

share|improve this question
1  
I'm for signing first, and then encrypting with symmetric authenticated encryption. – CodesInChaos Nov 22 '12 at 18:27
@DavidCary, I suspect it might help if you clarified: when you mention encryption, are you talking about public-key encryption, or symmetric-key encryption? I think only the former makes sense. Or, to put it another way: Do you assume Alice and Bob have already shared a symmetric key known only to them, or not? If you assume they have a symmetric key, there'd typically be no reason to use a digital signature -- so I presume you must be starting from the assumption that they don't already have a shared key, in which case we're talking about public-key signatures + public-key encryption. – D.W. Nov 23 '12 at 23:36

3 Answers

up vote 1 down vote

It depends on your requirement,

  • If you Sign-then-encrypt then only receiver can decrypt and then
    verify .
  • If encrypt-then-sign then anybody can verify the
    authenticity and only receiver can decrypt it .

But in practice, both are not enough , ideally We have to sign-encrypt-sign , am not able to recollect the paper which discusses this

There is one more paper that is popular and discusses this issue in general

share|improve this answer
"If encrypt-then-sign then anybody can verify the authenticity" - Baloney. All that a third party can verify is that there is a signature on some random-looking string, but there's no way to make sense of this (without cooperation from the recipient). This is not a useful capability. In particular, it is not reasonable to call this "verify[ing] the authenticity" of the message. – D.W. Nov 23 '12 at 23:28
"in practice, both are not enough" - False. Sign-the-encrypt is sufficient, if you include the prepend the identity of the recipient before signing. See my answer. (Sign-encrypt-sign is not necessary -- and indeed, in practice no deployed system that I'm familiar with uses sign-encrypt-sign.) – D.W. Nov 23 '12 at 23:30
1  
@D.W , in encrypt-then-sign, If i encrypt with receivers public key and sign with my private key, then anybody knowing my public key ( say some auditor or a proxy agent) can first verify the signature for authenticity ( and drop it if does not match ) but only receiver can actually decrypt it – sashank Nov 24 '12 at 0:44
sashank, in my experience it is very rare for there to be any value in verifying that a signature is valid without being able to verify the contents of the message. (As far as auditing, in my experience any auditor is going to demand to see the contents of the message.) – D.W. Nov 24 '12 at 1:12
up vote -2 down vote

The only difference between this approaches is hiding information about sender. If you don't want attackers know who is signer, you need to sign-then-encrypt. In another case it doesn't matter.

share|improve this answer
There might be a successful chosen ciphertext attack against sign-then-encrypt. $\hspace{1.4 in}$ – Ricky Demer Nov 23 '12 at 8:02
@Ricky Demer: How can attacker get a plain text? There are no conditions for chosen ciphertext model. – Pavel Ognev Nov 23 '12 at 8:31
For example, it might be easy to come up with a ciphertext whose decryption is the result $\hspace{1 in}$ of setting the $n$th bit in the original plaintext to zero. $\:$ – Ricky Demer Nov 23 '12 at 8:38
If attacker change the ciphertext somehow, the decrypted text will be changed too and signature verification will fail. – Pavel Ognev Nov 23 '12 at 10:57
1  
@RickyDemer, regarding your comment "There might be a successful chosen ciphertext attack against sign-then-encrypt." - Not if you use a IND-CCA2-secure encryption scheme and a UF-CMA-secure signature scheme, and if you prepend the recipient's identity first. See my answer. (In general, the quality of technical analysis in this comment thread is low, and many comments seem to lack familiarity with the relevant technical literature, so I would caution by-standers to take what you read with a grain of salt.) – D.W. Nov 23 '12 at 23:32
show 8 more comments
up vote 4 down vote

Assuming you are asking about public-key signatures + public-key encryption:

Short answer: I recommend sign-then-encrypt, but prepend the recipient's name to the message first.

Long answer: When Alice wants to send an authenticated message to Bob, she should sign and encrypt the message. In particular, she prepends Bob's name to the message, signs this using her private key, appends her signature to the message, encrypts the whole thing under Bob's public key, and sends the resulting ciphertext to Bob. Bob can decrypt, verify the signature, and confirm that this indeed came from Alice (or someone she shared her private key with). Make sure you use an IND-CCA2-secure public-key encryption scheme and a UF-CMA-secure public-key signature scheme (i.e., one that is secure against existential forgery attack).

Justification: The reason to do this is to defeat some subtle attacks. These attacks are not necessarily a problem in all scenarios, but it's best to harden the approach as much as possible. A complete explanation would take more space than is available here, but see below for a sketch of the reasoning.

For a detailed analysis about whether to sign first or encrypt first, the following is a good resource: Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.

I don't recommend encrypt-then-sign. It could work, but it has some subtle pitfalls in some contexts, because the signature does not prove that the sender was aware of the context of the plaintext. For instance, suppose Alice's SSH client sends the message "Dear SSH server, please append my public key to /root/.ssh/authorized_keys -- and you can know that I am authorized because I know the root password is lk23jas0" (encrypted then signed with Alice's public key), and the SSH server acts on it if the root password is correct. Then Eve can eavesdrop, capture this message, strip off Alice's signature, sign the ciphertext with Eve's own key, and send it to the SSH server, obtaining root-level access even though Eve didn't know the root password.

share|improve this answer
I notice you write "IND-CCA2-secure public-key encryption". $\:$ Is this as opposed to $\hspace{1.6 in}$ CCA2 SIM-NME' (www.iacr.org/archive/asiacrypt2007/48330522/48330522.pdf) or $\hspace{1.5 in}$ some other security notion against CCA2 attacks? $\;\;$ – Ricky Demer Nov 23 '12 at 23:59
@RickyDemer, I don't know. This is the first time I've heard of SIM-NME', whatever that is. IND-CCA2 security is the standard notion of security for a public-key encryption scheme that is intended to be secure against chosen-ciphertext attacks. For a definition of IND-CCA2 security, see any good textbook on modern (theoretical) crypto ... or, if you're feeling brave, see Wikipedia. – D.W. Nov 24 '12 at 1:15
I always thought CCA2 security was (just) the higher of two standard notions of security for public-key encryption. $\:$ If one only has bounded-CCA2 non-malleable (www.cs.toronto.edu/~vinodv/boundedCCA.pdf) public-key encryption, then I think something like sign-then-encrypt-then-sign would work best, although I don't know at what stages one would need to include the recipient's name. $\:$ (I also notice that the system butchered my previous comment.) $\;\;$ – Ricky Demer Nov 24 '12 at 1:47
@RickyDemer, I've never heard of this "bounded-CCA2 non-malleable" until now; as far as I can tell, it has approximately zero practical relevance. Anyone can invent some crazy security notion, but that doesn't make it relevant. I stand by all of my recommendations and statements in my answer. To be honest, I'm not sure where you're going with your comments. If you have questions, you may want to raise them in a separate question -- I'm not sure if I understand what you are getting at, but they seem to be a bit of a tangent. – D.W. Nov 24 '12 at 2:21
@RickyDemer, s far as why your comments are being formatted funny, it appears to be because you are manually inserting LaTeX spacing commands (e.g., \;, \hspace, manual linebreaks, etc.) into your comment text. It has been suggested to you before that you avoid doing that, if you want to avoid the funny formatting of your comments. I think that remains valid advice. – D.W. Nov 24 '12 at 2:21

Your Answer

 
discard

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.