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: [email protected] <[email protected]> Sent: Wednesday, September 10, 2025 11:04 To: Vasilenko Eduard <[email protected]>; North American Network Operators Group <[email protected]> Cc: [email protected] 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 <[email protected]> > Sent: Tuesday, September 9, 2025 22:53 > To: North American Network Operators Group <[email protected]> > Cc: [email protected] > 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 > <[email protected]> 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 <[email protected]> >> Sent: Monday, September 8, 2025 22:26 >> To: North American Network Operators Group <[email protected]> >> Cc: Saku Ytti <[email protected]>; Dan Collins <[email protected]>; >> Vasilenko Eduard <[email protected]> >> Subject: Re: MD5 is slow >> >> On Mon, Sep 8, 2025 at 3:00 AM Vasilenko Eduard via NANOG >> <[email protected]> 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/[email protected]/message/4 >> LF >> VVQ7VGFM76EPKKFRSEAAXHKBGCREV/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/BN > JWFADODFXFOURBOKXOAW2FQW2R5L5W/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/SDTWUKN6TL4Z3VVQFQYVMCTCS7W4MJXQ/
