[seems to have accidentally moved off list] Passwords for TCP-MD5 and TCP-AO do not have to be remembered, and they are configured by experts who know they should be random. On 12 September 2025 13:31:03 CEST, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:

* You will see that the number of random letters is very very important. For sure, very important, every letter is 75x. But nobody would be capable of remembering even 8 random letters. People would continue to choose not very strong passwords. It is possible to fight with people or help them with technology that would not need such strong passwords. The IT world has chosen the latter. Many smart people have participated in this – I do not believe that they have forgotten to account for something.

And do not forget that for the process of brute force, the password “7Jon%Brain&Letter” (17 letters) is weaker than “n4H*h!s$” (8 letters). I mean: there is a way to downgrade too, even for long passwords.

Only full automation when passwords are not appointed manually permits raising the bar of password complexity. Eduard From: nanog@immibis.com <nanog@immibis.com> Sent: Friday, September 12, 2025 13:33 To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Subject: RE: MD5 is too fast

You did 10 random letters with 8 5090s and you calculated 19 days.

Have you calculated 12 random letters? 16 random letters? 24 random letters? 40 random letters?

You will see that the number of random letters is very very important.

On 12 September 2025 09:53:36 CEST, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

I hope I have answered in the thread. If not, ping me. Ed/ -----Original Message----- From: nanog--- via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Sent: Thursday, September 11, 2025 18:17 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 too fast

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<mailto: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<mailto:nanog@lists.nanog.org>> Sent: Thursday, September 11, 2025 12:03 To: North American Network Operators Group <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> Cc: Thomas Bellman <bellman@nsc.liu.se<mailto: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/SZV 2BS2WTBZIF5TOK43UQ4GYGNSB4QVX/

________________________________

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/S3YL6WSD...