One thing to keep in mind - the generally accepted solution for making a hash or encryption algorithm “slow” is to simply iterate, feeding the output of the function back into itself a given number of times. As an hopefully not apples-to-oranges example, 1Password iterates on the PDKDF2 algorithm 650,000 times to decrypt a vault’s key using user input. When running md5 iteratively in a small python script on my mid-range laptop, 1 million iterations takes .26 seconds, certainly fast enough for a user operation but extremely resistant to a brute force attack when the maximum guess rate is about 4 tries per execution block per second. If a GPU’s matrix math can dramatically speed this up, I’d be curious to what degree.
In other words, employing a “slow" algorithm in order to resist a brute force attack does not appear to be the best way to do so, by a long shot. -Chris > On Sep 11, 2025, at 02:02, Thomas Bellman via NANOG <[email protected]> > wrote: > > 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 > > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/ZTQZQCQRYZLJCECGLXKTSMHYMV7MFBOC/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/5YHUJ3ZBXPRB7CD6GGIZYYSJHB3NAEUR/
