Which means if IOS does no pubkey packet length validation, you no longer need to generate a keypair that has a pubkey that collides on MD5. You just need a blob that collides with that hash, and will *truncate* to a key you control. Which is much easier to collide.
To actually exploit this : Generating a collision isn't hard. But you'd have to generate a collision that was also valid to use in the key algorithm specified in SSH_MSG_USERAUTH_REQUEST. So now you actually need a preimage attack, and even for MD5 that's not feasible still. Even if you managed to pull that off, you STILL don't have valid private half of the keypair. And if you could do that you just broke all of modern cryptography so we have other problems. :) On Sun, Aug 31, 2025 at 5:04 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
On Sun, Aug 31, 2025, 16:39 Krassimir Tzvetanov via NANOG < nanog@lists.nanog.org> wrote:
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.
Normally, yes. But unless I read the email incorrectly, the problem is IOS just uses an MD5 of the key sent by the client and verdicts auth *based on the checksum match*. If it matches, it just uses the key the client sent.
Which means if IOS does no pubkey packet length validation, you no longer need to generate a keypair that has a pubkey that collides on MD5. You just need a blob that collides with that hash, and will *truncate* to a key you control. Which is much easier to collide.
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IUQM7XIN...