They are not entirely broken
They are not entirely broken
Posted Oct 21, 2024 0:24 UTC (Mon) by wittenberg (subscriber, #4473)In reply to: They are not entirely broken by cypherpunks2
Parent article: LibreSSL 4.0.0 released
A major problem in discussing cryptography (and security in general) is that we can't show that something is secure (with a few exceptions like one-time pads and Shamir secret sharing, which are not relevant here). All we can do is discuss how much confidence we have in a system. It is sometimes possible to use a reduction to show that one system is at least as secure as another, but again that is not relevant here. We gain confidence in a system when many people we respect try and fail to find a weakness in it. We lose confidence when we learn of techniques which weaken related systems (perhaps a version with fewer rounds, or a system with a very similar structure). There are cases when we lose confidence almost instantly. We had fair confidence in SIKE in June of 2022, but no confidence in SIKE by August of 2022.
Which brings us to MD4 and MD5. MD4 has been known to be vulnerable to collision attacks for almost 30 years. That greatly reduces my confidence in its adequacy against pre-image attacks. MD5 appears to be stronger.
I am more confident in SHA-3 than I am in SHA-2 for several reasons:
1. It is not vulnerable to length-extension attacks (though they can be defended against in older hash functions by prepending the total length to the message before calculating the message digest.
2. SHA-3 was the result of an open competition, so I worry less about NSA doing something fishy. -- We all remember what they did to ECDH.
3. SHA-2 is close enough in design to SHA-1 to be worrisome.
Another reason for not supporting old algorithms is the cost. The cost in maintenance is hard to estimate in free software, but there is a cost in security which is borne by everyone in the community. More code almost inevitably means more bugs, and therefore more attack surface. All of us bear the increased risk in return for which a small group who have not updated gain convenience. That small group is more vocal, as the cost each of them pays is higher, but I think that the total cost for the large group is much larger.
--David
Posted Oct 21, 2024 2:48 UTC (Mon)
by cypherpunks2 (guest, #152408)
[Link]
While the keccak core as used in SHAKE/SHA-3 is very good, it hasn't received anywhere near the amount of analysis that the MD4 through SHA-2 constructions have. I am not a cryptographer, but I trust that the weaknesses have been resolved. In particular, the construction of SHA-2 is very different from that of MD4, MD5, and SHA-1. The similarities it shares (unbalanced feistel-like construction, davies-meyer compression function, merkle-damgaard padding) are rather superficial. The germane difference is that the older designs used a single heterogeneous non-linear function that changed based on the iteration, whereas SHA-2 uses all four functions (choice, majority, sum 1, sum 2) on each iteration.
> though they can be defended against in older hash functions by prepending the total length to the message before calculating the message digest
The best way to mitigate it would be to use SHA-512/256, I'd think. Then the hash itself becomes resistant to the attacks and there is no need to change the way the hash is used to work around its own limitations. As an added bonus, on 64-bit machines, SHA-512 is faster than SHA-256 so SHA-512/256 is a more efficient way to get a 256 bit digest than SHA-256 itself.
The primary reason that I am not a fan of SHA-3 is that it is designed to be extremely fast in hardware and not a general-purpose SHA-2 replacement. Its heavy use of bitwise transpositions makes it very efficient in silicon but less efficient in software. This makes it quite bad for slow KDFs because it gives an ASIC an inherent advantage (yes we should all be using a memory hard KDF, but non-memory hard KDFs will be around for a long time). SHA-2 on the other hand is optimized for 32/64 bit operations in software, and efficient silicon implementations are an afterthought.
They are not entirely broken