Differences

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

--- pgpfan:no_new_ae [2024/01/06 16:41] – [Hash then encrypt is generically insecure] closer b.walzer
+++ pgpfan:no_new_ae [2024/01/29 13:08] – [OCFB-MDC uses the insecure SHA1 hash. Therefore OCFB-MDC is insecure] stronger reference, stronger point b.walzer
@@ Line 113: / 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 and the ability to even generating a valid hash by an attacker with access to 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. So something like a [[wp>Cyclic_redundancy_checkcheck|CRC]] would be sufficient.
+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.