I discuss the security of the OpenPGP standard and implementations more than most. As a result I run across certain unhelpful ideas more than most. I am reasonably certain at this point that these ideas originally came from a hard to follow section of the paper describing a vulnerability called EFAIL¹⁾. EFAIL came out in 2018 and became much better known than normal due to wide media coverage. These ideas propagated to the point that they can be now considered legends. These legends are serving to inhibit discussion. Who wants to talk about something they know to be completely broken? So I think it would be a good idea to go right back to the beginning and address this at its source.

Here then, presented for your consideration, is my take on section 5.2 of EFAIL…

First a short glossary:

SE (Symmetrically Encrypted): The OpenPGP block cipher mode without modification detection.
SEIP (Symmetrically Encrypted Integrity Protected): The OpenPGP block cipher mode with modification detection.
MDC (Modification Detection Code): Part of the OpenPGP cipher mode with modification detection.

5.2 Defeating integrity protection

Generating SE packets. Clients may ignore the standards recommendation and still generate SE ciphertexts. These messages have no integrity protection and have no means of preventing our attacks.

The newer OpenPGP block cipher mode with modification detection was introduced around the year 2000. Adoption seems to be universal at this point.

Older ciphertexts that were generated before the introduction of the MDC will remain vulnerable.

Since that was, as just mentioned, around the year 2000, few of those very old encrypted emails would contain the HTML required to make EFAIL work.

Ignoring the MDC. The MDC is only effective if it is checked. This can easily be verfied by introducing changes to the ciphertext and leaving the MDC as it is. If the MDC will not match the modfied ciphertext and if the client continues processing, the client may be vulnerable.

The EFAIL paper did an extensive job of identifying email clients that could have avoided the EFAIL attack by detecting modifications of the encrypted message but did not. So this section is certainly not misleading.

Stripping the MDC. Similar to the previous attempt, the MDC can also be removed, such that the client can not check the MDC at all. This is easily possible by removing the last 22 bytes from the ciphertext.

The language here is hard to understand. I think that “previous attempt” might refer to the previously mentioned “Ignoring the MDC” topic. The EFAIL researchers found an implementation that was ignoring the modification check. It did not complain if it was entirely absent from the end of the encrypted message. That seems sloppy but there are no security implications from the practice. The modification check was being ignored anyway.

You could just remove the last part of the encrypted message. Then it would no longer be formatted properly and would likely just fail on decryption. The result would certainly not pass the modification check. I strongly suspect that this section of EFAIL contributed to the legend that the OpenPGP modification detection is weak to the point of uselessness. The way this section is written makes it easy to end up with that impression.

Downgrade SEIP packets to SE packets.

A “downgrade” here means something different than it would for a connection oriented protocol like TLS. A downgrade attack on TLS most commonly means interference with the negotiation of encryption methods that occurs at the start of a connection. That type of negotiation doesn't exist for the OpenPGP case. Instead this is a kind of transmogrification attack. An encrypted message with modification detection is transformed into a message without modification detection without decrypting the message at any point in the process.

A more elaborate method is to disable the integrity protection by changing an SEIP packet to an Symmetrically Encrypted (SE) packet, which has no integrity protection. This is straightforward, because the packet type is not encrypted (see Figure 4).

The packet type specifies how the message is to be decrypted. How would you decrypt the message to get the encrypted packet type without knowing how?

This downgrade attack has been known since 2002 [20]²⁾, but never used in an actual attack.

The actual description of a downgrade attack from reference [20] was a fair ways down in the email list thread. I have corrected my version of the reference to point to the relevant message.

Likely because of the attention drawn by the EFAIL paper, I suspect that this reference became, by itself, the cause of a legend. That's the contention that the OpenPGP block cipher mode has only 16 bits of security. Since there was no weakness found for that particular issue (it was a problem with the specification), this legend is objectively false.

However, there is a caveat: in an SE packet, the last two bytes of the IV are added just after the first block. This was originally used to perform an integrity quick check on the session key.

Although technically true in a sense, I found the use of the term “integrity” confusing in this context. It is normally just called the “quick check”. The two bytes mentioned provide some defined redundancy helpful for detecting that the decryption was unsuccessful. In practice that redundancy is used to provide an easier to understand message to the user when they get the passphrase wrong while trying to decrypt a symmetrically encrypted file. So this has nothing to do with the integrity of the message as a whole.

While the SE type resynchronizes the block boundaries after encrypting these two additional bytes, the SEIP does not perform this resynchronization. To repair the decryption after changing the SEIP to an SE packet, two bytes must be inserted at the start of the first block to compensate for the missing bytes. This was also described by Perrin and Magazinius [20, 21]³⁾.

The [20, 21] references are to email list messages describing downgrade attacks but with no specific details provided. Fortunately, there was a reference to a more detailed description later in the [21] discussion thread in the form of exploit code⁴⁾. The exploit code clearly showed the requirement to somehow guess a 16 bit value to make the downgrade work. So in a normal OpenPGP environment where there is only a single message/file, the odds for the attacker would be 1 out of 65536. That would be on top of the expected hundred or so messages required to make EFAIL work in the first place. So for all practical purposes this downgrade is not possible in this context.

Since an attack was published against this integrity protection mechanism [22]⁵⁾, its interpretation is discouraged [18]⁶⁾, and the two bytes are ignored. They depict the beginning of the first real plaintext block and the SE and SEIP packet types treat them differently.

Reference [18] is to the OpenPGP standard. I don't read the appropriate section as discouraging the use of the “quick check” bytes. I only see a discussion of the issues. There is no security implication for such use in any sort of normal OpenPGP environment and it is an important usability improvement. The popular GnuPG checks the 2 bytes under discussion so there is wide usage of the feature.

I was puzzled about why the EFAIL paper was spending so much time talking about the two quick check bytes in a section about a downgrade attack. They don't seem to have anything to do with such an attack. Why would it be important that these bytes were not used very much? Then I tried to use GnuPG to decode the downgraded message produced by the exploit code and got this:

  gpg: decryption failed: Bad session key

… which is due to a failed quick check. The message actually could be decrypted with the key provided. The quick check bytes were wrong. I have since concluded that this problem is inherent to the exploit. After guessing the 16 bits you have to clobber the quick check bytes. There is nothing special about the quick check bytes, something has to be clobbered and the quick check bytes just happen to be there.

So we have a downgrade attack with a very low probability of success in an environment where that is important. The attack damages the encrypted message in a way that will cause most implementations to produce a bogus fatal error. It is easily arguable that this doesn't even count as a downgrade attack. But most people reading this section of the EFAIL paper would be unaware of this and would end up with the impression that there was something there they should be concerned about.

The mere possibility that a message can be changed to another form is not in itself evidence of a downgrade (transmogrification) vulnerability. I could, for example, design a version of the popular GCM cipher block mode that only differed in that it did not detect modifications. No one would think that I had created a downgrade vulnerability as a result. Such a vulnerability would require:

1. That the transmogrification is possible in the first place.
2. That there exist implementations that will accept the changed message.
3. That the changed message can actually be used to cause some sort of trouble.

For the GCM example, #1 involves no effort, but there are no implementations that would permit #2. Even though the downgrade is theoretically possible, it fails on practicality. We can't ignore practicality when considering a potential downgrade vulnerability.

Now let's address the situation with the two OpenPGP block modes…

A transmogrification is possible from the message type with the modification check to the message type without. As mentioned before, the odds of success are 1 out of 65536. Success also depends on the recipient implementation ignoring the damage to the message by ignoring the quick check. So we have fulfilled requirement #1 with caveats.

The only reason to support decryption using the PGP encryption method without modification detection is for backwards compatibility. It is to allow decryption of messages/files created in the relatively narrow window from PGP's birth in the 1990's and the adoption of modification detection after the year 2000. As a result, implementations are dropping support for the message type that does not check for modifications. Most notably, GnuPG no longer accepts such messages by default. So requirement #2 is possibly fulfilled, but probably not for very long past this point.

A modification check at the message level is not traditionally required for normal OpenPGP use. The signature system takes care of detecting modifications as well as authenticating the sender. So for fulfilling requirement #3, at this point in time we pretty much are left with the case where we want to prevent EFAIL class attacks and want to use the check at the message level to do so. That is the potential trouble here. EFAIL is against email. A 1 out of 65536 chance of success makes a downgrade practically impossible in an email environment. Taking into account the hundred or so guesses required to do EFAIL in the first place gets the odds into the millions. So requirement #1 drops out.

Let's pretend that someone was intent on using OpenPGP formatted messages in some new scheme that required a modification check at the message level. Such a scheme obviously could not accept messages without a modification check. Requirement #2 would drop out.

Since we can't imagine a situation where we could meet the requirements for a downgrade attack we have to admit that such an attack is not known.

In line with what seems to be the current practice, EFAIL came with a website intended to increase general interest in the vunerabiliy⁷⁾. This page has a misleading part…

Will signatures prevent these attacks?

No. PGP and S/MIME emails are displayed in the email program independently of whether or not they are signed or whether an existing signature is valid or not.

The part after the “No.” is OK. Finding such email programs is more or less what EFAIL is about.

Even if signatures did matter: an attacker can copy the altered ciphertext into a separate email and create a valid signature under his own name.

This part is only relevant to S/MIME. From the relevant reference⁸⁾:

From this we understand that message takeover attacks are not possible against OpenPGP, since the attacker is not able to sign the encrypted messages. Accordingly, contrary to S/MIME, OpenPGP offers the advantage that when receiving a signed and encrypted email one may always be certain that the signer authored the message, and can make no mistake when replying with history.

Someone who did not dig through the actual EFAIL paper for the reference would end up with the impression that OpenPGP signatures were not effective against EFAIL class attacks. That is simply wrong.