Differences

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

--- pgpfan:ledowngrade [2025/11/05 16:36] – [An Unwarranted Claim Against SEIPD (OCFB-MDC)] b.walzer
+++ pgpfan:ledowngrade [2026/03/23 19:12] (current) – [Politics] New point about chunk size used for POC. 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.
-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.
@@ Line 107: / Line 107: @@
 If you end up believing that the attack from the paper is a valid vulnerability then you might think that the extra operation is worth the cost. Otherwise you might not.
+During the pre-schism phase of the standards process there was huge, never ending, debate about the amount of data processed between integrity checks ("chunk size"). In the end this attempt at standardization failed and the chunk size was made a settable parameter that ranged from 64 bytes to 4 MB. The proof of concept in the paper cranks the chunk size down from the 4 MB GnuPG default to 64 bytes to aid the attack. Someone observing this who was in favour of a larger chunk size might feel vindicated.
 =====An Unwarranted Claim Against SEIPD (OCFB-MDC)=====