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 EFAIL1). 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]2), but never used in an actual attack.
The actual description of a transmogrification 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]3).
The [20, 21] references are to email list messages describing transmogrification 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 code4). The exploit code clearly showed the requirement to somehow guess a 16 bit value to make the transmogrification 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 transmogrification is not possible in this context.
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 (and likely others) 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 transmogrification 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 exploit code had to provide a function to do this). 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 transmogrification 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 transmogrification 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.
There is an aspect of this that could be inherently misleading to those familiar with downgrade attacks. Most often the reason for doing a downgrade attack in the first place is to force the use of some method with a vulnerability known to the attacker. That method at one time was considered secure but that security degraded in some way over time. That is not what is happening for the OpenPGP case. The OpenPGP block cipher mode without modification detection is not defective in some way. It just doesn't provide modification detection. It has never provided modification detection. So an implementation that is given a message in that format knows exactly what it is not getting … any indication that a modification might or might not of occurred.
In practice, this is mostly about allowing 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 already mentioned, there is no possibility of negotiating another protocol/format here. Those messages/files will never have modification detection.
So if you want to, say, prevent EFAIL, then if you want to support messages without modification detection you will have to take an approach that does not depend on such detection. For example, you could take into account the modification detection provided by a signature. It makes no difference to the implementation if the format was originally modification detecting and someone changed it along the way. The implications are the same. So in a very real sense, the fact that it might be possible to transmogrify a message with modification detection to one without is irrelevant to the discussion of security in the OpenPGP case.
Amazon might send you a toaster instead of a replacement lock. That doesn't mean that your front door has a potential vulnerability. Amazon would have to send you something that actually provided a lock function before we could claim that there might be a vulnerability.
In line with what seems to be the current practice, EFAIL came with a website intended to increase general interest in the vulnerability7). 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 reference8):
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 and were generally weak. That is simply wrong.
This possible misapprehension is very relevant here. If you accept that OpenPGP signatures are ineffective against EFAIL then you would think that the modification detection provided by the block cipher mode was the last chance to resolve EFAIL. As a result the discussion in section 5.2 would seen to be very important and relevant. Otherwise, if you knew that signatures were effective against EFAIL, things would be more nuanced. You would realize that all EFAIL attack messages would show up as unsigned (anonymous) and encrypted. Unsigned but encrypted messages are troublesome in more ways than just EFAIL. So you might consider solving the larger, more general, issue instead, possibly basing your solution completely on the protection provided by signatures. At that point the discussion in section 5.2 would become irrelevant.
In fairness, it should be mentioned that the question of S/MIME signatures vs EFAIL is also somewhat nuanced. S/MIME provides two types of signatures. One “inside the envelope” and one “on the outside of the envelope”. The proposed weakness is based on the outside signature. Presumably an implementation using signatures against EFAIL would only use the inside signatures. So there might be an argument here, should someone go to the trouble to develop it.