Differences

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

--- pgpfan:legends [2024/02/19 19:46] – Point strengthened b.walzer
+++ pgpfan:legends [2024/05/02 13:27] (current) – [Misleading Legends Caused by EFAIL] This needs a good analogy b.walzer
@@ Line 1: / Line 1: @@
 ======Misleading Legends Caused by EFAIL======
@@ Line 43: / Line 42: @@
 >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 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.
+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.
@@ Line 54: / 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]])).
-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(([[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 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.
-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.
+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.
-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. That is why it is legitimate for me to assume that there is only one message/file and that only one guess is possible. Any system using OpenPGP formatted messages in something like a connection oriented environment where multiple guesses are possible would treat messages/files without modification detection as if that format didn't exist. So the issue of downgrading would also not exist.
+----
-When considering security with respect to a transmogrification attack like this the only criteria available are practical ones. An implementation must exist that will accept a changed message. The changed message must be able to cause some trouble. That doesn't seem possible here. So this simply is not an issue.
+[[pgpfan:index|PGP FAN index]]\\
+[[em:index|Encrypted Messaging index]]\\
+[[:|Home]]