pgpfan:no_new_ae
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
pgpfan:no_new_ae [2022/12/22 22:08] – link to intptxt 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. | 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: | + | I have come to believe that OpenPGP gains its legendary effectiveness mostly from the [[pgpfan: |
* 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. | * 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: | * 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: | ||
- | 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> | + | 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> |
=====Conclusion===== | =====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:// | + | The problems caused by these harmful proposals are not off in the future. |
The Snowden leak (([[https:// | The Snowden leak (([[https:// | ||
Line 97: | Line 97: | ||
===OpenPGP' | ===OpenPGP' | ||
- | This is essentially the idea that hash then encrypt is inferior expressed in the language of theoretical cryptography. | + | This is essentially the idea that hash then encrypt is inferior expressed in the language of theoretical cryptography. |
+ | |||
+ | Because of that design you have to decrypt the message/ | ||
+ | |||
+ | 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.==== | ====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==== | ====OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure==== | ||
- | According to a partially remembered email list post, the MDC only requires | + | 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> | ||
+ | |||
+ | 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' | 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' | ||
Line 114: | Line 126: | ||
This came from a blog post called [[pgpfan: | This came from a blog post called [[pgpfan: | ||
+ | |||
+ | ====OCFB-MDC doesn' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Like any design process based on mathematical/ | ||
+ | |||
+ | 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==== | ====The MDC can be stripped==== | ||
Line 265: | 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. | 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: | ||
+ | [[em: | ||
+ | [[:|Home]] | ||
pgpfan/no_new_ae.1671746924.txt.gz · Last modified: 2022/12/22 22:08 by b.walzer