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
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, 5 Sept 2025 at 10: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).
Out of curiosity, how did you arrive at 5ms? I don't think it is important, but it is interesting to me. I'm more arriving at around 1us on core from <10years ago (w/ SHA instruction set) or 10us on older core per ISIS LSA. But we can't still include even this 1us or 10us to the convergence budget, because NOS almost always has most of the cores doing nothing, due to poor design and no commercial pressure to improve. So if this would actually matter, you could at the first point when receiving LSA call sha_validate on another core with access to a shared pointer to boolean sha_valid=false, which this other core sets to true, upon validating SHA. Then the original core which is guaranteed to do work exceeding 1us or 10us for that LSA will continue its work, and finally check that sha_valid is true, if not reject the work it did, making the integrity validation free provided it takes less time to validate the integrity than it takes to calculate the topology. -- ++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 3:22 AM 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)
The topic as of late is tied to IOS storing MD5 checksums of authorized SSH public keys for authentication. I presume the sole purpose of this was to simply avoid storing the entirety of the public key (usually ~535 bytes for a 4096-bit key).
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
I have a temptation to ask: why hash in the first place?
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. re performance, you may find rfc 1810 amusing, if only from a historical perspetive. randy
On Fri, Sep 5, 2025 at 3:34 PM Randy Bush via NANOG <nanog@lists.nanog.org> wrote:
I have a temptation to ask: why hash in the first place?
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.
For the case of BGP, your better option is Rfc3682 + use graceful restarts. Peering providers & customers would preferably deny forwarding outgoing BGP packets from outside the link onto a direct link that don't originate between the peers connected to that same direct link -- essentially, deny spoofed packets within your routing policy. On modern hardware; I've seen figures for MD5 computations at 82,000 Million hashes/second for the RTX 4090. You shouldn't have much a bandwidth or latency issue due to md5 with modern silicon. The MD5 option is still perfectly effective against online attacks, And the weakness of MD5 becomes irrelevent. It won't ever be really insecure, since random internet users attempting to inject spoofed RSTs to your application from outside your network will not have a copy of your packets, nor your exact config file. The former requires physical access or remote control of a peer to obtain. An attacker possessing the latter would suggest they got your md5 key anyways (the key for md5 has to be stored with reversible encryption or plaintext). But no, Any attacker would be spitting packets blindly, not having a sample that tells them which hash value they are actually trying to recreate, and the limiting factor is not how quickly they can try to break MD5, but how many packets they can actually emit per second & hope that they guessed the key right on one packet. If that is billions of packets per second, then they will cause a DoS due to too many packets per second eons before they have a good chance at guessing a random md5 key. -- -JA
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...
Hi Ytti, Hi Dan, 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. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Friday, September 5, 2025 18:55 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow On Fri, 5 Sept 2025 at 10: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).
Out of curiosity, how did you arrive at 5ms? I don't think it is important, but it is interesting to me. I'm more arriving at around 1us on core from <10years ago (w/ SHA instruction set) or 10us on older core per ISIS LSA. But we can't still include even this 1us or 10us to the convergence budget, because NOS almost always has most of the cores doing nothing, due to poor design and no commercial pressure to improve. So if this would actually matter, you could at the first point when receiving LSA call sha_validate on another core with access to a shared pointer to boolean sha_valid=false, which this other core sets to true, upon validating SHA. Then the original core which is guaranteed to do work exceeding 1us or 10us for that LSA will continue its work, and finally check that sha_valid is true, if not reject the work it did, making the integrity validation free provided it takes less time to validate the integrity than it takes to calculate the topology. -- ++ytti
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
The hash doesn't need to be slow if there are enough numbers to check. If you have to calculate 340282366920938463463374607431768211456 hashes, it doesn't matter if each one takes a nanosecond and the bad guy has 1 billion computers, because that's still 340282366920938463463 seconds to go. On 8/09/25 09:59, Vasilenko Eduard via NANOG wrote:
Hi Ytti, Hi Dan, 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. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Friday, September 5, 2025 18:55 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
On Fri, 5 Sept 2025 at 10: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). Out of curiosity, how did you arrive at 5ms? I don't think it is important, but it is interesting to me.
I'm more arriving at around 1us on core from <10years ago (w/ SHA instruction set) or 10us on older core per ISIS LSA.
But we can't still include even this 1us or 10us to the convergence budget, because NOS almost always has most of the cores doing nothing, due to poor design and no commercial pressure to improve. So if this would actually matter, you could at the first point when receiving LSA call sha_validate on another core with access to a shared pointer to boolean sha_valid=false, which this other core sets to true, upon validating SHA. Then the original core which is guaranteed to do work exceeding 1us or 10us for that LSA will continue its work, and finally check that sha_valid is true, if not reject the work it did, making the integrity validation free provided it takes less time to validate the integrity than it takes to calculate the topology.
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VV7SJROW...
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
Except, it’s not 340282366920938463463 seconds to go, it’s ≤ 340282366920938463463 seconds to go. That’s the worst case number if the attacker gets his brute force on the last possible attempt. In reality, one should assume that most brute force attacks will succeed in roughly 1/2 that time, and if any intelligence can be applied to further reduce the search space, frequently, the time can be further reduced, often to between 1/8 and 1/32 of the original total number of hashes, sometimes even more. So if we’re actually talking about 1/2 of 1/32 of your original number, it’s still 5316911983139663491.609375 seconds which is roughly 61538333138190.5496714 days or approximately 168482773821.19247001 years, so yeah, still reasonably safe, but a lot of people don’t consider these factors when thinking about hash safety, so it is important to bring them up. Owen
On Sep 8, 2025, at 11:29, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
The hash doesn't need to be slow if there are enough numbers to check. If you have to calculate 340282366920938463463374607431768211456 hashes, it doesn't matter if each one takes a nanosecond and the bad guy has 1 billion computers, because that's still 340282366920938463463 seconds to go.
On 8/09/25 09:59, Vasilenko Eduard via NANOG wrote:
Hi Ytti, Hi Dan, 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. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Friday, September 5, 2025 18:55 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
On Fri, 5 Sept 2025 at 10: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). Out of curiosity, how did you arrive at 5ms? I don't think it is important, but it is interesting to me.
I'm more arriving at around 1us on core from <10years ago (w/ SHA instruction set) or 10us on older core per ISIS LSA.
But we can't still include even this 1us or 10us to the convergence budget, because NOS almost always has most of the cores doing nothing, due to poor design and no commercial pressure to improve. So if this would actually matter, you could at the first point when receiving LSA call sha_validate on another core with access to a shared pointer to boolean sha_valid=false, which this other core sets to true, upon validating SHA. Then the original core which is guaranteed to do work exceeding 1us or 10us for that LSA will continue its work, and finally check that sha_valid is true, if not reject the work it did, making the integrity validation free provided it takes less time to validate the integrity than it takes to calculate the topology.
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VV7SJROW...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPVZV7RZ...
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
I think it would be prudent to pay attention to the application OP is talking about. OP is talking about: - password hashes, this can be argued to matter, there are terrific slow hashes for this - validating ISIS LSP, this cannot be argued to matter, the collision isn't valid ISIS LSP All of this information is already on the thread. On Mon, 8 Sept 2025 at 22:24, Owen DeLong via NANOG <nanog@lists.nanog.org> wrote:
Except, it’s not 340282366920938463463 seconds to go, it’s ≤ 340282366920938463463 seconds to go.
That’s the worst case number if the attacker gets his brute force on the last possible attempt.
In reality, one should assume that most brute force attacks will succeed in roughly 1/2 that time, and if any intelligence can be applied to further reduce the search space, frequently, the time can be further reduced, often to between 1/8 and 1/32 of the original total number of hashes, sometimes even more.
So if we’re actually talking about 1/2 of 1/32 of your original number, it’s still 5316911983139663491.609375 seconds which is roughly 61538333138190.5496714 days or approximately 168482773821.19247001 years, so yeah, still reasonably safe, but a lot of people don’t consider these factors when thinking about hash safety, so it is important to bring them up.
Owen
On Sep 8, 2025, at 11:29, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
The hash doesn't need to be slow if there are enough numbers to check. If you have to calculate 340282366920938463463374607431768211456 hashes, it doesn't matter if each one takes a nanosecond and the bad guy has 1 billion computers, because that's still 340282366920938463463 seconds to go.
On 8/09/25 09:59, Vasilenko Eduard via NANOG wrote:
Hi Ytti, Hi Dan, 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. Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Friday, September 5, 2025 18:55 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
On Fri, 5 Sept 2025 at 10: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). Out of curiosity, how did you arrive at 5ms? I don't think it is important, but it is interesting to me.
I'm more arriving at around 1us on core from <10years ago (w/ SHA instruction set) or 10us on older core per ISIS LSA.
But we can't still include even this 1us or 10us to the convergence budget, because NOS almost always has most of the cores doing nothing, due to poor design and no commercial pressure to improve. So if this would actually matter, you could at the first point when receiving LSA call sha_validate on another core with access to a shared pointer to boolean sha_valid=false, which this other core sets to true, upon validating SHA. Then the original core which is guaranteed to do work exceeding 1us or 10us for that LSA will continue its work, and finally check that sha_valid is true, if not reject the work it did, making the integrity validation free provided it takes less time to validate the integrity than it takes to calculate the topology.
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VV7SJROW...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPVZV7RZ...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DC6GLPQH...
-- ++ytti
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
All of these questions have been addressed already in the thread. I have not seen any. Only messages "it could not be the truth". Ed/ -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Monday, September 8, 2025 21:23 To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Dan Collins <dcollinsn@gmail.com> Subject: Re: MD5 is slow
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
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...
On Tue, Sep 9, 2025 at 1:10 AM 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
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> 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...
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, September 9, 2025 22:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow 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/4LF VVQ7VGFM76EPKKFRSEAAXHKBGCREV/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJWFADO...
On Wed, 10 Sept 2025 at 09:12, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
No, not all hashes, only hashes for some application for some reason. MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW acceleration to win SHA competition. You really need to look at your application before you start to define what metrics hash should and should not have. Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice. For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you need collision, but you need the input to be valid and conducive towards your attack vector. I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which turns out to be not good hash for ECMP). -- ++ytti
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:
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...
Hi Ytti, I have to apologize for the subject. I have SHA2/3 in mind because NIST said that MD5 is "not recommended". I have answered Matthew, but it was blocked by the mailman. This answer is very relevant to you too: 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 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 -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 09:39 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 09:12, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
No, not all hashes, only hashes for some application for some reason. MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW acceleration to win SHA competition. You really need to look at your application before you start to define what metrics hash should and should not have. Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice. For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you need collision, but you need the input to be valid and conducive towards your attack vector. I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which turns out to be not good hash for ECMP). -- ++ytti
I didn't read the paper in detail, but it is immaterial if the paper finds performance lacking in some architecture. We are not discussing what is the performance, we are discussing what is the design goal. Design goal is that it should be fast. Here is another SHA3 paper which looks at low, mid, high performance. cores and hardware implementations and reports massively faster SHA3 performance. https://keccak.team/files/Keccak-implementation-3.2.pdf My cursory look at SHA2 I came up thinking that a typical +10y old XEON will do like 10-20cpb, and <10y will do 1-2cpb (when using SHA instruction set). Which is not meaningful contributor to latency and indeed we can amortize this if we are on microseconds budget, as we can do other work while we validate it, before committing to one or another outcome. https://www.cs.haifa.ac.il/~orrd/HashFuncSeminar/Lecture13.pdf - here are SHA3 finalist performances: Skein 4-8cpb Blake 5-10cpb KECCAK 14-16cpb Grøstl 15-35cpb JH 16-45cpb They are not low, because the authors were incompetent. They are both memory and instruction count cheap by design. If you find anecdotes of performances that you consider slow, it doesn't change the fact that the design goal is cheap cycles, cheap memory. Look for argon2, balloon with design goals which would be more conducive towards hashing 8byte passwords. On Wed, 10 Sept 2025 at 09:55, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Hi Ytti, I have to apologize for the subject. I have SHA2/3 in mind because NIST said that MD5 is "not recommended". I have answered Matthew, but it was blocked by the mailman. This answer is very relevant to you too:
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 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 -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 09:39 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 09:12, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
No, not all hashes, only hashes for some application for some reason. MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW acceleration to win SHA competition.
You really need to look at your application before you start to define what metrics hash should and should not have.
Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice.
For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you need collision, but you need the input to be valid and conducive towards your attack vector.
I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which turns out to be not good hash for ECMP).
-- ++ytti
-- ++ytti
This is a professional networking context and you are supposed to know that you are supposed to use a properly generated random password for your BGP sessions. On 10/09/25 08:06, Vasilenko Eduard wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, September 9, 2025 22:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow
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/4LF VVQ7VGFM76EPKKFRSEAAXHKBGCREV/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJWFADO...
On Wed, Sep 10, 2025 at 1:08 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. True, but a digest algorithm (MD5, SHA2, etc) is a cryptographic primitive. It is not a solution to the password problem, but a component that can be used in a secure algorithm.
Message digests are Not designed to address the "weak password" problem. Cryptographic primitives do not provide security properties unless used responsibly. The hash is designed with complexity to resist analytic attacks specifically, Just like AES and other block ciphers are designed with complexity to resist analysis, not to protect you if you provide a weak key as input. The cipher does not work if the key is weak, and a digest does not work if the input is weak.
More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
Real world numbers for SHA2 are in the 10 million hashes per second per CPU core when hashing multiple values in parallel. For protocols such as IP you can independently hash a buffer of packets in series to fill a CPU pipeline, So long as the auth hash for each packet is independent of the auth hash of each other packet. For example; Single-threaded, even my puny desktop CPU can average 0.62 milliseconds per SHA2 hash With unoptimized nodeJS javascript over 15 different single-threaded Iterations with 1500 input bytes each: Sha2(1500 bytes): Start - Sha2 Done: 1.4767500000000098 milliseconds, Hash result: GrTiJlJLamiDP8PIUnsNhumCcCf9yfJMcR/eCZlAIOk= Sha2(1500 bytes): Start - Sha2 Done: 0.13516599999999812 milliseconds, Hash result: jaTVUK6vsXNwGbiT9cmy47DRsKNVjE7gtITEMIBMOws= Sha2(1500 bytes): Start - Sha2 Done: 1.1061659999999875 milliseconds, Hash result: 4ubia4JqMWuq9R4Q35sdq1NJ115+ZK83E/nOz9q9uYo= Sha2(1500 bytes): Start - Sha2 Done: 0.05308299999998667 milliseconds, Hash result: okaqlyoiuIA84fhkpajx4Qx2nsRvStwgeBIShlfzG+4= Sha2(1500 bytes): Start - Sha2 Done: 0.37487500000000296 milliseconds, Hash result: +FnXQpA5clQPxThov0LheQtfxqBmpmh2N3XNuJGNO/g= Sha2(1500 bytes): Start - Sha2 Done: 0.5407499999999885 milliseconds, Hash result: fRqXSApGDmUdonbr0C+At+J0jQpHWJCFMCPF/scV6HY= Sha2(1500 bytes): Start - Sha2 Done: 0.05229199999999423 milliseconds, Hash result: 5QPDcBCyqSezAVf0/lBhBj69ido5hlLq8E2kppBC9h4= Sha2(1500 bytes): Start - Sha2 Done: 0.4628330000000034 milliseconds, Hash result: bSXNEItlxRNio//+nZ9oQPVMnp+WGZzGgMiZpd9TqgE= Sha2(1500 bytes): Start - Sha2 Done: 0.5801250000000095 milliseconds, Hash result: t4X4TZx4jEEZsRZTjZ2uLPAui87FKeRlaWPmAM2n4yc= Sha2(1500 bytes): Start - Sha2 Done: 3.876041999999998 milliseconds, Hash result: NVAA36H5u1hhKLdRi6OvB0L2oE9EUXtGKYUACiC/2cw= Sha2(1500 bytes): Start - Sha2 Done: 0.47479199999999366 milliseconds, Hash result: ecWELiRxHLG7N7J7Mk39DTUlc2bUMUxFdXZ18wQPSWg= Sha2(1500 bytes): Start - Sha2 Done: 0.09158299999999997 milliseconds, Hash result: wYhXGHUsvXj3DbfwCZqjkSQOaMsFS3YBX+8yp6H7siw= Sha2(1500 bytes): Start - Sha2 Done: 0.056416999999996165 milliseconds, Hash result: t4sUzPFMPq4xmgGIeUI5ltL7we6z6Rp0izNUM/7mxcA= Sha2(1500 bytes): Start - Sha2 Done: 0.07050000000000978 milliseconds, Hash result: /5hsS84g0s86g9NsNTxflDcPKfiAT63e+dlNugekqDk= Sha2(1500 bytes): Start - Sha2 Done: 0.05216599999999971 milliseconds, Hash result: flZ3xlAS6e1Jxcfeyl1X+jL8Zj8yzIhHTO+EAx2ZKGk= -------- async function run() { for(i=0;i<15;i++){ var data, result, start, end, dataBuffer; data = new Uint32Array(1500) crypto.getRandomValues(data); dataBuffer = new Uint8Array(data); data = String.fromCharCode.apply(null, dataBuffer); console.log(`Sha2(${data.length} bytes): Start`) start = performance.now(); await crypto.subtle.digest("SHA-256", dataBuffer ).then(function (hash) { result = hash;}); end = performance.now(); console.log(` - Sha2 Done: ${end - start} milliseconds, Hash result: ${btoa(String.fromCharCode(...new Uint8Array(result)))}`) } } run() -- -JA
Hi Jay, Big thanks for the test! This is not a valid assumption: "For protocols such as IP you can independently hash a buffer of packets in series to fill a CPU pipeline". Because if we have a network event, we may have just 1 ISIS LSP to broadcast/propagate. There is a high probability that your "desktop CPU" is more powerful than the CPU used by routing vendors. Especially now, when there is a temptation to move to ARM. Even the best ARM cores are much less powerful than CISC cores. Indeed, 0.6ms looks not important for the control plane. (there was a jump to 3.876ms) I have referenced in a different message how it becomes 4ms average for the best ARM core. Hence, it is probably time for me to accept that hash is meaningful only for RISC architectures. Eduard -----Original Message----- From: Jay Acuna <mysidia@gmail.com> Sent: Wednesday, September 10, 2025 11:19 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow On Wed, Sep 10, 2025 at 1:08 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. True, but a digest algorithm (MD5, SHA2, etc) is a cryptographic primitive. It is not a solution to the password problem, but a component that can be used in a secure algorithm.
Message digests are Not designed to address the "weak password" problem. Cryptographic primitives do not provide security properties unless used responsibly. The hash is designed with complexity to resist analytic attacks specifically, Just like AES and other block ciphers are designed with complexity to resist analysis, not to protect you if you provide a weak key as input. The cipher does not work if the key is weak, and a digest does not work if the input is weak.
More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
Real world numbers for SHA2 are in the 10 million hashes per second per CPU core when hashing multiple values in parallel. For protocols such as IP you can independently hash a buffer of packets in series to fill a CPU pipeline, So long as the auth hash for each packet is independent of the auth hash of each other packet. For example; Single-threaded, even my puny desktop CPU can average 0.62 milliseconds per SHA2 hash With unoptimized nodeJS javascript over 15 different single-threaded Iterations with 1500 input bytes each: Sha2(1500 bytes): Start - Sha2 Done: 1.4767500000000098 milliseconds, Hash result: GrTiJlJLamiDP8PIUnsNhumCcCf9yfJMcR/eCZlAIOk= Sha2(1500 bytes): Start - Sha2 Done: 0.13516599999999812 milliseconds, Hash result: jaTVUK6vsXNwGbiT9cmy47DRsKNVjE7gtITEMIBMOws= Sha2(1500 bytes): Start - Sha2 Done: 1.1061659999999875 milliseconds, Hash result: 4ubia4JqMWuq9R4Q35sdq1NJ115+ZK83E/nOz9q9uYo= Sha2(1500 bytes): Start - Sha2 Done: 0.05308299999998667 milliseconds, Hash result: okaqlyoiuIA84fhkpajx4Qx2nsRvStwgeBIShlfzG+4= Sha2(1500 bytes): Start - Sha2 Done: 0.37487500000000296 milliseconds, Hash result: +FnXQpA5clQPxThov0LheQtfxqBmpmh2N3XNuJGNO/g= Sha2(1500 bytes): Start - Sha2 Done: 0.5407499999999885 milliseconds, Hash result: fRqXSApGDmUdonbr0C+At+J0jQpHWJCFMCPF/scV6HY= Sha2(1500 bytes): Start - Sha2 Done: 0.05229199999999423 milliseconds, Hash result: 5QPDcBCyqSezAVf0/lBhBj69ido5hlLq8E2kppBC9h4= Sha2(1500 bytes): Start - Sha2 Done: 0.4628330000000034 milliseconds, Hash result: bSXNEItlxRNio//+nZ9oQPVMnp+WGZzGgMiZpd9TqgE= Sha2(1500 bytes): Start - Sha2 Done: 0.5801250000000095 milliseconds, Hash result: t4X4TZx4jEEZsRZTjZ2uLPAui87FKeRlaWPmAM2n4yc= Sha2(1500 bytes): Start - Sha2 Done: 3.876041999999998 milliseconds, Hash result: NVAA36H5u1hhKLdRi6OvB0L2oE9EUXtGKYUACiC/2cw= Sha2(1500 bytes): Start - Sha2 Done: 0.47479199999999366 milliseconds, Hash result: ecWELiRxHLG7N7J7Mk39DTUlc2bUMUxFdXZ18wQPSWg= Sha2(1500 bytes): Start - Sha2 Done: 0.09158299999999997 milliseconds, Hash result: wYhXGHUsvXj3DbfwCZqjkSQOaMsFS3YBX+8yp6H7siw= Sha2(1500 bytes): Start - Sha2 Done: 0.056416999999996165 milliseconds, Hash result: t4sUzPFMPq4xmgGIeUI5ltL7we6z6Rp0izNUM/7mxcA= Sha2(1500 bytes): Start - Sha2 Done: 0.07050000000000978 milliseconds, Hash result: /5hsS84g0s86g9NsNTxflDcPKfiAT63e+dlNugekqDk= Sha2(1500 bytes): Start - Sha2 Done: 0.05216599999999971 milliseconds, Hash result: flZ3xlAS6e1Jxcfeyl1X+jL8Zj8yzIhHTO+EAx2ZKGk= -------- async function run() { for(i=0;i<15;i++){ var data, result, start, end, dataBuffer; data = new Uint32Array(1500) crypto.getRandomValues(data); dataBuffer = new Uint8Array(data); data = String.fromCharCode.apply(null, dataBuffer); console.log(`Sha2(${data.length} bytes): Start`) start = performance.now(); await crypto.subtle.digest("SHA-256", dataBuffer ).then(function (hash) { result = hash;}); end = performance.now(); console.log(` - Sha2 Done: ${end - start} milliseconds, Hash result: ${btoa(String.fromCharCode(...new Uint8Array(result)))}`) } } run() -- -JA
Hi Ytti,
https://keccak.team/files/Keccak-implementation-3.2.pdf Thanks, I did read with middle attention. Looks like people did think a lot about how to optimize SHA-3. Because if they do not optimize it, hackers could - it would give them an advantage.
For Kђѐѐюј-f [1600] specifically, this becomes: • 1824 XORs, • 600 ANDs and 600 NOTs, and • 696 64-bit rotations. For such a number of operations, whatever would be done for optimization, it could not be "fast" in the end.
Design goal is that it should be fast. I do not agree; it was just an attempt to check the limits. Because if the particular hash would be too fast on any implementation (on any platform), Then it would not be secure - it would be susceptible to brute force. Hash should be slow enough for the fastest platform, then it makes sense to optimize it for all other platforms.
Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 10:22 To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: MD5 is slow I didn't read the paper in detail, but it is immaterial if the paper finds performance lacking in some architecture. We are not discussing what is the performance, we are discussing what is the design goal. Design goal is that it should be fast. Here is another SHA3 paper which looks at low, mid, high performance. cores and hardware implementations and reports massively faster SHA3 performance. https://keccak.team/files/Keccak-implementation-3.2.pdf My cursory look at SHA2 I came up thinking that a typical +10y old XEON will do like 10-20cpb, and <10y will do 1-2cpb (when using SHA instruction set). Which is not meaningful contributor to latency and indeed we can amortize this if we are on microseconds budget, as we can do other work while we validate it, before committing to one or another outcome. https://www.cs.haifa.ac.il/~orrd/HashFuncSeminar/Lecture13.pdf - here are SHA3 finalist performances: Skein 4-8cpb Blake 5-10cpb KECCAK 14-16cpb Grøstl 15-35cpb JH 16-45cpb They are not low, because the authors were incompetent. They are both memory and instruction count cheap by design. If you find anecdotes of performances that you consider slow, it doesn't change the fact that the design goal is cheap cycles, cheap memory. Look for argon2, balloon with design goals which would be more conducive towards hashing 8byte passwords. On Wed, 10 Sept 2025 at 09:55, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Hi Ytti, I have to apologize for the subject. I have SHA2/3 in mind because NIST said that MD5 is "not recommended". I have answered Matthew, but it was blocked by the mailman. This answer is very relevant to you too:
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 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 -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 09:39 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 09:12, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
No, not all hashes, only hashes for some application for some reason. MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW acceleration to win SHA competition.
You really need to look at your application before you start to define what metrics hash should and should not have.
Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice.
For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you need collision, but you need the input to be valid and conducive towards your attack vector.
I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which turns out to be not good hash for ECMP).
-- ++ytti
-- ++ytti
It may be that people designing the hash did not think about weak passwords. 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. Ed/ -----Original Message----- From: nanog@immibis.com <nanog@immibis.com> Sent: Wednesday, September 10, 2025 11:04 To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: Re: MD5 is slow This is a professional networking context and you are supposed to know that you are supposed to use a properly generated random password for your BGP sessions. On 10/09/25 08:06, Vasilenko Eduard wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, September 9, 2025 22:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow
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/4 LF VVQ7VGFM76EPKKFRSEAAXHKBGCREV/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BN JWFADODFXFOURBOKXOAW2FQW2R5L5W/
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
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
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/5E22LVBX...
It may be that people designing the hash did not think about weak passwords. 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. Ed/ -----Original Message----- From: nanog@immibis.com <nanog@immibis.com> Sent: Wednesday, September 10, 2025 11:04 To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: Re: MD5 is slow This is a professional networking context and you are supposed to know that you are supposed to use a properly generated random password for your BGP sessions. On 10/09/25 08:06, Vasilenko Eduard wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, September 9, 2025 22:53 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow
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/4 LF VVQ7VGFM76EPKKFRSEAAXHKBGCREV/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BN JWFADODFXFOURBOKXOAW2FQW2R5L5W/
Please stop obsessing over the speed of hashing. Slow hashes are used on end user protocols where the password has to be something that is easy to remember by a user. The password used in BGP-MD5 doesn't have to be remembered by anyone and should be a completely random string, and there are so many possibilities that using a slow hash is irrelevant. A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware. On 10 September 2025 11:52:04 CEST, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
Hi Ytti,
https://keccak.team/files/Keccak-implementation-3.2.pdf Thanks, I did read with middle attention. Looks like people did think a lot about how to optimize SHA-3. Because if they do not optimize it, hackers could - it would give them an advantage.
For Kђѐѐюј-f [1600] specifically, this becomes: • 1824 XORs, • 600 ANDs and 600 NOTs, and • 696 64-bit rotations. For such a number of operations, whatever would be done for optimization, it could not be "fast" in the end.
Design goal is that it should be fast. I do not agree; it was just an attempt to check the limits. Because if the particular hash would be too fast on any implementation (on any platform), Then it would not be secure - it would be susceptible to brute force. Hash should be slow enough for the fastest platform, then it makes sense to optimize it for all other platforms.
Eduard -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 10:22 To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Cc: North American Network Operators Group <nanog@lists.nanog.org> Subject: Re: MD5 is slow
I didn't read the paper in detail, but it is immaterial if the paper finds performance lacking in some architecture. We are not discussing what is the performance, we are discussing what is the design goal. Design goal is that it should be fast. Here is another SHA3 paper which looks at low, mid, high performance. cores and hardware implementations and reports massively faster SHA3 performance. https://keccak.team/files/Keccak-implementation-3.2.pdf
My cursory look at SHA2 I came up thinking that a typical +10y old XEON will do like 10-20cpb, and <10y will do 1-2cpb (when using SHA instruction set). Which is not meaningful contributor to latency and indeed we can amortize this if we are on microseconds budget, as we can do other work while we validate it, before committing to one or another outcome.
https://www.cs.haifa.ac.il/~orrd/HashFuncSeminar/Lecture13.pdf - here are SHA3 finalist performances: Skein 4-8cpb Blake 5-10cpb KECCAK 14-16cpb Grøstl 15-35cpb JH 16-45cpb
They are not low, because the authors were incompetent. They are both memory and instruction count cheap by design. If you find anecdotes of performances that you consider slow, it doesn't change the fact that the design goal is cheap cycles, cheap memory.
Look for argon2, balloon with design goals which would be more conducive towards hashing 8byte passwords.
On Wed, 10 Sept 2025 at 09:55, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Hi Ytti, I have to apologize for the subject. I have SHA2/3 in mind because NIST said that MD5 is "not recommended". I have answered Matthew, but it was blocked by the mailman. This answer is very relevant to you too:
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 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 -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Wednesday, September 10, 2025 09:39 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 09:12, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
But it's reality. Many passwords are not strong enough. More importantly, hash has XX rounds to give a really random output. Hence, the hash is designed to be slow.
No, not all hashes, only hashes for some application for some reason. MD5, SHA are designed to be fast. You can look into SHA competition and see that CPB is a metric which they are measured against. They have to be fast in the existing instruction set and they have to be friendly towards HW acceleration to win SHA competition.
You really need to look at your application before you start to define what metrics hash should and should not have.
Yes, for password hashing (like legacy unix 8 bytes) MD5 was a poor choice.
For authenticating ISIS, BGP whatever, there is absolutely no reason for it to be slow. In the above example you need collision, any input string will be accepted. For BGP MD5, TCP-AO, it is authenticating the _message_, not only you need collision, but you need the input to be valid and conducive towards your attack vector.
I continue to be at loss, this thread has made these points repeatedly. It is also easy to verify out of the thread that you are not being misled when you are told being slow is not only a non-goal but undesirable for most hash use cases. And there are many hash use cases, your programming language needs hash to do associative arrays, your switch needs hash to do ECMP (which is interesting topic onto itself, as we used to use same CRC as for ethernet FCS, which turns out to be not good hash for ECMP).
-- ++ytti
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BAR3QJ4J...
BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on the alien domain). Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”. If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681> Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, September 10, 2025 15:28 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow 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<mailto: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<mailto:saku@ytti.fi>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto: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<mailto: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/5E22LVBX...
Once upon a time, nanog@immibis.com <nanog@immibis.com> said:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU. -- Chris Adams <cma@cmadams.net>
Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets being associated with hashing? Operationally, I'm getting from this that spoofing IGP packets is a popular pastime. Nich -----Original Message----- From: Vasilenko Eduard via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 8:25 AM To: Tom Beecher <beecher@beecher.cc>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: RE: MD5 is slow BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on the alien domain). Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”. If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681> Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, September 10, 2025 15:28 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow 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<mailto: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<mailto:saku@ytti.fi>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto: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<mailto: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/5E22LVBX... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q7RJ7HFD...
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU.
Anything reasonably newer on MX has Haswell or Icy Lakes in them, and multicore. But even that Ford Model T of an MX80 wouldn't flinch at MD5 operations. On Wed, Sep 10, 2025 at 9:33 AM Chris Adams via NANOG <nanog@lists.nanog.org> wrote:
Once upon a time, nanog@immibis.com <nanog@immibis.com> said:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU. -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RI46RBUW...
On Wed, Sep 10, 2025 at 8:20 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
Perfect. The CPU of a Pi as in an ARMv7 is far too low to efficiently bear the load involved in IGP calculations for a large network. Let alone a full BGP table. Network vendors have chosen and will choose procs and application-specific circuits adequate to the task for MD5 or SHA2. This is not a problem. If the ARM cannot hash quickly; the gear will likely contain logic circuits and software modules optimized for efficient hashing to achieve acceptable latency. Even that underpowered Pi Zero seems capable hashing within a 1 millisecond interval just fine using standard libraries. SHA-3 is not operationally relevant, but the slowest of those algorithms still speed measures as hashing 4 Kilobytes within a millisecond interval. $ ssh piuser@mordor.elysium 'sudo apt -y install botan >/dev/null 2>&1; tail -15 /proc/cpuinfo; botan speed --buf-size=1500 --msec=1 SHA-256 SHA-384 SHA-3' Enter passphrase for key '/home/shadowfax/.ssh/yubikey5ec01': Confirm user presence for key * User presence confirmed processor : 3 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : BCM2835 Revision : 902120 Serial : 000000002d61f097 Model : Raspberry Pi Zero 2 W Rev 1.0 SHA-256 hash buffer size 1500 bytes: 24.384 MiB/sec (0.026 MiB in 1.056 ms) SHA-384 hash buffer size 1500 bytes: 7.719 MiB/sec (0.009 MiB in 1.112 ms) SHA-3(512) hash buffer size 1500 bytes: 4.254 MiB/sec (0.004 MiB in 1.009 ms) $ -- -JA
The MD5 option of BGP (or TCP more generally, but only BGP really uses it) combines each TCP packet with a password that's configured the same on both sides of the connection, then hashes the combination, and transmits it in the packet. The receiver does the same calculation, and if the receiver's calculated hash doesn't match the one in the packet, it ignores the packet. This procedure is more specifically called a "message authentication code" or MAC and the password is actually a "key" for the MAC. On 10 September 2025 15:53:17 CEST, Nicholas Warren via NANOG <nanog@lists.nanog.org> wrote:
Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets being associated with hashing?
Operationally, I'm getting from this that spoofing IGP packets is a popular pastime.
Nich
-----Original Message----- From: Vasilenko Eduard via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 8:25 AM To: Tom Beecher <beecher@beecher.cc>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: RE: MD5 is slow
BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on the alien domain).
Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”. If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681>
Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, September 10, 2025 15:28 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
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<mailto: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<mailto:saku@ytti.fi>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto: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<mailto: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/5E22LVBX... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q7RJ7HFD... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZVGRMCGR...
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.eduard@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
Because the BGP is not relevant (event propagation time is not important, not to the ms level), I would prefer the same explanation, but in relation to ISIS or OSPF. Yes, it is called MAC. Example configuration is explained, for example, here: https://netquirks.co.uk/wp-content/uploads/2023/03/is-is-md5-authentication.... Eduard -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 20:07 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow The MD5 option of BGP (or TCP more generally, but only BGP really uses it) combines each TCP packet with a password that's configured the same on both sides of the connection, then hashes the combination, and transmits it in the packet. The receiver does the same calculation, and if the receiver's calculated hash doesn't match the one in the packet, it ignores the packet. This procedure is more specifically called a "message authentication code" or MAC and the password is actually a "key" for the MAC. On 10 September 2025 15:53:17 CEST, Nicholas Warren via NANOG <nanog@lists.nanog.org> wrote:
Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets being associated with hashing?
Operationally, I'm getting from this that spoofing IGP packets is a popular pastime.
Nich
-----Original Message----- From: Vasilenko Eduard via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 8:25 AM To: Tom Beecher <beecher@beecher.cc>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: RE: MD5 is slow
BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on the alien domain).
Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”. If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681>
Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, September 10, 2025 15:28 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
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<mailto: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<mailto:saku@ytti.fi>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto: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<mailto: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/5E2 2LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q7R J7HFDGPW3D45PJGWSX5GJ5H3BLSV3/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZVG RMCGRF4OZN2UKUAYITCSMG6SXYPTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UYFO4NJY...
There is a trend to move to ARM on desktops. Apple has finished. Microsoft has ambitious plans. RISC architecture is gaining more attention now. It is the trend that makes sense to support. RISC has consequences: more cores, greater effectiveness (in terms of power and cost), and a lower cost per workload, but fewer resources per core (always) and lower frequency (typically). Pointing to CISC is not in the trend. Agree, CISC is probably fast enough not to pay attention to the hash calculation time (if you do not care about an additional 1ms*2(input/output)*5(hops) on the control plane). Ed/ -----Original Message----- From: Tom Beecher via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 17:36 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Beecher <beecher@beecher.cc> Subject: Re: MD5 is slow
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU.
Anything reasonably newer on MX has Haswell or Icy Lakes in them, and multicore. But even that Ford Model T of an MX80 wouldn't flinch at MD5 operations. On Wed, Sep 10, 2025 at 9:33 AM Chris Adams via NANOG <nanog@lists.nanog.org> wrote:
Once upon a time, nanog@immibis.com <nanog@immibis.com> said:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU. -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RI 46RBUWSGZU7CWSCOPIB6SQZNWIIJYE/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BE3UNLEP...
Talking about IA is almost nonsense, it doesn't have any implied performance losses or gains. RISC/CISC is utterly uninteresting in the modern world. For more than 20 years CPUs have not executed the code compilers deliver to them. There is a front-end that translates the standard IA into some proprietary micro ops the CPU uses. We could argue this is really bad, as the compiler has no control over execution. But the reality is the compiler is terrible and produces code that doesn't have sufficient information how to run it fast. So to run that low information code fast, hardware designers came up with this design where hardware does magic tricks (which will inherently make CPU unsafe) to usually run code very fast. In Itanium Intel tried to fix this, it tried to make the CPU dumb, and the compiler smart. But no one ever produced a smart compiler for Itanium. Turns out, it is a lot easier to make a business case out of selling CPU hardware than it is to make a business case out of selling smart compiler licenses. So we have a lot of R&D budget to make CPUs increasingly complex and increasingly detached from the instruction set, and no R&D budget to make smart compilers which emit enough information to run the code fast without unsafe assumptions made by HW. There is no particular reason why the CPU couldn't have two front-ends and run two IA using its proprietary micro ops. You can certainly have SHA instruction set in ARM: https://developer.arm.com/documentation/ddi0602/2025-06/SIMD-FP-Instructions... https://datatracker.ietf.org/doc/html/rfc2385 Some measurements of a sample implementation showed that on a 100 MHz R4600, generating a signature for simple ACK segment took an average of 0.0268 ms, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. This is an over 20 years old CPU, even then the MD5 cost was under millisecond. But it actually mattered much more, because the same core was doing packet lookup and copying memory. This R4600 was used in NPE100, NPE150 in 7200, amongst others. If you want to believe that MD5 and SHA are intentionally slow, I apologise for trying to rob that joy from you and will not do it again. On Thu, 11 Sept 2025 at 09:23, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
There is a trend to move to ARM on desktops. Apple has finished. Microsoft has ambitious plans. RISC architecture is gaining more attention now. It is the trend that makes sense to support.
RISC has consequences: more cores, greater effectiveness (in terms of power and cost), and a lower cost per workload, but fewer resources per core (always) and lower frequency (typically).
Pointing to CISC is not in the trend. Agree, CISC is probably fast enough not to pay attention to the hash calculation time (if you do not care about an additional 1ms*2(input/output)*5(hops) on the control plane). Ed/ -----Original Message----- From: Tom Beecher via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 17:36 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Beecher <beecher@beecher.cc> Subject: Re: MD5 is slow
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU.
Anything reasonably newer on MX has Haswell or Icy Lakes in them, and multicore. But even that Ford Model T of an MX80 wouldn't flinch at MD5 operations.
On Wed, Sep 10, 2025 at 9:33 AM Chris Adams via NANOG <nanog@lists.nanog.org> wrote:
Once upon a time, nanog@immibis.com <nanog@immibis.com> said:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
I don't know what's common right this minute (as I haven't been shopping for routers for a bit), but for example, all the Juniper MXes outside of the MX80 have been competent-to-beefy Intel CPUs. I don't think the routers likely to be running a lot of BGP are going to be using some low-end CPU. -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RI 46RBUWSGZU7CWSCOPIB6SQZNWIIJYE/
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BE3UNLEP... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/R2MNUBZ6...
-- ++ytti
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 <mpetach@netflight.com> Sent: Wednesday, September 10, 2025 23:01 To: Vasilenko Eduard <vasilenko.eduard@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.eduard@huawei.com<mailto:vasilenko.eduard@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
On Thu, 11 Sept 2025 at 10:28, 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.
It just takes time. But if you have demand for SHA-3, you can absolutely use SHA-3 in TCP-AO, if you control both ends. And then you could write RFC for it, and ask vendors to support this RFC for TCP-AO.
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.
It is already microseconds for the majority of cases.
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.
No they were not :(. The design called for as fast as it can be, for the more critical metrics it had. Preventing brute force by artificial cost was never a design goal. You have memory and time expensive hashes that do what you think SHA and MD5 do. -- ++ytti
On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
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.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)? /Bellman
Hi Jay, Big thanks for the tests. Botan uses ARM hardware acceleration by default: https://botan.randombit.net/handbook/hardware_acceleration.html. But ARMv7 has it only for SHA-256, not for SHA-384 or SHA-512 (ARMv8 is needed). It is probably the reason for the big difference between SHA-256 and others. (3x is what many claimed for the acceleration). OK. The problem does not exist. Eduard -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 18:04 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jay Acuna <mysidia@gmail.com> Subject: Re: MD5 is slow On Wed, Sep 10, 2025 at 8:20 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
A hash is also way faster than 5ms to compute. I suggest doing your own benchmark. Run it on an old raspberry pi or one of Amazon's cheapest ARM servers to be sure it's comparable to typical router CPU hardware.
Perfect. The CPU of a Pi as in an ARMv7 is far too low to efficiently bear the load involved in IGP calculations for a large network. Let alone a full BGP table. Network vendors have chosen and will choose procs and application-specific circuits adequate to the task for MD5 or SHA2. This is not a problem. If the ARM cannot hash quickly; the gear will likely contain logic circuits and software modules optimized for efficient hashing to achieve acceptable latency. Even that underpowered Pi Zero seems capable hashing within a 1 millisecond interval just fine using standard libraries. SHA-3 is not operationally relevant, but the slowest of those algorithms still speed measures as hashing 4 Kilobytes within a millisecond interval. $ ssh piuser@mordor.elysium 'sudo apt -y install botan >/dev/null 2>&1; tail -15 /proc/cpuinfo; botan speed --buf-size=1500 --msec=1 SHA-256 SHA-384 SHA-3' Enter passphrase for key '/home/shadowfax/.ssh/yubikey5ec01': Confirm user presence for key * User presence confirmed processor : 3 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : BCM2835 Revision : 902120 Serial : 000000002d61f097 Model : Raspberry Pi Zero 2 W Rev 1.0 SHA-256 hash buffer size 1500 bytes: 24.384 MiB/sec (0.026 MiB in 1.056 ms) SHA-384 hash buffer size 1500 bytes: 7.719 MiB/sec (0.009 MiB in 1.112 ms) SHA-3(512) hash buffer size 1500 bytes: 4.254 MiB/sec (0.004 MiB in 1.009 ms) $ -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/26VERQIL...
The simple integer division on the processor takes something like 40 cycles (fast). Hence, the factorization challenge should have thousands of bits. Then it is going to take millions of years for one processor to try all possibilities. If the password is just 12 letters (80 bits?), then the time to test the password should be longer. Or else the good processor would try all combinations for a limited time. Of course, a longer password would help a lot, but even 200 bits is not 2000. The check should be proportionally slower. It is especially a problem when we are dealing with predictable passwords based on human language words. Maybe SHA-2/3 have not been developed with "slowness" as a goal. It may be that only randomness was the target. Hence, so many assembler instructions for one round. But only the slowness permits its use for HMAC or the password fingerprint that you have discussed before. I could not believe that slowness is just a byproduct of randomness. It is so evident why it is needed by itself (for some applications). Ed/ -----Original Message----- From: Thomas Bellman via NANOG <nanog@lists.nanog.org> Sent: Thursday, September 11, 2025 12:03 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Thomas Bellman <bellman@nsc.liu.se> Subject: Re: MD5 is slow On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
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.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)? /Bellman
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
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords? Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords? On 11 September 2025 12:18:00 CEST, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
The simple integer division on the processor takes something like 40 cycles (fast). Hence, the factorization challenge should have thousands of bits. Then it is going to take millions of years for one processor to try all possibilities.
If the password is just 12 letters (80 bits?), then the time to test the password should be longer. Or else the good processor would try all combinations for a limited time. Of course, a longer password would help a lot, but even 200 bits is not 2000. The check should be proportionally slower. It is especially a problem when we are dealing with predictable passwords based on human language words.
Maybe SHA-2/3 have not been developed with "slowness" as a goal. It may be that only randomness was the target. Hence, so many assembler instructions for one round. But only the slowness permits its use for HMAC or the password fingerprint that you have discussed before. I could not believe that slowness is just a byproduct of randomness. It is so evident why it is needed by itself (for some applications). Ed/ -----Original Message----- From: Thomas Bellman via NANOG <nanog@lists.nanog.org> Sent: Thursday, September 11, 2025 12:03 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Thomas Bellman <bellman@nsc.liu.se> Subject: Re: MD5 is slow
On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
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.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)?
/Bellman
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SZV2BS2W...
One thing to keep in mind - the generally accepted solution for making a hash or encryption algorithm “slow” is to simply iterate, feeding the output of the function back into itself a given number of times. As an hopefully not apples-to-oranges example, 1Password iterates on the PDKDF2 algorithm 650,000 times to decrypt a vault’s key using user input. When running md5 iteratively in a small python script on my mid-range laptop, 1 million iterations takes .26 seconds, certainly fast enough for a user operation but extremely resistant to a brute force attack when the maximum guess rate is about 4 tries per execution block per second. If a GPU’s matrix math can dramatically speed this up, I’d be curious to what degree. In other words, employing a “slow" algorithm in order to resist a brute force attack does not appear to be the best way to do so, by a long shot. -Chris
On Sep 11, 2025, at 02:02, Thomas Bellman via NANOG <nanog@lists.nanog.org> wrote:
On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
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.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)?
/Bellman
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZTQZQCQR...
I would prefer the same explanation, but in relation to ISIS or OSPF.
I addressed this previously. IS-IS and OSPF both have delays so that SPF isn't constantly running if a given network is unstable. Take for example an IS-IS network on a Juniper. By default : - For a point to point interface, R1 transmits CSNPs every 5000ms. - R2 receives CSNP, and updates its LSDB. - LSDB change = topology change. R2 starts a 200ms timer before running SPF. - If additional CSNPs are received such that R2 runs SPF 3 times in succession. ( 600ms ) , R2 starts a holddown timer, preventing any additional SPF runs for the next 5000ms. If you changed values to their platform minimums : - csnp tx interval : 1000ms - spf delay : 50ms So your BEST case is still 1050ms + 1/2 link RTT. ( These would probably be really bad to use in a real network too. ) Does this make it clear why even a couple theoretical extra ms of processing time is not a concern? On Thu, Sep 11, 2025 at 2:05 AM Vasilenko Eduard via NANOG < nanog@lists.nanog.org> wrote:
Because the BGP is not relevant (event propagation time is not important, not to the ms level), I would prefer the same explanation, but in relation to ISIS or OSPF. Yes, it is called MAC. Example configuration is explained, for example, here: https://netquirks.co.uk/wp-content/uploads/2023/03/is-is-md5-authentication.... Eduard -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 20:07 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: nanog@immibis.com Subject: RE: MD5 is slow
The MD5 option of BGP (or TCP more generally, but only BGP really uses it) combines each TCP packet with a password that's configured the same on both sides of the connection, then hashes the combination, and transmits it in the packet. The receiver does the same calculation, and if the receiver's calculated hash doesn't match the one in the packet, it ignores the packet.
This procedure is more specifically called a "message authentication code" or MAC and the password is actually a "key" for the MAC.
Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets being associated with hashing?
Operationally, I'm getting from this that spoofing IGP packets is a
On 10 September 2025 15:53:17 CEST, Nicholas Warren via NANOG < nanog@lists.nanog.org> wrote: popular pastime.
Nich
-----Original Message----- From: Vasilenko Eduard via NANOG <nanog@lists.nanog.org> Sent: Wednesday, September 10, 2025 8:25 AM To: Tom Beecher <beecher@beecher.cc>; North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: RE: MD5 is slow
BGP would never be fast, because it could be a DDoS attack vector by
itself (push expensive BGP to run very often on the alien domain).
Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the
If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681>
Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, September 10, 2025 15:28 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi>; Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow
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
“sub-second”. 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<mailto: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<mailto:saku@ytti.fi>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto: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<mailto: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/5E2 2LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q7R J7HFDGPW3D45PJGWSX5GJ5H3BLSV3/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZVG RMCGRF4OZN2UKUAYITCSMG6SXYPTL/
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UYFO4NJY... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EGMXOLSP...
Let me do a little calculation here. Imagine that we have access to one server with 8 cards "NVIDIA GeForce RTX 5090". Every respected black or white hacker (including pintesters) has access to something similar. Then we could do MD5 hash calculations (for one block) with the performance 1.72*10^12 hashes per second. I have assumed Hashcat 7 that such people use extensively: https://openbenchmarking.org/test/pts/hashcat&eval=7b7b45c3848e0a5482fb82f220518d5233961430#metrics Imagine a person who would like to protect the password. The password is typed on the keyboard, let's say 75 different characters (upper case, lower case, numbers, special symbols). Assume that the person is very accurate and generates 10 letters really random. Then it is 5.6*10^18 of combinations. Hence, the server (with Hashcat) would try all potential passwords and find the right one for an average of 19 days (average is /2 from the worst case). If 10 letters are not completely random (English words are used, even partially), then the search could be greatly optimized. Access to a larger number of GPUs would make the time (to crack the password) ridiculously small. I doubt that 19 days is a good protection for a password! The password typed manually should last for a much longer time - you could torment people in any way, but you would not be capable of achieving a faster password rotation. There is no way to fix MD5 for plain password protection. There is the possibility for networking protocols to organize *automatic* passwords/keys rotation (every night?), and additionally generate longer keys (32 bytes?) in a really random way. Then MD5 would be applicable again. It is the reason why IT guys use “Bcrypt” or “Argon” for password hashing -> even the best GPU is going to waste a big enough time (millions of years). By the way, it is related to the previous thread on the MD5 strength - it does not have it. One would say that it is not an MD5 problem, it is a password problem (length, rotation), but it does not matter - the problem persists anyway. Moving to the slower hash is the solution that was adopted by IT, because it is much more difficult to push users to generate strong passwords and rotate them very often. Maybe in this way it would be possible to explain why "not MD5" for password hashing. Eduard -----Original Message----- From: Vasilenko Eduard Sent: Thursday, September 11, 2025 13:18 To: 'North American Network Operators Group' <nanog@lists.nanog.org> Cc: Thomas Bellman <bellman@nsc.liu.se> Subject: RE: MD5 is slow The simple integer division on the processor takes something like 40 cycles (fast). Hence, the factorization challenge should have thousands of bits. Then it is going to take millions of years for one processor to try all possibilities. If the password is just 12 letters (80 bits?), then the time to test the password should be longer. Or else the good processor would try all combinations for a limited time. Of course, a longer password would help a lot, but even 200 bits is not 2000. The check should be proportionally slower. It is especially a problem when we are dealing with predictable passwords based on human language words. Maybe SHA-2/3 have not been developed with "slowness" as a goal. It may be that only randomness was the target. Hence, so many assembler instructions for one round. But only the slowness permits its use for HMAC or the password fingerprint that you have discussed before. I could not believe that slowness is just a byproduct of randomness. It is so evident why it is needed by itself (for some applications). Ed/ -----Original Message----- From: Thomas Bellman via NANOG <nanog@lists.nanog.org> Sent: Thursday, September 11, 2025 12:03 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Thomas Bellman <bellman@nsc.liu.se> Subject: Re: MD5 is slow On 2025-09-11 09:23, Vasilenko Eduard via NANOG wrote:
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.
Since you are asserting that the hash functions must be "slow" in order to resist brute force attacks, could you perhaps give us an estimate of *how* slow they must be? And how you arrive at that (e.g. how much resources does the attacker deploy, and how long walltime do you give the attacker)? /Bellman
Hi Tom, I do not want to discuss “why in 1st place” for 2 reasons: 1. It is not related to the previous discussion 2. I mostly agree with you: it is not a good idea to squeeze everything possible from something; the network is becoming fragile after such an exercise (I have seen it many times). But people are doing it! For my 30 years in networking, I have seen these “sub-second” discussions and other “IGP speed optimizations” many times. For example: convergence-time.dvi<https://www.cs.princeton.edu/courses/archive/fall10/cos561/papers/IGPconverge05.pdf> RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/rfc9681/> Like we or not. I remember that it was possible to achieve something like 600ms. The article above claims even less (3x better for small scale network). 30ms (over 5 hops) could be 5% which is visible. But it would be no 30ms, I have failed with my assumption based on the academic document, Jay Acuna has proved it to me. It would be 2.5ms (over 5 hops) even for SHA-3, - I do not believe it is relevant. We could park this discussion. MD5 is fast enough not to create a latency problem (and additionally not to protect anything because of this). Eduard From: Tom Beecher <beecher@beecher.cc> Sent: Thursday, September 11, 2025 19:25 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: Re: MD5 is slow I would prefer the same explanation, but in relation to ISIS or OSPF. I addressed this previously. IS-IS and OSPF both have delays so that SPF isn't constantly running if a given network is unstable. Take for example an IS-IS network on a Juniper. By default : - For a point to point interface, R1 transmits CSNPs every 5000ms. - R2 receives CSNP, and updates its LSDB. - LSDB change = topology change. R2 starts a 200ms timer before running SPF. - If additional CSNPs are received such that R2 runs SPF 3 times in succession. ( 600ms ) , R2 starts a holddown timer, preventing any additional SPF runs for the next 5000ms. If you changed values to their platform minimums : - csnp tx interval : 1000ms - spf delay : 50ms So your BEST case is still 1050ms + 1/2 link RTT. ( These would probably be really bad to use in a real network too. ) Does this make it clear why even a couple theoretical extra ms of processing time is not a concern? On Thu, Sep 11, 2025 at 2:05 AM Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Because the BGP is not relevant (event propagation time is not important, not to the ms level), I would prefer the same explanation, but in relation to ISIS or OSPF. Yes, it is called MAC. Example configuration is explained, for example, here: https://netquirks.co.uk/wp-content/uploads/2023/03/is-is-md5-authentication.... Eduard -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Wednesday, September 10, 2025 20:07 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: nanog@immibis.com<mailto:nanog@immibis.com> Subject: RE: MD5 is slow The MD5 option of BGP (or TCP more generally, but only BGP really uses it) combines each TCP packet with a password that's configured the same on both sides of the connection, then hashes the combination, and transmits it in the packet. The receiver does the same calculation, and if the receiver's calculated hash doesn't match the one in the packet, it ignores the packet. This procedure is more specifically called a "message authentication code" or MAC and the password is actually a "key" for the MAC. On 10 September 2025 15:53:17 CEST, Nicholas Warren via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote:
Can someone with experience in list discussions tell me what's happening right now? Why are passwords and secrets being associated with hashing?
Operationally, I'm getting from this that spoofing IGP packets is a popular pastime.
Nich
-----Original Message----- From: Vasilenko Eduard via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Wednesday, September 10, 2025 8:25 AM To: Tom Beecher <beecher@beecher.cc<mailto:beecher@beecher.cc>>; North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Subject: RE: MD5 is slow
BGP would never be fast, because it could be a DDoS attack vector by itself (push expensive BGP to run very often on the alien domain).
Many people did tuning of the IGP to achieve “sub-second”. Some number of ms * a few hops * 2 => it is something like 1/5 of the “sub-second”. If it is not important, why do people do something like this RFC 9681 - IS-IS Fast Flooding<https://datatracker.ietf.org/doc/html/rfc9681>
Symmetric encryption may be used only for authentication. But it is better to encrypt the whole header if symmetric encryption is available. Eduard From: Tom Beecher <beecher@beecher.cc<mailto:beecher@beecher.cc>> Sent: Wednesday, September 10, 2025 15:28 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>>; Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Subject: Re: MD5 is slow
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<mailto:nanog@lists.nanog.org><mailto:nanog@lists.nanog.org<mailto: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<mailto:saku@ytti.fi><mailto:saku@ytti.fi<mailto:saku@ytti.fi>>> Sent: Wednesday, September 10, 2025 13:11 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org><mailto:nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>>> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com><mailto:vasilenko.eduard@huawei.com<mailto: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<mailto:nanog@lists.nanog.org><mailto:nanog@lists.nanog.org<mailto: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/5E2 2LVBXJI4WQUE6CQUOCJ7GJB4XQ5ZL/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q7R J7HFDGPW3D45PJGWSX5GJ5H3BLSV3/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZVG RMCGRF4OZN2UKUAYITCSMG6SXYPTL/
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UYFO4NJY... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EGMXOLSP...
On Thu, Sep 11, 2025 at 10:17 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords? A password with 80bits randomness or entropy (An ~11-character
See; The simple policy of: Routing protocol keys are to be created using "pwgen 85" or at least "pwgen 38". Never create a key by hand. This rule preferably applies to all `passwords' sent over the network or keys which secure a network protocol, even if encrypted transport is used, and even if hashed. properly generated random password) contains 2^80 = 1208925819614629174706176 possibilities. If you can make 1 Trillion guesses per second, then it takes on average 19167 years to crack. That is the expectation if the hash is secure. You divide the number of possibilities by (two times the number of guesses per second)*86400*365. Current hardware gets you 80 million guesses per second per GPU for about $1800 per node, So the 1 trillion guesses per second is 12,500 hardware nodes obtainable by spending approximately $22.5 million. At that rate you need approximately 10 years' worth of brute forcing before you have a >= 0.1% chance of guessing it randomly. Each additional bit doubles the figures up to approximately 128 bits. Where you are looking at a 5395141535403007094 years to crack on average. Adding bits will eventually reach the problem that your hashing algorithm only maps inputs to 256 bits of output, so the adversary could guess a different password from yours which happens to hash to the same value as the correct one.
Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords? -- -JA
If it is so easy to enforce long enough and random enough passwords, Then why did IT people move to hashes with much lower speed? Take, for example, 16 really random letters (on keyboard), then the time to check all MD5s would go to 9.2B years (for the same 8 cards "NVIDIA GeForce RTX 5090"). Even if the attacker gets access to 100k of "NVIDIA GeForce RTX 5090", it is still 0.72M years. 16 random letters are definitely enough for the purpose. Ed/ -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Friday, September 12, 2025 18:17 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jay Acuna <mysidia@gmail.com> Subject: Re: MD5 is too fast On Thu, Sep 11, 2025 at 10:17 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
See; The simple policy of: Routing protocol keys are to be created using "pwgen 85" or at least "pwgen 38". Never create a key by hand. This rule preferably applies to all `passwords' sent over the network or keys which secure a network protocol, even if encrypted transport is used, and even if hashed.
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords? A password with 80bits randomness or entropy (An ~11-character properly generated random password) contains 2^80 = 1208925819614629174706176 possibilities.
If you can make 1 Trillion guesses per second, then it takes on average 19167 years to crack. That is the expectation if the hash is secure. You divide the number of possibilities by (two times the number of guesses per second)*86400*365. Current hardware gets you 80 million guesses per second per GPU for about $1800 per node, So the 1 trillion guesses per second is 12,500 hardware nodes obtainable by spending approximately $22.5 million. At that rate you need approximately 10 years' worth of brute forcing before you have a >= 0.1% chance of guessing it randomly. Each additional bit doubles the figures up to approximately 128 bits. Where you are looking at a 5395141535403007094 years to crack on average. Adding bits will eventually reach the problem that your hashing algorithm only maps inputs to 256 bits of output, so the adversary could guess a different password from yours which happens to hash to the same value as the correct one.
Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords? -- -JA
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJVO2FJ...
Because people don’t choose random passwords. They choose rememberable passwords. If everyone was using a password manager there wouldn’t be such an issue as they do produce random password strings. Mark -- Mark Andrews
El 15 sept 2025, a las 8:07, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> escribió:
If it is so easy to enforce long enough and random enough passwords, Then why did IT people move to hashes with much lower speed?
Take, for example, 16 really random letters (on keyboard), then the time to check all MD5s would go to 9.2B years (for the same 8 cards "NVIDIA GeForce RTX 5090"). Even if the attacker gets access to 100k of "NVIDIA GeForce RTX 5090", it is still 0.72M years. 16 random letters are definitely enough for the purpose. Ed/ -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Friday, September 12, 2025 18:17 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jay Acuna <mysidia@gmail.com> Subject: Re: MD5 is too fast
On Thu, Sep 11, 2025 at 10:17 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
See; The simple policy of: Routing protocol keys are to be created using "pwgen 85" or at least "pwgen 38". Never create a key by hand. This rule preferably applies to all `passwords' sent over the network or keys which secure a network protocol, even if encrypted transport is used, and even if hashed.
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords? A password with 80bits randomness or entropy (An ~11-character properly generated random password) contains 2^80 = 1208925819614629174706176 possibilities.
If you can make 1 Trillion guesses per second, then it takes on average 19167 years to crack. That is the expectation if the hash is secure. You divide the number of possibilities by (two times the number of guesses per second)*86400*365. Current hardware gets you 80 million guesses per second per GPU for about $1800 per node, So the 1 trillion guesses per second is 12,500 hardware nodes obtainable by spending approximately $22.5 million.
At that rate you need approximately 10 years' worth of brute forcing before you have a >= 0.1% chance of guessing it randomly.
Each additional bit doubles the figures up to approximately 128 bits. Where you are looking at a 5395141535403007094 years to crack on average. Adding bits will eventually reach the problem that your hashing algorithm only maps inputs to 256 bits of output, so the adversary could guess a different password from yours which happens to hash to the same value as the correct one.
Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords? -- -JA
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJVO2FJ... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FRWYU5IW...
Because you don't understand that different applications are different. If sugar is bad for you, why is it legal to sell fruit? On 15 September 2025 08:06:47 CEST, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
If it is so easy to enforce long enough and random enough passwords, Then why did IT people move to hashes with much lower speed?
Take, for example, 16 really random letters (on keyboard), then the time to check all MD5s would go to 9.2B years (for the same 8 cards "NVIDIA GeForce RTX 5090"). Even if the attacker gets access to 100k of "NVIDIA GeForce RTX 5090", it is still 0.72M years. 16 random letters are definitely enough for the purpose. Ed/ -----Original Message----- From: Jay Acuna via NANOG <nanog@lists.nanog.org> Sent: Friday, September 12, 2025 18:17 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jay Acuna <mysidia@gmail.com> Subject: Re: MD5 is too fast
On Thu, Sep 11, 2025 at 10:17 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
See; The simple policy of: Routing protocol keys are to be created using "pwgen 85" or at least "pwgen 38". Never create a key by hand. This rule preferably applies to all `passwords' sent over the network or keys which secure a network protocol, even if encrypted transport is used, and even if hashed.
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords? A password with 80bits randomness or entropy (An ~11-character properly generated random password) contains 2^80 = 1208925819614629174706176 possibilities.
If you can make 1 Trillion guesses per second, then it takes on average 19167 years to crack. That is the expectation if the hash is secure. You divide the number of possibilities by (two times the number of guesses per second)*86400*365. Current hardware gets you 80 million guesses per second per GPU for about $1800 per node, So the 1 trillion guesses per second is 12,500 hardware nodes obtainable by spending approximately $22.5 million.
At that rate you need approximately 10 years' worth of brute forcing before you have a >= 0.1% chance of guessing it randomly.
Each additional bit doubles the figures up to approximately 128 bits. Where you are looking at a 5395141535403007094 years to crack on average. Adding bits will eventually reach the problem that your hashing algorithm only maps inputs to 256 bits of output, so the adversary could guess a different password from yours which happens to hash to the same value as the correct one.
Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords? -- -JA
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJVO2FJ... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FRWYU5IW...
In cryptography, hash algorithms are really meant to prove consistency/equality between a known value, and an obfuscated value. The hash functions are designed to avoid collisions, and aren't made to be computationally difficult. They just happen to be slow, other hash use cases insist on speed. Hash collisions are rare enough that using them for passwords is secure enough in 99.99% of cases. Considering that most BGP servers are ACL'd, an attacker with the ability to initiate a peering session likely has too much access already. If we were handling passwords the "cryptographically correct" way, we'd use a key derivation function designed to be computationally difficult. PBKDF1/2 have iteration time parameters that specifically address brute force concerns. So anyway, we use password hashes because they accomplish the goal, not because they were designed for the task. On Monday, September 15th, 2025 at 12:07 AM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote:
If it is so easy to enforce long enough and random enough passwords, Then why did IT people move to hashes with much lower speed?
Take, for example, 16 really random letters (on keyboard), then the time to check all MD5s would go to 9.2B years (for the same 8 cards "NVIDIA GeForce RTX 5090"). Even if the attacker gets access to 100k of "NVIDIA GeForce RTX 5090", it is still 0.72M years. 16 random letters are definitely enough for the purpose. Ed/ -----Original Message----- From: Jay Acuna via NANOG nanog@lists.nanog.org
Sent: Friday, September 12, 2025 18:17 To: North American Network Operators Group nanog@lists.nanog.org
Cc: Jay Acuna mysidia@gmail.com
Subject: Re: MD5 is too fast
On Thu, Sep 11, 2025 at 10:17 AM nanog--- via NANOG nanog@lists.nanog.org wrote:
See; The simple policy of: Routing protocol keys are to be created using "pwgen 85" or at least "pwgen 38". Never create a key by hand. This rule preferably applies to all `passwords' sent over the network or keys which secure a network protocol, even if encrypted transport is used, and even if hashed.
Have you calculated how long it should take to test all 80-bit passwords? 200-bit passwords? 2000-bit passwords?
A password with 80bits randomness or entropy (An ~11-character properly generated random password) contains 2^80 = 1208925819614629174706176 possibilities.
If you can make 1 Trillion guesses per second, then it takes on average 19167 years to crack. That is the expectation if the hash is secure. You divide the number of possibilities by (two times the number of guesses per second)86400365. Current hardware gets you 80 million guesses per second per GPU for about $1800 per node, So the 1 trillion guesses per second is 12,500 hardware nodes obtainable by spending approximately $22.5 million.
At that rate you need approximately 10 years' worth of brute forcing before you have a >= 0.1% chance of guessing it randomly.
Each additional bit doubles the figures up to approximately 128 bits. Where you are looking at a 5395141535403007094 years to crack on average. Adding bits will eventually reach the problem that your hashing algorithm only maps inputs to 256 bits of output, so the adversary could guess a different password from yours which happens to hash to the same value as the correct one.
Suppose that a good server can try about a billion passwords per second. How long do you think it takes to try all the passwords?
-- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BNJVO2FJ... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FRWYU5IW...
participants (17)
-
brent saner -
Chris Adams -
Chris Woodfield -
Dan Collins -
Jay Acuna -
Jeffrey Haas -
Mark Andrews -
Matthew Petach -
nanog＠immibis.com -
Nicholas Warren -
Owen DeLong -
Randy Bush -
Riley O -
Saku Ytti -
Thomas Bellman -
Tom Beecher -
Vasilenko Eduard