Differences

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

--- pgpfan:no_new_ae [2023/12/27 00:56] – [OCFB-MDC only has 16 bits of security] New objection b.walzer
+++ pgpfan:no_new_ae [2024/01/29 13:21] (current) – [OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure] More specific. b.walzer
@@ Line 49: / Line 49: @@
 =====Conclusion=====
-The problems caused by these harmful proposals are not off in the future. They are causing trouble today even though none have made it into the OpenPGP standard (2022). I have personally been involved in an obscure and hard to fix interoperability problem caused by one of these proposed encryption modes that had somehow leaked out of an implementation. There was no evidence that the user had explicitly authorized the use of the mode. The GnuPG implementation actually had a possible remote code execution exploit(([[https://nvd.nist.gov/vuln/detail/CVE-2020-25125|CVE-2020-25125]])) caused by the implementation of the new preferences system required to deal with the proliferation of block cipher modes. The issue was quickly rectified but I could not ask for a better example of the risk associated with implementing new functionality.
+The problems caused by these harmful proposals are not off in the future. [[pgpfan:noae_shame|They are causing trouble today]] even though none have made it into the OpenPGP standard (2022). I have personally been involved in an obscure and hard to fix interoperability problem caused by one of these proposed encryption modes that had somehow leaked out of an implementation. There was no evidence that the user had explicitly authorized the use of the mode. The GnuPG implementation actually had a possible remote code execution exploit(([[https://nvd.nist.gov/vuln/detail/CVE-2020-25125|CVE-2020-25125]])) caused by the implementation of the new preferences system required to deal with the proliferation of block cipher modes. The issue was quickly rectified but I could not ask for a better example of the risk associated with implementing new functionality.
 The Snowden leak (([[https://blog.cryptographyengineering.com/2014/12/29/on-new-snowden-documents/|On the new Snowden documents]])) had documents that suggested PGP encrypted material was on a short list of things that the NSA(([[wp>National_Security_Agency|National Security Agency]])) could not get access to. That likely was for passive eavesdropping but this still suggests that it might not be a good time to tinker with the fundamental cryptography of OpenPGP without good reason.
@@ Line 97: / Line 97: @@
 ===OpenPGP's OCFB-MDC is inferior because it falls into the class of INT-PTXT instead of the class of INT-CTXT===
-This is essentially the idea that hash then encrypt is inferior expressed in the language of theoretical cryptography. This is covered in a separate article: [[pgpfan:intptxt]].
+This is essentially the idea that hash then encrypt is inferior expressed in the language of theoretical cryptography. Since we know the design of OCFB-MDC we can address this directly.
+Because of that design you have to decrypt the message/file first before checking for any changes. So there is a risk that the message/file might leak or be caused to leak during that check. After the check you can blow up with an error if you want and prevent any further chance of a leak.
+The check here is the hash called SHA-1. As with most hashes, the time taken is not affected by the content that is being checked. It would be pretty much impossible to make the time taken depend on the content by accident. Since this is a hash, it acts to destroy the meaning of the content to prevent the hash from being reversed. So some sort of side channel leak is very unlikely.
+So when someone brings up the fact that OCFB-MDC is INT-PTXT they are really saying they think that a hash operation might leak information. They would have to come up with some idea of how that might happen.
 ====OpenPGP does not have authenticated encryption. Everything needs authenticated encryption.====
@@ Line 107: / Line 113: @@
 ====OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure====
-According to a partially remembered email list post, the MDC only requires a hash that is non-reversible. That seems quite reasonable to me. So the currently known SHA1 collision weakness does not affect the security of OCFB-MDC in any way. I understand that the mere presence of something called SHA1 can cause problems in some situations, but such restrictions are not rational. If this is actually a problem then I suggest that the SHA1 used for OCFB-MDC be renamed to something like "The MDC Hash" and be respecified to only provide irreversability.
+From the appropriate discussion section of OpenPGP standard:
+>It does not rely on a hash function being collision-free, it relies on a hash function being one-way.
+So the currently known SHA1 collision weakness does not affect the security of OCFB-MDC in any way. OCFB-MDC prevents an attacker from getting access to the computed hash or even to generate a valid hash with the aid of an encryption oracle. So I would go so far as to say that a good one-way function is not really required. All that is needed is a function that can reliably detect changes to the protected message. Some classes of [[wp>Cyclic_redundancy_checkcheck|CRC]] might be sufficient for example.
+I understand that the mere presence of something called SHA1 can cause problems in some situations, but such restrictions are not rational. If this is actually a problem then I suggest that the SHA1 used for OCFB-MDC be renamed to something like "The MDC Hash" and be respecified to only provide irreversability.
 Because OCFB-MDC protects the output of the hash by randomizing and then encrypting it, it seems reasonable to think that it is more resistant to weaknesses in the hash than the commonly used schemes that expose the output of the hash to the attacker. So replacing OCFB-MDC with such a scheme might increase the probability of trouble down the road. If we were to take a stand against harmful changes prompted by broken policies covering the use of certain cryptographic functions, we couldn't really find a better place to take that stand than with SHA1 usage in OCFB-MDC. It isn't that we got lucky somehow here, the collision resistance of the hash used in OCFB-MDC is simply irrelevant.