Re:Why Keccak is not ARX
by Dylan16807 on Wednesday September 20, 2017 @05:10AM
(#15291862)
When one hash is a billion times too fast to securely store passwords, and another hash is ten billion times too fast to securely store passwords, the speed difference doesn't matter.
All the hashes you'd care to look at are within an order of magnitude of speed. They all need to be repeated a very large number of times to fight brute forcing. Using more repetitions for a faster hash is so utterly trivial it's not even worth mentioning in the context of security. There is zero difference in security margin from the speed of a hash.
And yes, memory-intensive algorithms are good for passwords, so you shouldn't be caring about normal hashes at all.
Brute force is irrelevant in hashing. The faster the better.
PS: this is because the complexities for attacks are too high. For SHA-3-256 you need 2^128 operations to approach finding a collision. Whatever your speed you will never reach this amount of computation (or storage).
State actors can easily afford ASIC AES and SHA2 brute-force farms, and that's a concern, especially with monocultural recommendations to "always use AES/SHA2." Now that Keccak's been chosen as the basis for SHA3 in-lieu of more hw expensive alternatives like ECHO, the cost of cracking has been reduced for future scenarios. Do we really want to slash the security margin for a modest bump in runtime performance?