Re: MD5 is slow

[Saku Ytti via NANOG <nanog () lists nanog org>]

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/XBIM4VC2AO4V6KW3M4SKEGRPIM7YIP4N/