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 <nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/ZTQZQCQR...