Re: MD5 is insecure

[Tom Beecher via NANOG <nanog () lists nanog org>]

Dan-

I fully stand by my statements that you have :

   - Presented evidence of a poor design decision
   - Presented no evidence of a practical method of exploitation as a
   result of that design decision.
   - Provided a soft recommendation that people stop using public key SSH
   auth.


The phrasing "you might consider" is absolutely a recommendation. It is a
softer recommendation than "you must" or "you should" , but it is
absolutely verbiage making a suggestion/recommendation that someone do or
consider doing something. Even suggesting that people should "consider"
removing publickey auth based on your post is irresponsible.

This is especially true in the context of the back half of your posting ,
where you accurately call out that this isn't exploitable, then sow FUD
about about the ways it MIGHT be. For the avoidance of doubt ,between the
equals signs, quotation marks will only be used to signify a direct copy
paste from your post.

==========

After you explain your findings , you correctly start out with this :

"It’s entirely possible I’m being alarmist: I’ve spoken to a few people
knowledgeable in cryptography, and they tell me that this kind of preimage
attack is still not feasible. While MD5 is showing weaknesses against large
volumes of texts being able to be produced with the same hash (collision
attacks — for example, changing a few characters in the text of a document
the size of a novel and getting the same sum) we haven’t yet seen a
feasible ability to generate text matching a very short known hash
(especially when that hash needs to be of some very specifically-formatted
prime numbers that happen to be a valid ssh pubkey)."

Everything you said here is absolutely fair and correct. You correctly
state that people knowledgeable on the subject have said that this isn't
exploitable.

However, everything you follow this up is maybe, could be, still might be a
problem.

"But, if I’m being alarmist, let me just say two words that bring it back.
“Jia Tan”. Jia was the anonymous, generally-assumed-to-be-state-sponsored
open-source contributor who slipped an exploit into the XZ compression
utilities that would have ultimately allowed a master public-key into
OpenSSH. It was a sophisticated attack."

There is a universe of difference between someone social engineering an
exploit into a codebase , and someone finding an algorithm/method to
perform a mathematical computation that to date is considered not possible.
Bringing this up in this way is very much a coded way of saying well this
could happen, look here.

"Again, I’m not a cryptanalyst, nor do I have IOS-XE source code to look
over. I haven’t loaded this all in a debugger, or in Ghidra or whatever it
is the reverse engineers do. I’ve typed some basic commands into my
routers, and thrown some basic ssh commands against them, and I’m not
liking what I see.

At the end of the day, I’m just a simple country SysAdmin who’s seen people
upload sloppy php code to their websites for 25 years, and I don’t like the
way this makes my “gut” feel. I’ve seen things you people wouldn’t believe."

Not liking what you see is understandable and a fair thing to say. But
again this is coded language that to the reader implies there is a concern.

"Even if Cisco had put out newer releases, they hide their IOS software
behind a paywall, and their process for getting code for devices that are
not under warranty is obnoxiously complex, but most of the devices on the
secondary market are EOL or close to it, so there’s no fix coming for any
of this."

You again use fix here, implying this is MUSTFIX, when in reality it is
SHOULDFIX.

Again , after multiple paragraphs of maybe, might be, could still be a
problem, you close with :

"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.

(Note: the NSA has a reasonable document about Cisco Password .ssh/config
Algorithms)

Heck, after discovering this, I am contemplating, strongly, just using a
USB- to-serial-port concentrator with a unix box running rtty or conserver,
and disabling all network configuration on my routers, and limiting any
configuration to the console ports (but this does make using tools like
RANCID way harder).""

Again I take the position that "you might consider" is a soft
recommendation, but still a recommendation. Followed up with you are
"contemplating, strongly" about doing that yourself is just reinforcing
that.

Elsewhere in your post, you make a demonstrably false comment.

"Of course, what’s more scary here is, if you ssh to a lot of places (like,
say, public looking glasses?), you’ve also uploaded that public key to lots
of other places. Because chances are, uploading your public key is the
default behavior. Even if you keep your private key encrypted.

Imagine a darker world, where places with a modified sshd could have
stored, and hashed it. With md5.

Those places could have then generated an ssh private key, having a public
key with the same md5 hash. It would have been mathematically hard to do
so, but this is a possible offline (massively-parallel) attack. Just
sitting generating keys. They would not have to try those keys against your
router to attempt auth."

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.


===========




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/