RE: MD5 is insecure

[Gary Sparkes via NANOG <nanog () lists nanog org>]

<snip>

> The bedrock principle of public key cryptography is that it is impossible to re-create a private key while only having 
> the public key. This is not "mathematically hard" ; it is currently considered mathematically IMPOSSIBLE. And until 
> such a time as a quantum computer can do it, it remains impossible.

One issue here - It's possible, but computationally expensive. Exponentially more so as key size increases. 

RSA-768 was successfully factored / private key derived from public key in 2009. The highest successful one before RSA 
shut down the RSA factoring challenge. 

It's a matter of time/computer resources, not outright impossible. That was almost 16 years ago. 

https://eprint.iacr.org/2010/006 & 
https://arstechnica.com/information-technology/2010/01/768-bit-rsa-cracked-1024-bit-safe-for-now/

Whereas time estimates scale up exponentially as key length increases, with classical computers it is a "solved" 
problem for this algorithm, but a computationally expensive one. 

1024 should be feasible these days in a "reasonable" timeframe - the 2009 RSA-768 took approximately 2 years months of 
real-time processing across a sizable cluster (80 processors). We can obviously scale much further now.

4096 is still in the realm of geological or universe-scale timeframes for classical computing, however. 

===========




On Thu, Sep 4, 2025 at 12:16 PM Dan Mahoney <danm () prime gushi org> wrote:

> > On Sep 4, 2025, at 05:21, Tom Beecher <beecher () beecher cc> wrote:
> >
> > Dan-
> >
> > The main concern I have with your post, and the reason I have been 
> > so
> vocal in these messages , centers around the following :
> > Or you might consider just going back to using inline passwords and
> consider Cisco’s ssh implementation a failure at launch — at least the 
> “secret” hashing algorithms are salted, but on older kit, it’s also 
> still md5.
> > It's absolutely fair to criticize their implementation in its 
> > current
> form. I could see it making sense 20 years ago, but they've had time 
> to iterate and improve on it, and should have.
> > However, Cisco's implementation is not vulnerable to any currently 
> > known
> exploits, and no theoretical attack vectors don't seem to apply either.
> > The fact that you make a recommendation for readers to *stop using
> public key SSH auth* because of that is , respectfully, absolutely 
> irresponsible. Someone, somewhere is going to read this, and follow 
> this advice, making their device LESS secure, and for no good reason.  
> We don't tell people that current cryptography might eventually 
> someday be vulnerable to quantum computers , so stop using cryptography completely.
> You are doing that here, by saying "This might be exploitable some 
> day, so don't use it."  Everything MIGHT be exploitable some day, 
> that's how it goes.
>
> Tom,
>
> You see those things on either sides of the words “stop using public 
> key SSH auth” ?  Those are called quotation marks, and they mean, in 
> this context, that you are directly citing my words, to the larger group.
>
> Except that those words, in that order, appear nowhere in my article, 
> which hasn’t changed at all, except for one typo which I’ve since 
> corrected.
>
> I make no such recommendation.  My usage of the word “you might” is 
> not a recommendation, it’s a statement that people may do their own 
> research and carefully consider how they put an older device online, 
> if at all.  Where you’ve cited me bashing md5, I am referring to its 
> crypt() implementation, also used in Cisco type 5 secrets, matching my 
> recommendations with that of the NSA.  If anything, I’ll happily 
> suggest that the best answer for an EOL or near-EOL devices is “just use a serial cable”.
>
> But back to your quote.
>
> I believe that you’re seeing words that literally aren’t on the page, 
> and are citing them to a public mailing list, claiming they’re mine.
>
> This is not ok.
>
> -Dan
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FRQXA3TFDLTHZ2T7I7T2B2SMA6TLMJDG/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/NCPG47PSBQFIJGGD3JZKLKTRSB4EGI4K/