RE: MD5 is slow

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

Hi Matthew,
You are right, I probably need to stop trying to satisfy my curiosity.
People have shown me a couple of overlooked points and even one mistake.

You are right again that MD5 is mostly used, not SHA-2, and nobody supports SHA-3.
It was strange for me that the community does not pay attention to the NIST recommendation.
Maybe because there are professionals (in this community) who deeply understand that MD5 is good enough (the previous 
big thread on MD5 is evidence).
It is indeed making my complaints completely irrelevant. Going to sub-millisecond makes it irrelevant for the control 
plane.

For the calculation, it looks like table 6.1 has a mistake in the title of the last column: it should be “Cycles per 
bit”.
Because the total 5281063 (5.28 million) cycles is for sure the original number measured in the experiment. Then 
5281063/1000/8=660.
You would probably agree that they could not measure directly “Cycles per byte” in such tests.
Actually, there is no need for a calculator to divide 5.28 by 2Ghz. Millions of nanoseconds would result in 
milliseconds.

I am not concerned about security; I am concerned about latency.
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.
From this discussion, I have understood that Networking may develop its own version of hash that would be faster but 
less secure. It would make sense.
Unfortunately, it would need a high qualification to make it controllable weaker.
MD5 looks like the right compromise.
Albeit, I do not see that it was a conscious decision. It looks like it just happened this way for historical reasons 
(despite the NIST push to move out).

Eduard
From: Matthew Petach <mpetach () netflight com>
Sent: Wednesday, September 10, 2025 23:01
To: Vasilenko Eduard <vasilenko.eduard () huawei com>
Cc: North American Network Operators Group <nanog () lists nanog org>
Subject: Re: MD5 is slow


Hi Eduard,

You need to stop moving the goalposts.
Most network protocols use MD5.
RFC 5310 added support for specifying other authentication algorithms, but that is up to the
network's discretion to specify it; and network engineers are generally not going to manually
select an encryption algorithm that their hardware isn't capable of doing quickly.

If you're concerned about adding latency to routing convergence, then stick with discussing the
hash algorithms that are actually being widely used, which is still almost entirely MD5.

Pointing at SHA-3 and saying "but that's slower on a particular processor I care about" isn't
terribly relevant, because nobody's forcing you to use SHA-3 on that processor.  Stick with
MD5 if your processor is slow at SHA-3.  (As an aside, the paper you cite shows the ARM-9
processor runs at 650 cycles per byte of input, so on a 2ghz ARM-9 processor, it'll take about
334 nanoseconds per byte of input run through SHA-3; a 1K input would thus take about 334
microseconds, or 0.3 ms).

To your second point, as others have tried to explain, there is a difference between securing
static secrets and preventing nuisance attacks.  You need stronger security when you are
protecting against access to static data that is vulnerable to longer-lasting attacks.
For routing protocol security, the goal is NOT to keep data secret; there is generally nothing
in an LSP that is particularly secret.  What you are trying to do is prevent nuisance attacks
from people trying to confuse your routing protocols.  The encryption key in that case is
simply raising the bar to make such attacks more headache than they are worth.  If someone
spends the resources to brute force figure out your encryption key, big whoop dee-doo, you
go into your config generation system, pick a new encryption key, and push out new configs
to your routers, and they're back to square one again.  The attacker doesn't gain access to
any secret information if they brute-force your MD5 hashed OSPF or IS-IS authentication key.
The worst they can do is disrupt your routing protocol by sending bad information into it until
you change the authentication key, which is generally trivial to do.  As such, there is no
particular need to move to "stronger" encryption functions than your hardware is capable of
supporting, because there's nothing secret you're trying to protect; you're simply making it
difficult enough to send bogus data into your network that most attackers won't bother trying.

Please stop moving the goalposts to try to bolster your defense of a defenseless position.  :(

Thank you.

Matt


On Tue, Sep 9, 2025 at 11:40 PM Vasilenko Eduard <vasilenko.eduard () huawei com<mailto:vasilenko.eduard () huawei 
com>> wrote:
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 IJCNA-2020-O-01.pdf<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


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