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 From: Matthew Petach <mpetach () netflight com> Sent: Wednesday, September 10, 2025 05:14 To: North American Network Operators Group <nanog () lists nanog org> Cc: Vasilenko Eduard <vasilenko.eduard () huawei com> Subject: Re: MD5 is slow On Tue, Sep 9, 2025 at 1:10 AM Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog org>> wrote: The problem is smaller: the attacker needs to predict only the password; some packets are predictable for 100%. The password is the thing that you put at the end of a command: "ip ospf message-digest-key 1 md5 c1$c0" How long could the password be? 10-12 letters are considered to be a good password (if upper case, lower case, special letters, numbers), but people typically use just words (only 100k words are typically well-known). Then some APTs have billions of typical passwords in the database (prioritized for probability). They could just try them all on a good GPU. It is needed for hash to be slow. Hence, for example, SHA-2 consists of "And, Xor, Or, Rot, Shr, Add (mod 2^32)" in 64 or 80 rounds! (for every block of 512bits). Hence, a few milliseconds twice per every hop for a rather small control plane message. It is strange for me that nobody cares about this latency. Eduard Eduard, I think the reason that it seems to you "that nobody cares about this latency" is that you seem to be focusing on a different latency from what everyone else thinks about when worrying about latency. Initially, you seemed to be concerned about a completely incorrect 5ms per MD5 hash number, which multiple people pointed out was completely wrong. The idea that hash functions need to be "slow" to prevent brute force attacks is a leftover from the idea that password comparisons would be slowed down after a certain number of tries to slow the rate of brute force password attacks. But that's not a function of the hash itself, that's a function of the programs calling the hashing function inserting extra latency. The hash calculation itself is breathtakingly fast. If we do a quick web search and look at the top few results from the past 18 months, people report that relatively modern CPUs can do about 43 million MD5 hashes per second per core. That would mean a given MD5 hash is taking about 23 nanoseconds (0.00000002325581395348 seconds) Even if every LSP update is MD5 hashed separately, sequentially on a single CPU core, that still means flooding 1000 LSP updates is going to add 23 microseconds of latency to your routing convergence. Flooding 1000 LSPs sequentially through 50 nodes in a large network? You've finally hit 1ms of added time to your overall convergence due to the MD5 lookups *throughout the entire network* Compared to the rest of the flooding process timers and SPF calculation, that latency is negligible. Additionally, that's pretty much the worst-case scenario, when you've had such a massive change to the network that you have 1,000 LSPs that all need to be updated and flooded out at once. In most cases, you've got orders of magnitude fewer updates going on, so your MD5 latency is going to add fractions of a microsecond to the convergence time. Comparing that to the speed of light across town, and you quickly realize that the MD5 calculation is a fraction of the time it takes to send that LSP from here to the router on the other side of the city, let alone a router on the other side of the country. When most people talk about latency, that's the latency that really starts to matter. Worrying about the speed of the MD5 calculation when it comes to trying to speed up convergence on a modern router with a modern multi-core CPU is like worrying about the wind resistance from the dirt on the hairs on the back of the flea that's biting the tip of the ear on the dog while it has its head sticking out the passenger window of the car on a warm sunny day while zipping down the highway. (The car that is, not the flea). If you want to reduce your gas consumption, you pull the dog inside and roll up the window. You don't swerve all over the road trying to brush the dirt off the hairs on the back of the flea. If you're worried about IGP convergence times, there's much bigger contributors to the overall convergence time that are much better targets to go after. Thanks! Matt -----Original Message----- From: Jay Acuna <mysidia () gmail com<mailto:mysidia () gmail com>> Sent: Monday, September 8, 2025 22:26 To: North American Network Operators Group <nanog () lists nanog org<mailto:nanog () lists nanog org>> Cc: Saku Ytti <saku () ytti fi<mailto:saku () ytti fi>>; Dan Collins <dcollinsn () gmail com<mailto:dcollinsn () gmail com>>; Vasilenko Eduard <vasilenko.eduard () huawei com<mailto:vasilenko.eduard () huawei com>> Subject: Re: MD5 is slow On Mon, Sep 8, 2025 at 3:00 AM Vasilenko Eduard via NANOG <nanog () lists nanog org<mailto:nanog () lists nanog org>> wrote: