RE: MD5 is slow

[Vasilenko Eduard via NANOG <nanog () lists nanog org>]

Let me do a little calculation here.
Imagine that we have access to one server with 8 cards "NVIDIA GeForce RTX 5090". Every respected black or white hacker 
(including pintesters) has access to something similar.
Then we could do MD5 hash calculations (for one block) with the performance 1.72*10^12 hashes per second. I have 
assumed Hashcat 7 that such people use extensively: 
https://openbenchmarking.org/test/pts/hashcat&eval=7b7b45c3848e0a5482fb82f220518d5233961430#metrics
Imagine a person who would like to protect the password. The password is typed on the keyboard, let's say 75 different 
characters (upper case, lower case, numbers, special symbols).
Assume that the person is very accurate and generates 10 letters really random. Then it is 5.6*10^18 of combinations.
Hence, the server (with Hashcat) would try all potential passwords and find the right one for an average of 19 days 
(average is /2 from the worst case).
If 10 letters are not completely random (English words are used, even partially), then the search could be greatly 
optimized.
Access to a larger number of GPUs would make the time (to crack the password) ridiculously small.

I doubt that 19 days is a good protection for a password! The password typed manually should last for a much longer 
time - you could torment people in any way, but you would not be capable of achieving a faster password rotation.

There is no way to fix MD5 for plain password protection.
There is the possibility for networking protocols to organize *automatic* passwords/keys rotation (every night?), and 
additionally generate longer keys (32 bytes?) in a really random way. Then MD5 would be applicable again.

It is the reason why IT guys use “Bcrypt” or “Argon” for password hashing -> even the best GPU is going to waste a big 
enough time (millions of years).

By the way, it is related to the previous thread on the MD5 strength - it does not have it.
One would say that it is not an MD5 problem, it is a password problem (length, rotation), but it does not matter - the 
problem persists anyway.
Moving to the slower hash is the solution that was adopted by IT, because it is much more difficult to push users to 
generate strong passwords and rotate them very often.

Maybe in this way it would be possible to explain why "not MD5" for password hashing.
Eduard
-----Original Message-----
From: Vasilenko Eduard 
Sent: Thursday, September 11, 2025 13:18
To: 'North American Network Operators Group' <nanog () lists nanog org>
Cc: Thomas Bellman <bellman () nsc liu se>
Subject: RE: MD5 is slow

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

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/JS7B5UQGEA4Z5DXD2JCLHTZ6UEXUY5WC/