Differences

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

--- pgpfan:ledowngrade [2025/11/03 19:59] – [Two Pet Peeves] Spelling. b.walzer
+++ pgpfan: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.
-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 126: / Line 126: @@
 ''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.)).