There are many hash functions for many needs with very different design goals over several unrelated metrics.There are intentionally slow hashes for PW secrets, MD5 and SHA-2 are not such. I do not accept the argument that MD5 or SHA-2 is a meaningful contributor when we discuss RTT latencies of network equipment anywhere. Even if we would accept someone uses SHA2 for ISIS and that contributes 5ms to the convergence budget, it would be largely meaningless, as we don't really care about initial convergence time, and after initial convergence we can convergence for any single fault prior to it happening, so no work needs to be done at the RE to forward around the fault at the time it happens. On Fri, 5 Sept 2025 at 10:22, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

Hi all, So many smart people are in the discussion about MD5 ... I have a temptation to ask: why hash in the first place?!? (does not matter MD5 or SHA-2) Any hash MUST be slow (by design) to withstand brute force. In the network device case, it is about 5ms for SHA-2 (of course, dependent on the control plane processor). It should be checked on every hop for routing event propagation. Hence, it creates a delay for the event propagation that is typically much higher than RTT. When "Packet Design" was alive, they measured 300ms cross-US. A decade later, it should be faster, but anyway slow enough. It is a big part (maybe even the biggest) of the "sub-second" convergence of IGP protocols. Actually, it greatly undermines the value of ISIS IETF performance tunings: https://datatracker.ietf.org/doc/html/rfc9681.

Why do people not use symmetric encryption for networking protocols? Symmetric encryption has a typical latency of 10s of microseconds.

Of course, it is possible to calculate how much energy would be saved on hash calculations worldwide, but people in this group would probably not welcome a green agenda. And this number would be miserable against bitcoin. Eduard _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Y677XAJS...

-- ++ytti

On Fri, Sep 5, 2025, 03:22 Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

Any hash MUST be slow (by design) to withstand brute force. In the network device case, it is about 5ms for SHA-2 (of course, dependent on the control plane processor).

It is not necessary for a cryptographic hash function to be slow (on the order of milliseconds), nor is it true that SHA2 is designed to be slow, or that it is that slow on short inputs. Even relatively weak processors can compute millions of hashes per second with SHA2 hash functions. If you could find a way to compute hashes a million times faster, and used that in a brute-force preimage attack, you'd be shaving off the equivalent of 20 bits of difficulty - not near enough to make a brute force attack on a 256-bit hash tractible. The case where you do care about speed is when you're dealing with password hashing, for example. The threat is a dictionary attack, since testing even the most common 10,000 passwords against a database of user accounts is very likely to compromise a good percentage of them. Using pbkdf2, or bcrypt, or argon2, allows you to slow that down. But that's only because we know that a lot of people use simple or common passwords. You're likely to get some hits even in the first few thousand attempts. For signing or message integrity checking, that isn't the case. If you're trying to find a second public key (or any other message) corresponding to a specific predetermined hash value, by brute force, the probability of each attempt succeeding is 2^-n. Even if you could try a million hashes per microsecond on every CPU that exists on the planet Earth, we're talking about something like 10^40 years to succeed at a sha-256 preimage attack. 128 bit hashes would be faster but still not remotely possible.

On Fri, Sep 5, 2025 at 2:22 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

I have a temptation to ask: why hash in the first place?!? (does not matter MD5 or SHA-2)

The purpose of a hashing is to create a space-efficient figure representing bytes of data. The hashing system is secure or cryptographic If it is intractible to perform specified manipulations, such as deriving bits that were hashed from the output hash (with or without knowing other data bits), creating or altering data given an existing hash and some data such that the output hash will be the same as a pre-chosen hash value, or the same hash value as a prior input, etc.

Any hash MUST be slow (by design) to withstand brute force. In the network device case, it is about 5ms for SHA-2 (of course,

MD5 and SHA-2 are not slow in this sense. They are not designed to withstand "brute force". They are designed with enough bit perturbations to accomplish the fundamental objectives of a secure hash above, but they are not slow enough to protect some small amount of text such as a password. A slow hash would be something like md5crypt, Poul-Henning Kemp's algorithm. PBKDF on SHA-2. Or 100,000 rounds of MD5 or SHA-2, rather than a single round. BCrypt, etc. Hashes designed for greater brute force resistance, but these can be more quickly obsoleted for this purpose than the underlying SHA-2, etc, which are not resistant to brute force. I think your latency figures have to do with a specific software implementation. These numbers vary depending on implementation and computing power. Most likely your latency calculation is for evaluating a single hash value, but brute force attacks would use unique customized implementations of the hashing algorithm designed to perform billions of Hash operations in parallel at a much greater volume of operations per second. For example, a Massively-multithreaded parallel implementation performing a billion simultaneous MD5 operations for brute force purposes Can take certain computations MD5 normally performs on each hash _one_ time, and copy the calculation result as the starting point across all the parallel hashing instances before MD5 computation unique to each attempt starts. Only a part of the implementation's equivalent to the final MD5Update() on the last block of input has to be repeated upon each parallel element. In reality parts of the MD5 algorithm may be further separable allowing for greater volume of processing in a parallel implementation Versus calculating a single hash value. -- -JA

back in the day, the kiddies had sport by sending RSTs against BGP sessions. pretty much any hash with a key space of 48+ bits was sufficient to raise the bar. md5 was cheap and easy.

sorry. forgot the primary cite, rfc 2385 randy

Hi Jay, Hi Brent, Sorry. It looks like I was not clear enough. My question was not related to the discussed MD5 strength that occurred during the last week. Public key is not needed very often, no need to pay attention to the speed of fingerprint generation. I was talking about Hash usage in many networking protocols, where it delays a network control plane message. Eduard -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Friday, September 5, 2025 20:02 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jay Acuna <mysidia@gmail.com> Subject: Re: MD5 is slow On Fri, Sep 5, 2025 at 2:22 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

I have a temptation to ask: why hash in the first place?!? (does not matter MD5 or SHA-2)

The purpose of a hashing is to create a space-efficient figure representing bytes of data. The hashing system is secure or cryptographic If it is intractible to perform specified manipulations, such as deriving bits that were hashed from the output hash (with or without knowing other data bits), creating or altering data given an existing hash and some data such that the output hash will be the same as a pre-chosen hash value, or the same hash value as a prior input, etc.

Any hash MUST be slow (by design) to withstand brute force. In the network device case, it is about 5ms for SHA-2 (of course,

MD5 and SHA-2 are not slow in this sense. They are not designed to withstand "brute force". They are designed with enough bit perturbations to accomplish the fundamental objectives of a secure hash above, but they are not slow enough to protect some small amount of text such as a password. A slow hash would be something like md5crypt, Poul-Henning Kemp's algorithm. PBKDF on SHA-2. Or 100,000 rounds of MD5 or SHA-2, rather than a single round. BCrypt, etc. Hashes designed for greater brute force resistance, but these can be more quickly obsoleted for this purpose than the underlying SHA-2, etc, which are not resistant to brute force. I think your latency figures have to do with a specific software implementation. These numbers vary depending on implementation and computing power. Most likely your latency calculation is for evaluating a single hash value, but brute force attacks would use unique customized implementations of the hashing algorithm designed to perform billions of Hash operations in parallel at a much greater volume of operations per second. For example, a Massively-multithreaded parallel implementation performing a billion simultaneous MD5 operations for brute force purposes Can take certain computations MD5 normally performs on each hash _one_ time, and copy the calculation result as the starting point across all the parallel hashing instances before MD5 computation unique to each attempt starts. Only a part of the implementation's equivalent to the final MD5Update() on the last block of input has to be repeated upon each parallel element. In reality parts of the MD5 algorithm may be further separable allowing for greater volume of processing in a parallel implementation Versus calculating a single hash value. -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SBAFN4EF...

On Mon, 8 Sept 2025 at 11:00, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:

Your comments on the performance are very important. I still believe that any Hash must be slow enough, because if it were fast, then the attacker could take a big GPU and brute force it (The routing message is very predictable; only the password is not known, but could be tested from the dictionary). But what is slow? us or ms? In support of the latter, look to https://www.ijcna.org/Manuscripts/IJCNA-2020-O-01.pdf. It is hundreds of cycles per byte. Acceleration helps, but not much (around 3x) https://github.com/minio/sha256-simd/blob/master/README.md. A few milliseconds per every hop is expensive.

All of these questions have been addressed already in the thread. I'm not sure what to do here, should we repeat the answers? -- ++ytti

On Sep 8, 2025, at 3:26 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

Sorry. It looks like I was not clear enough. My question was not related to the discussed MD5 strength that occurred during the last week. Public key is not needed very often, no need to pay attention to the speed of fingerprint generation. I was talking about Hash usage in many networking protocols, where it delays a network control plane message.

You'd have to be clearer about what protocol and what hash you're asking after. Two of the common cases where such things show up is for authentication and for integrity checks. For authentication in control protocols, the balance you're looking for is being able to do the operation fast enough for expected traffic load among all of the other work being done by the system. If you're lucky, you might have hardware support for the cryptographic operation. For control planes, sometimes it's just the router's general purpose CPU. Easy examples of this sort of thing are the authentication fields for the IGPs, or for TCP-MD5/TCP-AO used by BGP, LDP, etc. For integrity checks, you have a set of data you're trying to provide a short-hand as to whether it's been passed around intact. You'll often see this for detached file signatures, although protocols may do similar things for internal checksum purposes as well. Cryptography of any sort can be an attack on the device implementing it. Use expensive ciphers and do volumetric attacks that cause that code to run, you'll burn CPU in some cases. Most protocols try to do the cryptographic checks far down their validation procedures. A regular conversation for BFD, as an example, is how often you want to do some bit of cryptography. Line card CPUs are usually puny and MIGHT have access to some hardware support for common ciphers like MD5/SHA-1/SHA-2. BFD sends tiny packets often some tens of ms apart. Now scale that up to a potentially large number of session on a line card. Using better ciphers, if you want authentication (many don't) gets expensive, so there's need to potentially think differently about when you do it. For example: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authenticati... -- Jeff

On Mon, Sep 8, 2025 at 3:00 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:

Your comments on the performance are very important. I still believe that any Hash must be slow enough, because if it were fast, then the attacker could take a big GPU and brute force it only the password is not known, but could be tested from the dictionary).

They do not require high latency. 0.1ms per call is still just fine. And the concept of brute force a hashing algorithm should resist involves many orders of magnitude more possibilities than contained in a password. Put it this way: MD5 has a block size of 512 bit. The MD5 algorithm has not failed in its security purpose for a hashing algorithm: If one is able to reverse an input by directly trying every possible input that contains a number of unpredictable bits 447 or less. Exactly the same way as it's not a MD5 problem if you have a 1-byte password, and someone tried all 255 possibilities. You really need a bare minimum of least a block of input; if not more to properly use MD5 and similar secure hashing algorithms. Predictable bits also don't help against guessing, so you should consider this as 512 bits of entropy on the input or more to safely use a hashing procedure calculated on 512-bit blocks. I also read MD5 input shorter than 512 must be padded congruent to 448 modulo 512. SHA-2 is similar. You need more bits than a typical password would contain. Standard secure hashing algorithms are not designed to save you in case your input contains fewer random bits. You have the option of using a key-stretching algorithm instead of a straight hash. PBKDF2, as mentioned before. Multiple rounds of hashing chained in a certain manner can cause delays for brute force guessing. A dictionary word contains about 4-bits worth of entropy. If the 512 bits are not filled, the input is to be padded with bits in front of your password, which are predictable, so they don't count. That is far from enough unpredictable bits to directly use MD5. From a randomized password; you get approximately 6 to 7 bits worth of entropy per character, so a good password length input for MD5 would be at about 85 random characters. -- -JA

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 -----Original Message----- From: Jay Acuna <mysidia@gmail.com> Sent: Monday, September 8, 2025 22:26 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Dan Collins <dcollinsn@gmail.com>; Vasilenko Eduard <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> wrote:

Your comments on the performance are very important. I still believe that any Hash must be slow enough, because if it were fast, then the attacker could take a big GPU and brute force it only the password is not known, but could be tested from the dictionary).

They do not require high latency. 0.1ms per call is still just fine. And the concept of brute force a hashing algorithm should resist involves many orders of magnitude more possibilities than contained in a password. Put it this way: MD5 has a block size of 512 bit. The MD5 algorithm has not failed in its security purpose for a hashing algorithm: If one is able to reverse an input by directly trying every possible input that contains a number of unpredictable bits 447 or less. Exactly the same way as it's not a MD5 problem if you have a 1-byte password, and someone tried all 255 possibilities. You really need a bare minimum of least a block of input; if not more to properly use MD5 and similar secure hashing algorithms. Predictable bits also don't help against guessing, so you should consider this as 512 bits of entropy on the input or more to safely use a hashing procedure calculated on 512-bit blocks. I also read MD5 input shorter than 512 must be padded congruent to 448 modulo 512. SHA-2 is similar. You need more bits than a typical password would contain. Standard secure hashing algorithms are not designed to save you in case your input contains fewer random bits. You have the option of using a key-stretching algorithm instead of a straight hash. PBKDF2, as mentioned before. Multiple rounds of hashing chained in a certain manner can cause delays for brute force guessing. A dictionary word contains about 4-bits worth of entropy. If the 512 bits are not filled, the input is to be padded with bits in front of your password, which are predictable, so they don't count. That is far from enough unpredictable bits to directly use MD5. From a randomized password; you get approximately 6 to 7 bits worth of entropy per character, so a good password length input for MD5 would be at about 85 random characters. -- -JA

That's your fault for using a dumb password and the hash doesn't help you with that. On 9 September 2025 10:09:56 CEST, Vasilenko Eduard via NANOG <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 -----Original Message----- From: Jay Acuna <mysidia@gmail.com> Sent: Monday, September 8, 2025 22:26 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Dan Collins <dcollinsn@gmail.com>; Vasilenko Eduard <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> wrote:

...

Your comments on the performance are very important. I still believe that any Hash must be slow enough, because if it were fast, then the attacker could take a big GPU and brute force it only the password is not known, but could be tested from the dictionary).

They do not require high latency. 0.1ms per call is still just fine. And the concept of brute force a hashing algorithm should resist involves many orders of magnitude more possibilities than contained in a password.

Put it this way: MD5 has a block size of 512 bit. The MD5 algorithm has not failed in its security purpose for a hashing algorithm: If one is able to reverse an input by directly trying every possible input that contains a number of unpredictable bits 447 or less. Exactly the same way as it's not a MD5 problem if you have a 1-byte password, and someone tried all 255 possibilities.

You really need a bare minimum of least a block of input; if not more to properly use MD5 and similar secure hashing algorithms. Predictable bits also don't help against guessing, so you should consider this as 512 bits of entropy on the input or more to safely use a hashing procedure calculated on 512-bit blocks. I also read MD5 input shorter than 512 must be padded congruent to 448 modulo 512.

SHA-2 is similar. You need more bits than a typical password would contain.

Standard secure hashing algorithms are not designed to save you in case your input contains fewer random bits.

You have the option of using a key-stretching algorithm instead of a straight hash. PBKDF2, as mentioned before. Multiple rounds of hashing chained in a certain manner can cause delays for brute force guessing.

A dictionary word contains about 4-bits worth of entropy. If the 512 bits are not filled, the input is to be padded with bits in front of your password, which are predictable, so they don't count. That is far from enough unpredictable bits to directly use MD5.

From a randomized password; you get approximately 6 to 7 bits worth of entropy per character, so a good password length input for MD5 would be at about 85 random characters.

-- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4LFVVQ7V...