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?


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.

  • 2
    $\begingroup$ 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. $\endgroup$ Commented Jul 11, 2013 at 15:48
  • $\begingroup$ 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 $\endgroup$ Commented Jul 13, 2013 at 17:52
  • $\begingroup$ @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. $\endgroup$
    – mikeazo
    Commented Jul 13, 2013 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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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