Re: MD5 is slow

[Tom Beecher via NANOG <nanog () lists nanog org>]

> It is the reason why symmetric encryption is much stronger for this use
> case. Hence, symmetric encryption does not need to be slow.


Symmetric encryption is faster when the data size in question is large.
The delta between symmetric and asymmetric is negligible at the data sizes
in scope for networking protocols. (Also hashes in protocols aren't being
used for ENCRYPTION, they're being used for AUTHENTICATION. )

Also, even if we assert the 5ms per hash calculation is accurate ( although
to be clear I agree it is not ), it is STILL basically a no-op.  ISIS and
OSPF implementations have spf-delay timers ( different by vendor ) to
prevent constant calculation churn during instability.  BGP UPDATES
received have to process through Adj-Rib-In , then go into Loc-Rib, then go
into main RIB with all other protocol routes, then you have to bestpath
THAT to get the FIB , which then gets turned around and transmitted as
appropriate.

Hash calculations , even if hypothetically repeated at each step ( which
they are not ) , are a negligible part of the convergence delay, at any
scale.

On Wed, Sep 10, 2025 at 7:13 AM Vasilenko Eduard via NANOG <
nanog () lists nanog org> wrote:

> Hi Ytti,
> It looks like you are trying to teach me what is "salt". Salt + password
> greatly increases the challenge for the attacker: it is not possible to map
> a hash to a password just from the database (in 1 step).
>
> For the attacker in the networking protocol case, the "salt" is always
> visible (these are additional fields from packet headers).
> The attacker could still try different passwords from the database. But it
> would need many steps; every step is effectively the same processing as on
> the legitimate host (headers + password).
> If we assume that on some platform (GPU?), the performance would be very
> fast (10B/sec), then all typical passwords would be tried in seconds.
> It is not acceptable. Hash must be slow! (if used for signature, because
> hash for load balancing or routing tables have no such problem - they need
> only good randomness)
>
> For symmetric encryption, the "salt" is the internal state of the
> encryption engine (initialization vector?) - it is not visible and
> changed/preserved between packets.
> It is the reason why symmetric encryption is much stronger for this use
> case. Hence, symmetric encryption does not need to be slow.
> Ed/
> -----Original Message-----
> From: Saku Ytti <saku () ytti fi>
> Sent: Wednesday, September 10, 2025 13:11
> 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 13:01, Vasilenko Eduard via NANOG <
> nanog () lists nanog org> wrote:
>
> > IMHO: Then it was bad design. The source text is visible if a hash is
> used for the signature. Only the password is not known.
>
> Please make a serious attempt in trying to understand how applications are
> different.
>
> Try to understand why unix passwords benefit from slow hash. You only have
> the password hash as output, any input that provides same hash, is
> equivalent. So any collision you find, you have exactly the same problem
> and serious problem.
>
> MD5 or SHA in BGP, ISIS, OSPF are not like this. There isn't even
> necessarily guarantee that useful collisions exist, as you may not have
> enough bits that can have arbitrary value while keeping PDU valid and
> conducive towards your attack vector.
>
> Most collisions would be garbage, where PDU is rejected. Therefore even if
> we assume we could cause MD5, SHA collisions, it wouldn't still matter.
>
> You have good rationale in wanting slow hash, but you struggle to
> understand why not all applications are about hashing 8byte secrets.
> --
>   ++ytti
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/5E22LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/R4MIG4NCKOQTUDS4CWJHIHSVJAW555ZL/