Well, that's even more complicated. When we talk about MD5 hash collision in the context of passwords the problem is still complex but at the same time way more complex when considered in the context of SSH keys. See for password collision, you merely need to find _any_ string that would cause an MD5 collision and can use that string as a password - however it does not need to be the correct password, it just needs to hash to the same thing. When we talk about SSH, complexity explodes, because you need to find an MD5 collision that is also a "collision" with the public key (which means both have to have the same moduly). To say it simpler, you will have to calculate multiple MD5 collisions and test each one of them if it can satisfy the public key. On Sun, Aug 31, 2025 at 12:54 PM Dan Mahoney via NANOG < nanog@lists.nanog.org> wrote:
On Aug 31, 2025, at 11:16, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
There is currently no known way to generate a private key that would match your private key hash, faster than brute force, and MD5 still provides adequate protection against brute-force attacks.
While nobody should be designing new protocols using MD5 just because there is no reason to use a hash algorithm that has *any* known weaknesses, its known weaknesses are not relevant to this application.
A method is known to generate two pieces of data with the same MD5 hash. This isn't the same thing as saying that a method is known to generate a piece of data with any given MD5 hash, or the same MD5 hash as another piece of data.
And that’s why this isn’t a CVE with a CVSS score. It’s just an indication of someone cutting corners in a way I’ve never seen before, that makes me wonder what other choices were made. I say that much.
-Dan _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G2NJ5JEF...