Re: MD5 is slow

[Jay Acuna via NANOG <nanog () lists nanog org>]

On Thu, Sep 11, 2025 at 2:24 AM Vasilenko Eduard via NANOG
<nanog () lists nanog org> wrote:
> 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.

There are few real-world software programs or network protocols
using SHA-3 for any purpose, and the IETF or network community is not bound
to blindly follow every NIST advisory without considering threat models,
and what purposes the hash serves in their design.

For the main purpose the feature exists. a MD4 or weaker hash'd likely
be adequate.

The weak point might not be the hash, for example RFC 2385 - Md5 option for BGP.
Does not create a heavily replay-resistant authentication,  since the
hash covers only
TCP segment data, and TCP header excluding options. Anything to identify when
the packet was actually sent (Timestamps are an optional TCP option, which
could therefore be modified on a saved packet without affecting the
auth. hash check.)

16-bit TCP Ack and Seq counters are unique,  but they are also reused by new TCP
sessions, and will wrap and roll to 0 eventually on a long-lived sesion.
All your adversary needs then is enough old packets captured over a
period of time
with the same key and saved to get appropriate Seq values and Ack values.

For example,
Suppose you are a threat actor with physical access or in a position
to actually
capture and save packets between routers:  Should you be in a position to get a
sample packet to attack the hash: In this position you have at least 2 trivial
attack methods to corrupt the adjacency.

Capture+replay old legitimate packets in order to corrupt the data exchange,
or flood spoofed MAC frames causing unicast frames b/w peers to go to
you instead -
which prevents routers from forwarding packets b/w each other over that LAN
all without affecting routing protocol routes or adjacencies.
It is not just a lower difficulty attack.. Forwarding disruption is
harder to detect,
since the routing protocol does not detect and log routes going down.

In case you actually needed to prevent corruption; a stronger hash
wouldn't help.
I believe for EGPs:  You would have to use BGP over TLS  (BGPSEC),
and not the hashing option alone in the first place.

For IS-IS; You'd have a not easily-solvable problem at that point.
You might use a combination of tunneling and IPSEC to prevent replay,

But your attacker's presence on the shared LAN segment b/w
internal routers
(necessary for them to see hash values being exchanged in the first place),
opens up more DoS options for the adversary than I could count.

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