Differences

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

--- pgpfan:legends [2024/03/04 21:12] – Forgot b.walzer
+++ pgpfan:legends [2024/03/13 18:35] (current) – Yet another try at a clear argument. b.walzer
@@ Line 42: / 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 53: / 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 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.
+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.
-The mere possibility that a message can be changed to another form is not in itself evidence of a downgrade
+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.
-(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:
-  - That the transmogrification is possible in the first place.
+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.
-  - That there exist implementations that will accept the changed message.
-  - 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.
+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.
-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.
 =====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 vunerabiliy(([[https://efail.de/|EFAIL]])). This page has a misleading part...
+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?//