[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 
<[email protected]> 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: [email protected] <[email protected]>
>Sent: Friday, September 12, 2025 13:33
>To: Vasilenko Eduard <[email protected]>
>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 
><[email protected]<mailto:[email protected]>> wrote:
>
>I hope I have answered in the thread.
>If not, ping me.
>Ed/
>-----Original Message-----
>From: nanog--- via NANOG <[email protected]<mailto:[email protected]>>
>Sent: Thursday, September 11, 2025 18:17
>To: North American Network Operators Group 
><[email protected]<mailto:[email protected]>>
>Cc: [email protected]<mailto:[email protected]>
>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 
><[email protected]<mailto:[email protected]>> 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 
><[email protected]<mailto:[email protected]>>
>Sent: Thursday, September 11, 2025 12:03
>To: North American Network Operators Group 
><[email protected]<mailto:[email protected]>>
>Cc: Thomas Bellman <[email protected]<mailto:[email protected]>>
>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/[email protected]/message/SZV
>2BS2WTBZIF5TOK43UQ4GYGNSB4QVX/
>
>________________________________
>
>NANOG mailing list
>https://lists.nanog.org/archives/list/[email protected]/message/S3YL6WSDA3K2ZWEKYBOOQPRVAQSYYNJX/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/347WMC4UYSTOCGIQJZAC7GHZCOT7KJJX/

Reply via email to