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 <[email protected]> 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 <[email protected]> >Sent: Wednesday, September 10, 2025 10:22 >To: Vasilenko Eduard <[email protected]> >Cc: North American Network Operators Group <[email protected]> >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 <[email protected]> >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 <[email protected]> >> Sent: Wednesday, September 10, 2025 09:39 >> To: North American Network Operators Group <[email protected]> >> Cc: Vasilenko Eduard <[email protected]> >> Subject: Re: MD5 is slow >> >> On Wed, 10 Sept 2025 at 09:12, Vasilenko Eduard via NANOG >> <[email protected]> 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/[email protected]/message/BAR3QJ4J6QQTQIFREGBPCS2KPNF2MKS2/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/HM2UK4NU62TX6WOX3ECURXVWQ2NN7USF/
