Differences

This shows you the differences between two versions of the page.

--- pgpfan:legends [2024/02/08 19:27] – Typo b.walzer
+++ pgpfan:legends [2024/05/02 13:27] (current) – [Misleading Legends Caused by EFAIL] This needs a good analogy b.walzer
@@ Line 40: / Line 40: @@
 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](([[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|RE: [Cfrg] OpenPGP security analysis]])), but never used in an actual attack.
+>This downgrade attack has been known since 2002 [20](([[https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw6RuE1-kWdg26w/|RE: [Cfrg] OpenPGP security analysis]], see the paragraph starting "The one thing I still see to worry about, is the rollback attack...")), 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.
+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.
-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.
+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.
-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.
@@ Line 57: / Line 53: @@
 >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](([[https://www.metzdowd.com/pipermail/cryptography/2015-October/026685.html|[Cryptography] OpenPGP SEIP downgrade attack]])).
-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(([[https://gist.github.com/coruus/85dea6eb82897044f65d#file-gistfile1-py|Exploit Code]], Referenced from: [[https://github.com/google/end-to-end/issues/161|No warning on decrypting Tag 9 (no integrity protection) packets #161]])). 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.
+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 code(([[https://gist.github.com/coruus/85dea6eb82897044f65d#file-gistfile1-py|Exploit Code]], Referenced from: [[https://github.com/google/end-to-end/issues/161|No warning on decrypting Tag 9 (no integrity protection) packets #161]])). 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.
 >
 >Since an attack was published against this integrity protection mechanism [22](([[https://eprint.iacr.org/2005/033|An Attack on CFB Mode Encryption As Used By OpenPGP]])), its interpretation is discouraged [18](([[https://www.rfc-editor.org/rfc/rfc4880|OpenPGP Message Format]], see the section starting "In winter 2005, Serge Mister and Robert Zuccherato...")), 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.
+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 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:
+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 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.
+... 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.
+=====A Legend From the EFAIL Publicity Page=====
+In line with what seems to be the current practice, EFAIL came with a website intended to increase general interest in the vulnerability(([[https://efail.de/|EFAIL]])). 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(([[https://www.cryptosource.de/blogpost__smime_mta_en.html|message takeover attacks against S/MIME]])):
+>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.
+----
-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...//
+[[pgpfan:index|PGP FAN index]]\\
+[[em:index|Encrypted Messaging index]]\\
+[[:|Home]]