The simple integer division on the processor takes something like 40 cycles (fast). Hence, the factorization challenge should have thousands of bits. Then it is going to take millions of years for one processor to try all possibilities. If the password is just 12 letters (80 bits?), then the time to test the password should be longer. Or else the good processor would try all combinations for a limited time. Of course, a longer password would help a lot, but even 200 bits is not 2000. The check should be proportionally slower. It is especially a problem when we are dealing with predictable passwords based on human language words. Maybe SHA-2/3 have not been developed with "slowness" as a goal. It may be that only randomness was the target. Hence, so many assembler instructions for one round. But only the slowness permits its use for HMAC or the password fingerprint that you have discussed before. I could not believe that slowness is just a byproduct of randomness. It is so evident why it is needed by itself (for some applications). Ed/ -----Original Message----- From: Thomas Bellman via NANOG <nanog@lists.nanog.org> Sent: Thursday, September 11, 2025 12:03 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Thomas Bellman <bellman@nsc.liu.se> Subject: Re: MD5 is slow On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
SHA-2 and SHA-3 are used not only for networking, they are general. Hence, they were developed to be slow enough to prevent brute force for some other applications.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)? /Bellman