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/4LFVVQ7VGFM76EPKKFRSEAAXHKBGCREV/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/BNJWFADODFXFOURBOKXOAW2FQW2R5L5W/
