Re: MD5 is insecure

[Dorn Hetzel via NANOG <nanog () lists nanog org>]

One of the nicest things about RSA is that there is no secret sauce, just
the factoring problem, and anyone who finds a truly fast way to factor
composites made from *huge* primes will be off to claim their Nobel, so
we'll all hear about it :)


On Fri, Sep 5, 2025 at 11:50 AM brent saner via NANOG <nanog () lists nanog org>
wrote:

> On Thu, Sep 4, 2025, 20:51 Jay Acuna via NANOG <nanog () lists nanog org>
> wrote:
>
> > On Thu, Sep 4, 2025 at 7:21 AM Tom Beecher via NANOG
> > <nanog () lists nanog org> wrote:
> >
> > > However, Cisco's implementation is not vulnerable to any currently
> known
> > > exploits, and no theoretical attack vectors don't seem to apply either.
> >
> > You mean not vulnerable to an exploit whose details are currently
> > available to you.
> > It is highly probable that known exploits to MD5 hashing exist which
> > have much greater
> > value to the finders not sharing the details than the practically
> > nonexistent
> > renumeration you'd get publishing.
>
> This is precisely why I still avoid NIST curves where possible (favoring
> Edwards curves).
>
>
> > The MD5 hash has a history of being broken for a long period of time, and
> > no
> > longer used on modern systems requiring security, and is in a state where
> > you could reasonably presume viable preimage attack methods have been
> > worked
> > out and are available to nefarious  actors, but are also not going to
> > be disclosed
> > to the public and not going to be taken up as matters for academic
> > research.
>
> RFC 1186 (MD4) was published Oct. 1990.
> By 1991, severe weaknesses were published and several collisions found.
> By 1995, near-collisions could be generated in a flash. Later that year, a
> full revision attack had been found and published.
> In 2004, significant collision efficiencies were published (along with
> other algos in the family, including MD5).
> By 2007, complete collisions can be generated in 2 or less hash ops.
> In 2008, a 2^128 →2^102 preimage for MD4 was published.
> In 2010, a 2^128 →2^99.7 preimage for MD4 was published.
>
>
> In 1991, MD5 was designed. It was published as RFC 1321 in 1992.
> In 1993, pseudo-collisions were found.
> In 1996, the compression routine in MD5 was considered broken. It's about
> this time that recommendations to switch to SHA(-1) are made.
> 2004, MD5CRK demonstrates a working birthday attack accomplished within an
> hour on a p690 cluster.
> 2005, two x.509 certificates sharing the same hash with different public
> keys are published. (Improved collision construction methodology is
> released days after this that reduces it to a few hours on a laptop.) (A
> 2005 laptop, keep in mind.)
> 2006, collision finding can now be done within a minute on a laptop.
> 2010, a single-block (512B) MD5 collision is announced (but not published).
> 2012, the Flame malware uses a forged Microsoft code-signing certificate
> with MD5 collision against a valid one.
> 2013, colliding is down to 1/8th block (64B).
> As of today and public knowledge, collision finding is at 2^24.1 and with
> chosen-prefix, this is reduced to 2^39.
>
> 12 years is an awfully long time of silence, given MD5's much wider
> adoption (and still-current usage) over MD4.
>
> Humans often set weak passwords, or don't like using multiple passwords,
> and
> > Single sign-on solutions systemize the security hole.  With
> password-based
> > auth
> > - your password is sent in plaintext to a SSH daemon.  SSH defenses
> against
> > adversary in the middle are weaker with password-based auth.
>
> A small explicit clarification in case people are freaking out,
> password-based auth for SSH doesn't send the password in plaintext *over
> the wire*, KEX happens before auth and a shared secret key is used to
> encrypt the transport for the session before auth occurs.
>
> The *daemon*, however, does indeed receive the sent password, correct.
>
>
> > A reused password only has to be captured a single time by one rogue SSH
> > daemon
> > or one device on the network.
>
> And for an extra fun time it has a username associated with it. This is
> daunting for those that use centralized auth in their org.
>
>
> > One of the best things you can do for authentication security is to
> > eliminate passwords
> > and use a crypto-based system. Passwords for SSH should have been
> > deprecated and
> > had support for them completely removed from all hardware a long time
> ago.
> >
>
> It's a hard line, but one I can stand behind.
>
> I also cannot stress the benefit of physical-token/FIDO2 MFA as well. It's
> easier than ever with OpenSSH 8.2p/8.3p (8.3p adds verify-required).
> Though net kit may be a fair bit away from this, and from my understanding
> IOS doesn't use OpenSSH (or a fork thereof) whatsoever - they have a 100%
> in-house-developed sshd.
>
>
> > On first login when setting up a new piece of hardware --  The
> > hardware can be designed
> > to only permit a password that one time, then generate
> > and display an admin keypair to be imported into the SSH client,  then
> > require the admin of new equipment to log back in using that keypair
> > before the keypair can
> > be saved, and before it is made possible to finalize or save an
> > initial device configuration and
> > activate any services.
>
>
> This is precisely what I set up for my org's jumpboxes/bastions. I'm
> sysops, not netops, though - so I have a significantly higher amount of
> flexibility in this particular context.
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/IPJ2FPWTJAGCBVZXC2DKYDNX7BGUK5DI/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/XPHJGZBE3YGJDGQP2K2S6XX36VN5O4HZ/