RE: MD5 is slow

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

Hi Jay,
Hi Brent,
Sorry. It looks like I was not clear enough. My question was not related to the discussed MD5 strength that occurred 
during the last week.
Public key is not needed very often, no need to pay attention to the speed of fingerprint generation.
I was talking about Hash usage in many networking protocols, where it delays a network control plane message.
Eduard
-----Original Message-----
From: Jay Acuna via NANOG <nanog () lists nanog org> 
Sent: Friday, September 5, 2025 20:02
To: North American Network Operators Group <nanog () lists nanog org>
Cc: Jay Acuna <mysidia () gmail com>
Subject: Re: MD5 is slow

On Fri, Sep 5, 2025 at 2:22 AM Vasilenko Eduard via NANOG <nanog () lists nanog org> wrote:

> I have a temptation to ask: why hash in the first place?!? (does not 
> matter MD5 or SHA-2)

The purpose of a hashing is to create a space-efficient figure representing bytes of data.

The hashing system is secure or cryptographic If it is intractible to perform specified manipulations, such as deriving 
bits that were hashed from the output hash  (with or without knowing other data bits), creating or altering data given 
an existing hash and some data such that the output hash will be the same as a pre-chosen hash value, or the same hash 
value as a prior input, etc.

> Any hash MUST be slow (by design) to withstand brute force. In the 
> network device case, it is about 5ms for SHA-2 (of course,

MD5 and SHA-2 are not slow in this sense.  They are not designed to withstand "brute force".

They are designed with enough bit perturbations to accomplish the fundamental objectives of a secure hash above, but 
they are not slow enough to protect some small amount of text such as a password.

A slow hash would be something like md5crypt, Poul-Henning Kemp's algorithm.
PBKDF on SHA-2.   Or  100,000 rounds of MD5 or SHA-2, rather than a
single round.
BCrypt, etc.   Hashes designed for greater brute force resistance, but
these can be more quickly obsoleted for this purpose than the underlying SHA-2, etc, which are not resistant to brute 
force.

I think your latency figures have to do with a specific software implementation.
These numbers vary depending on implementation and computing power.

Most likely your latency calculation is for evaluating a single hash value, but brute force attacks would use unique 
customized implementations of the hashing algorithm  designed to perform billions of Hash operations in parallel at a 
much greater volume of operations per second.

For example, a  Massively-multithreaded parallel implementation performing a billion simultaneous MD5 operations for 
brute force purposes

Can take certain computations MD5 normally performs on each hash _one_ time,  and copy the calculation result as the 
starting point across all the parallel hashing instances before MD5 computation unique to each attempt starts.

Only a part of the implementation's equivalent to the final
MD5Update()  on the last block of
input has to be repeated upon each parallel element.

In reality parts of the MD5 algorithm may be further separable allowing for greater volume of processing in a parallel 
implementation Versus calculating a single hash value.

--
-JA
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/SBAFN4EFNFLMZWMKOSMJGUT4IGOZ53PB/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/AA6KAA4XOLKSSR6XL7FKVYZCQRWIEWRI/