The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools

pgpfan:ledowngrade

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pgpfan:ledowngrade [2025/10/31 19:37] – [The CCA2 Insecurity Claim] Better. b.walzerpgpfan:ledowngrade [2025/12/10 16:27] (current) – [Stacked Vulnerabilities] Bad wording, spelling b.walzer
Line 71: Line 71:
 As has been pointed out(([[https://lists.gnupg.org/pipermail/gnupg-users/2024-August/067270.html|On the Legacy Encryption Downgrade Attacks against GnuPG]])) some (most?) implementations don't really make the SED mode available in the first place. But let's ignore that aspect for now and assume it is available. As has been pointed out(([[https://lists.gnupg.org/pipermail/gnupg-users/2024-August/067270.html|On the Legacy Encryption Downgrade Attacks against GnuPG]])) some (most?) implementations don't really make the SED mode available in the first place. But let's ignore that aspect for now and assume it is available.
  
-The vulnerabilties here are stacked. You have to get though one before you can attempt the other. When considering stacked vulnerabilities the first vulnerability can't be too serious by itself and should be less serious than the second. If, for example, you had a case where the first vulnerability had to decrypt the ciphertext and supply it to the attacker then would not even bother to consider the second. The second vulnerability would be irrelevant.+The vulnerabilities here are stacked. You have to get though one before you can attempt the other. When considering stacked vulnerabilities the first vulnerability can't be too serious by itself and should be less serious than the second. If, for example, you had a case where the first vulnerability had the user decrypt an arbitrary number of ciphertexts and supply the result to the attacker then you would not even bother to consider the second. The second vulnerability would be irrelevant.
  
 That is literally what is happening here. The attack from the paper requires that the user or the user's client receive a message, decrypt it and then send it back to the attacker. For this case there is no point in worrying about the second vulnerability before resolving the first. Once you have resolved the first then the second goes away. All that cool stuff about using an decryption function as a encryption function never has a chance to be meaningful. So it seems that there is no attack here against the LibrePGP OCB mode that could ever be considered significant in some way. That is literally what is happening here. The attack from the paper requires that the user or the user's client receive a message, decrypt it and then send it back to the attacker. For this case there is no point in worrying about the second vulnerability before resolving the first. Once you have resolved the first then the second goes away. All that cool stuff about using an decryption function as a encryption function never has a chance to be meaningful. So it seems that there is no attack here against the LibrePGP OCB mode that could ever be considered significant in some way.
Line 81: Line 81:
 > However, note that conducting this attack against LibrePGP-based email encryption is not realistic, since an email client that is vulnerable against our attacks would also expose the vulnerability of SEIPD packets being downgradeable to SED Packets, which was exploited in the Efail attack (([[https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|Efail: Breaking s/mime and openpgp email encryption using exfiltration channels]])). This vulnerability can be exploited much more straightforwardly, i.e., with only a single modified ciphertext. Accordingly, for any application that also supports OpenPGP SEIPD packets, which clearly is the case for current email clients, the vulnerability of SEIPD packets would be the much greater problem. > However, note that conducting this attack against LibrePGP-based email encryption is not realistic, since an email client that is vulnerable against our attacks would also expose the vulnerability of SEIPD packets being downgradeable to SED Packets, which was exploited in the Efail attack (([[https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|Efail: Breaking s/mime and openpgp email encryption using exfiltration channels]])). This vulnerability can be exploited much more straightforwardly, i.e., with only a single modified ciphertext. Accordingly, for any application that also supports OpenPGP SEIPD packets, which clearly is the case for current email clients, the vulnerability of SEIPD packets would be the much greater problem.
  
-This states that a "downgrade" from SEIPD to SED is something that the maintainer of an email client would have to be concerned with. I do not believe that to be true. SEIPD (Symmetrically Encrypted Integrity Protected Data, OCFB-MDC) is from the existing OpenPGP standard. The resistance designed into SEIPD against a modification to SED  reduces the probability of success to 0.000015 (1/(2^16)). That would not be a potential problem for the medium of email. In the presence of the "quick check" (the most common case) this sort of modification is not known to be possible at all. Of course, email client maintainers might not know this and as a result the argument concerning practically could still be valid.+This states that a "downgrade" from SEIPD to SED is something that the maintainer of an email client would have to be concerned with. I do not believe that to be true. SEIPD (Symmetrically Encrypted Integrity Protected Data, OCFB-MDC) is from the existing OpenPGP standard. The resistance designed into SEIPD against a modification to SED  reduces the probability of success to 0.000015 (1/2<sup>16</sup>). That would not be a potential problem for the medium of email. In the presence of the "quick check" (the most common case) this sort of modification is not known to be possible at all. Of course, email client maintainers might not know this and as a result the argument concerning practicality could still be valid.
  
 This in turn triggered the second peeve. The paper's attack involves sending unauthenticated SED encrypted messages to a victim. The paper at no point addressed the effect of [[pgpfan:pgpauth|PGP authentication]]. It was not even mentioned in passing. That seems to be very common for this sort of discussion and is fairly inexplicable. This in turn triggered the second peeve. The paper's attack involves sending unauthenticated SED encrypted messages to a victim. The paper at no point addressed the effect of [[pgpfan:pgpauth|PGP authentication]]. It was not even mentioned in passing. That seems to be very common for this sort of discussion and is fairly inexplicable.
Line 92: Line 92:
   - unauthenticated, encrypted with SED (provides no integrity check)   - unauthenticated, encrypted with SED (provides no integrity check)
  
-At this point in time, use of the SEIPD mode is fairly ubiquitous. So seeing the SED mode is a bit odd in any case. The SEIPD mode was specifically created to provide an integrity check for unauthenticated (unsigned, anonymous) messages. So it is very suspicious to see a unauthenticated SED mode encrypted message. Rather than any unwarranted concern about messages modified from SEIPD to SED, a client should instead deal with the unauthenticated SED encrypted messages critical to this attack simply on the basis of suspicion. Any unauthenticated but encrypted email messages should be noted as suspicious. The forwarding of such messages should be done with the greatest care or even prevented entirely. The opening of any attachments from such messages should be discouraged or prevented. The suspicious message should not be passed along to a complex decoder such as a generic HTML interpreter.+At this point in time, use of the SEIPD mode is fairly ubiquitous. So seeing the SED mode is a bit odd in any case. The SEIPD mode was specifically created to provide an integrity check for unauthenticated (unsigned, anonymous) messages. So it is very suspicious to see a unauthenticated SED mode encrypted message. Rather than any unwarranted concern about messages modified from SEIPD to SED, a client should instead deal with the unauthenticated SED encrypted messages critical to this attack simply on the basis of suspicion. Any unauthenticated but encrypted email messages should be noted as suspicious. 
 + 
 +The forwarding of suspicious messages should be done with the greatest care or even prevented entirely. The opening of any attachments from such messages should be discouraged or prevented. The suspicious message should not be passed along to a complex decoder such as a generic HTML interpreter.
  
 ... Or less complicated, a client could simply ignore unauthenticated but encrypted with SED messages as being not worth the bother to support. That would prevent the attack from the paper and some others at a slight cost in interoperability. ... Or less complicated, a client could simply ignore unauthenticated but encrypted with SED messages as being not worth the bother to support. That would prevent the attack from the paper and some others at a slight cost in interoperability.
Line 107: Line 109:
  
 =====An Unwarranted Claim Against SEIPD (OCFB-MDC)===== =====An Unwarranted Claim Against SEIPD (OCFB-MDC)=====
 +
 +//Much of the following section is no longer relevant as the paper has been updated to address the issue identified here.//
  
 In Reference A (Insecurity of OpenPGP SEIPD packets under adaptively chosen ciphertext attacks) the paper states: In Reference A (Insecurity of OpenPGP SEIPD packets under adaptively chosen ciphertext attacks) the paper states:
Line 122: Line 126:
 ''K2||LIT-hdr||message||MDC(K2||LIT-hdr||message)'' ''K2||LIT-hdr||message||MDC(K2||LIT-hdr||message)''
  
-I don't get any great amount of credit for spotting this. That is because I know that this exact same misunderstanding has happened before. When the security of the SEIPD encryption mode was being evaluated it turned out that the specification omitted the MAC key. So there was more discussion about the attack engendered by this omission than there might have been otherwise(([[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|The ITEF OpenPGP discussion thread about the security properties of the MDC]])). Perhaps the specification still needs some work to make this clearer.+I don't get any great amount of credit for spotting this. That is because I know that this exact same misunderstanding has happened before. When the security of the SEIPD encryption mode was being evaluated it turned out that the specification omitted the MAC key. So there was more discussion about the attack engendered by this omission than there might have been otherwise(([[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|The ITEF OpenPGP discussion thread about the security properties of the MDC]])). Perhaps the specification still needs some work to make this clearer((The LibrePGP specification has now been modified to make it clearer that the MAC key is included: [[https://lists.gnupg.org/pipermail/librepgp-discuss/2025/000089.html|Minor edits to the specification]])).
  
 A definite statement is required here: this paper does not show that the SEIPD encryption mode does not achieve CCA2 security((I was able to inform one of the authors about the error via an email exchange.)). A definite statement is required here: this paper does not show that the SEIPD encryption mode does not achieve CCA2 security((I was able to inform one of the authors about the error via an email exchange.)).
  
pgpfan/ledowngrade.1761939438.txt.gz · Last modified: by b.walzer