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
pgpfan:ledowngrade [2025/11/05 16:36] – [An Unwarranted Claim Against SEIPD (OCFB-MDC)] 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.
pgpfan/ledowngrade.1762360587.txt.gz · Last modified: by b.walzer