Differences

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

--- pgpfan:no_new_ae [2022/11/07 21:48] – [There are OCFB-MDC weaknesses mentioned in the OpenPGP standard] oracle immunity article expanded 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 39: / Line 39: @@
 OCFB-MDC is cryptographically secure in that a protected message can not be modified without detection. It provides the capability of the sort of thing often referred to as authenticated encryption. So the OpenPGP standard does not lack authenticated encryption as is sometimes claimed.
-I have come to believe that OpenPGP gains its legendary effectiveness mostly from the [[pgpfan:minimalist|minimal approach]] taken. So I am disturbed by how much extra complexity these proposals add to the standard. As a definite example, the proposal currently (September 2022) working through the IETF process add the following:
+I have come to believe that OpenPGP gains its legendary effectiveness mostly from the [[pgpfan:minimalist|minimal approach]] taken. So I am disturbed by how much extra complexity these proposals add to the standard. As a definite example, the proposal currently (September 2022) working through the IETF process adds the following:
   * Three new cipher block modes. Since the standard currently has two such modes (OCFB-CFB and the proceeding OCFB) that brings the total to five.
@@ Line 45: / Line 45: @@
   * Since these modes come from online, connection oriented media like TLS they tend to be limited in how much data they can process at once. As a result a [[pgpfan:no_new_ae#decrypting_large_files_should_not_result_in_the_release_of_suspect_data|"chunking" system]] has to be added to the standard. With the current two levels of blocking that brings the number of blocking levels to three.
-To be clear, this is not about any encryption mode. OpenPGP implementations normally use the [[Advanced_Encryption_Standard|AES]] encryption mode and there is no proposal to change this. This is about the relatively obscure [[wp>Block_cipher_mode_of_operation|block cipher mode]]. The only definite outcome of replacing the current block cipher mode (OCFB-MDC) will be to cause interoperability problems. The current proposal for such replacement makes the potential for such problems much worse by making two of the three added modes optional.
+To be clear, this is not about any encryption mode. OpenPGP implementations normally use the [[wp>Advanced_Encryption_Standard|AES]] encryption mode and there is no proposal to change this. This is about the relatively obscure [[wp>Block_cipher_mode_of_operation|block cipher mode]]. The only definite outcome of replacing the current block cipher mode (OCFB-MDC) will be to cause interoperability problems. The current proposal for such replacement makes the potential for such problems much worse by making two of the three added modes optional.
 =====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 94: / Line 94: @@
 We should not fail to recognize that hash then encrypt has a significant advantage over other methods in that it protects the integrity check with the encryption. An attacker has to work through the encryption to attack the check.
+===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. 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 103: / 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.
@@ Line 110: / Line 126: @@
 This came from a blog post called [[pgpfan:tpp|The PGP Problem]]. It turned out to be a misunderstanding caused by an incorrect specification. The author of the blog post misunderstood the discussion. There is no such weakness.
+====OCFB-MDC doesn't have a security proof====
+Instead of a criticism of the //design// of OCFB-MDC this is about a design //method//. This objection has the great advantage of not raising a specific issue. Vague contentions are hard to refute.
+The proof here is something like a mathematical proof created to support something kind of like an engineering process. Practically, it is a proof that generally accepted engineering principles were applied to the design. The important point here is that such a thing does not prove security directly, only indirectly through those design principles.
+Like any design process based on mathematical/logical principles, security proofs live and die on their assumptions. Cryptographic constructions with security proofs are still successfully attacked. Only at that point does it becomes clear what assumption was incorrect. That assumption might of even been implicit and unknown to the designer.
+So a security proof is not proof of security...
+A popular bridge design might of come from a process based on slide rules, algebra, lookup tables, cigarettes and coffee. If those bridges exist all over the country, would it make any sense to propose that they all be torn down and rebuilt using a newer design?
+If it turned out that the bridges were reliable, easy to inspect and inexpensive it would make more sense to use the bridge as an example to extend and improve the state of the art. That is the situation with OCFB-MDC. A simple, easy to understand design that has very much stood the test of time. It makes no sense to complain about the design process of something that has already proven itself secure. That is after all the hoped for result of applying generally accepted engineering principles in the first place.
 ====The MDC can be stripped====
@@ Line 261: / Line 291: @@
 The fix requires zero effort. Just leave things as they are. The blocking issue serves as a serious argument against the replacement of OCFB-MDC.
+[[pgpfan:index|PGP FAN index]]\\
+[[em:index|Encrypted Messaging index]]\\
+[[:|Home]]