RE: MD5 is slow

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

Hi Ytti, I have to apologize for the subject. I have SHA2/3 in mind because NIST said that MD5 is "not recommended".
I have answered Matthew, but it was blocked by the mailman. This answer is very relevant to you too:

Hi Matthew,
Thanks for the discussion. It is the right approach to calculate carefully.
I do not believe that MD5 is a good basis; NIST recommends moving away from it. I am not qualified to question NIST 
decisions.
I have already pointed out the reference to https://www.ijcna.org/Manuscripts/IJCNA-2020-O-01.pdf . It is SHA-3; I have 
not found good data for SHA-2 (I was interested in ARM).
They have a table in section 6.1 for all sizes. It is 4151199 Cycles for 750B. The maximum clock for the ARM core is 
about 2Ghz (practically less, routers do not have enough cooling for this). Hence, this 750B would be checked for 2ms.
There is a discussion in the IETF that in the big networks, many attributes (TE, flex-algo, whatever) are attached in 
ISIS, hence the packet may be full size (1500B). Then the hash would be 4ms.
Twice (8ms) if the message is relayed, because a hash would be needed on input and output.

Hence, I do not understand why 5ms is “completely incorrect”.
Eduard
-----Original Message-----
From: Saku Ytti <saku () ytti fi> 
Sent: Wednesday, September 10, 2025 09:39
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Vasilenko Eduard <vasilenko.eduard () huawei com>
Subject: Re: MD5 is slow

On Wed, 10 Sept 2025 at 09:12, Vasilenko Eduard via NANOG <nanog () lists nanog org> wrote:

> But it's reality. Many passwords are not strong enough.
> More importantly, hash has XX rounds to give a really random output.
> Hence, the hash is designed to be slow.

No, not all hashes, only hashes for some application for some reason.
MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are 
measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW 
acceleration to win SHA competition.

You really need to look at your application before you start to define what metrics hash should and should not have.

Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice.

For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need 
collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you 
need collision, but you need the input to be valid and conducive towards your attack vector.

I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread 
that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use 
cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch 
needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which 
turns out to be not good hash for ECMP).



--
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/HKFJNL7YCWF3OBWE6NN3PPTNYP5EFX7M/