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 <[email protected]> wrote: > On Thu, Sep 4, 2025, 20:51 Jay Acuna via NANOG <[email protected]> > wrote: > > > On Thu, Sep 4, 2025 at 7:21 AM Tom Beecher via NANOG > > <[email protected]> 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/[email protected]/message/IPJ2FPWTJAGCBVZXC2DKYDNX7BGUK5DI/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/XPHJGZBE3YGJDGQP2K2S6XX36VN5O4HZ/
