<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 <[email protected]> wrote: > > > > On Sep 4, 2025, at 05:21, Tom Beecher <[email protected]> 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/[email protected]/message/FRQXA3TFDLTHZ2T7I7T2B2SMA6TLMJDG/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/NCPG47PSBQFIJGGD3JZKLKTRSB4EGI4K/
