Take the 2-minute tour ×
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.

From reading RFC 2015 (MIME security with PGP), and from looking at the raw format of (GnuPG) encrypted and digitally signed email messages, it seems that first a signature is calculated from the plain text message, and then both are encrypted.

My question is why isn't this vulnerable to what Moxie Marlinspike dubs the "cryptographic doom principle" (basically, if you have to do any crypto operation before checking the signature, bad things will happen)? I suppose the reason (alongside the devil) will be in the details, in the particular way the "sign-then-encrypt" operation is implemented. But I've been unable to find (or more likely to make sense) of those details. Can anyone shed some light?

share|improve this question

2 Answers 2

The answer (to the title question) is no, due to a slight mixup in terminology. What Moxie says is (emphasis added)

if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

Notice that he says MAC and not signature. The PGP group has discussed this too, so you are not alone in your concern.

In other words, mac-then-encrypt is not the same thing as sign-then-encrypt. Sign-then-encrypt is preferred to encrypt-then-sign. For more discussion on sign-then-encrypt see this question and answers.

share|improve this answer
1  
Sign-then-Encrypt suffers from pretty much the same issues (padding oracles etc.) as MAC-then-Encrypt. I prefer Sign-then-Encrypt-then-MAC or Sign-then-AuthenticatedEncryption giving you the best of both worlds at moderate cost. –  CodesInChaos Jul 11 '13 at 15:48
    
Actually Sign-Then-Encrypt is worse than its Symmetric counter : in the public key setting, you can forward messages to make them appear having come from the original signer –  Alexandre Yamajako Jul 13 '13 at 17:52
    
@AlexandreYamajako, you are correct. The answers I referred the OP to solve this by prepending the message with the intended recipient's ID to resolve this problem. –  mikeazo Jul 13 '13 at 20:52

Whether this is OK depends upon the details of the encryption algorithm. You are right to point this out as "a fishy smell". That said, depending upon the details, it's possible GnuPG's approach could be OK. For instance, if the encryption algorithm it uses is IND-CCA2 secure, it might be fine.

Apparently Moxie Marlinspike's advice is focused on MACs (the symmetric-key setting), but I think you are right that it is also good advice in the asymmetric-key setting as well. However, let me point out one small detail. In principle there's no difference between a MAC (symmetric-key) vs signature (asymmetric-key). In practice there is one difference: it is rare to find symmetric-key encryption algorithms that are already secure against chosen-ciphertext attacks (without a MAC), whereas it's more common to find asymmetric-key encryption algorithms that are already secure against chosen-ciphertext attacks (without a MAC). In other words, most symmetric-key encryption algorithms are IND-CPA secure but not IND-CCA2 secure. In contrast, many asymmetric-key encryption algorithms are IND-CCA2 secure (and using one that isn't IND-CCA2 secure is also a "fishy smell").

If GnuPG uses an IND-CCA2 secure asymmetric-key, the risks that Moxie Marlinspike was pointing out don't apply: he was pointing out the risk of chosen-ciphertext attack on the decryption routine, but any IND-CCA2 algorithm is already secure against chosen-ciphertext attacks, even in the absence of any signature.

You can view the process of MACing or signing the ciphertext as a way of defending the encryption scheme against chosen-ciphertext attacks (i.e., defending an encryption scheme that isn't IND-CCA2-secure against IND-CCA2-style attacks). If the encryption scheme is already IND-CCA2-secure, that reduces the need to sign/MAC the ciphertext.

share|improve this answer

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.