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 <mpet...@netflight.com> Sent: Wednesday, September 10, 2025 23:01 To: Vasilenko Eduard <vasilenko.edu...@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.edu...@huawei.com<mailto:vasilenko.edu...@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/
