Differences

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

--- pgpfan:no_new_ae [2024/01/06 16:33] – [Hash then encrypt is generically insecure] removed link to weak article 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 102: / Line 102: @@
 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 111: / 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.