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 reference ([20]) is to the start of an email list thread on the IETF OpenPGP mailing list. Since it is an informal discussion between people with a lot of shared context, it is hard to follow without that context. There was a question about a particular classic vulnerability and how it applied to the then new block cipher mode that detected modification. The attack in question involved getting the victim to encrypt a specially crafted message. Then the attacker could remove either the beginning or end of the message and produce a new message that also passed the modification check.

This isn't what many people would consider a downgrade attack. It is the opposite sort of thing in that the ultimate goal is an encrypted message with a valid modification check, not a different type of message without one.

The email thread concluded with the general opinion that the new block cipher mode was not vulnerable to the attack in question. So either way, this counts as a null reference.

Likely because of the attention drawn by the EFAIL paper, 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, 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]³⁾.

As already mentioned, the [20] reference has no relevance here and Perrin actually said nothing about this. The [21] reference to an email list message described a downgrade attack but it provided no specific details. Fortunately, there was a reference to a more detailed description later in the discussion thread in the form of exploit code⁴⁾. The exploit code revealed 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. In this way legends are born…