Brent- Yes, you are correct about what is transmitted over the wire. Thank you. That being said, I believe it's still a distinction without a difference.
The only information stored on the router is the MD5 hash *of the base64 encoded public key*. Therefore when someone attempts to authenticate, the router *must* convert the presented mpint to base64, then take the md5sum of the result and compare to the config. - If x,y are unique, base64(x) can never equal base64(y) - Therefore even a single bit change in the mpint encoded data generates a different base64 version, which will produce a different MD5. Meaning we're back to a preimage situation. I think I see where you were going with essentially a buffer overflow, but the fact that the router must do this mpint to base64 conversion negates any possibly of that happening. On Tue, Sep 2, 2025 at 7:52 PM brent saner via NANOG <[email protected]> wrote: > On Tue, Sep 2, 2025 at 1:33 PM Tom Beecher <[email protected]> wrote: > > > > > Alice creates keypair *KP2*, with public key *K2*. Alice then pads junk > >> to *K2*'s *n* until she reaches collision in the wire-packed form with > >> *C,* creating *Blob1*. Let's say Alice had to add 512 bytes to reach > >> collision with *C*. > >> > > > > The key blob is *encoded* , not hashed. base64(x) can never equal > > base64(y), and therefore cannot collide. > > > > No, Tom; from the described problem in the other thread, the problem is the > key is *hashed* *in IOS' implementation*. It's MD5'd, and that MD5 checksum > is compared against an auth list of admin-specified key checksums. If it > matches, it then accepts *and uses* the *provided* pubkey. > (OpenSSH, for instance, properly relies on *local storage* for public key > authentication=>crypto rather than comparing checksums and using a > session-provided key.) > > That's what the entire hootenanny is about. > > It's also not sent base64-encoded over the wire. At all. It's sent *as > octets* representing the public exponent *e* and (roughly) n/2-bits-long > *n* > value (a product of *p/q*). > (Assuming you're using RSA. ED25519 it's just the public half of the > private keys.) > https://datatracker.ietf.org/doc/html/rfc8332#section-3 > https://datatracker.ietf.org/doc/html/rfc8332#section-3.2 > > Defined as: > > > string public key blob: > string "ssh-rsa" > mpint e > mpint n > > > Note what an mpint is (per terminology > <https://datatracker.ietf.org/doc/html/rfc8332#section-1.2>): > > mpint > > > Represents multiple precision integers in two's complement format, > stored as a string, 8 bits per byte, MSB first. Negative numbers > have the value 1 as the most significant bit of the first byte of > the data partition. If the most significant bit would be set for > a positive number, the number MUST be preceded by a zero byte. > Unnecessary leading bytes with the value 0 or 255 MUST NOT be > included. The value zero MUST be stored as a string with zero > bytes of data. > > > By convention, a number that is used in modular computations in > Z_n SHOULD be represented in the range 0 <= x < n. > > Examples: > > > value (hex) representation (hex) > ----------- -------------------- > 0 00 00 00 00 > 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 > 80 00 00 00 02 00 80 > -1234 00 00 00 02 ed cc > -deadbeef 00 00 00 05 ff 21 52 41 11 > > > - https://datatracker.ietf.org/doc/html/rfc4251#section-5 > > What you may be confused about is the public key's storage *on-disk*. > > Your ~/.ssh/id_rsa.pub might look like this: > > *ssh-rsa > > AAAAB3NzaC1yc2EAAAADAQABAAACAQDx92RsPGT6BnKzVFxaYPKR1hJuUMS79UHtz6WzF1dqeNjcyTAPCQMxtNjEKGbfX6x+JdCPmumyjBX7QHE4ywDxx6gIXhjBThNlvc00ccM0f3FT+DRc6MqdsQeB8lvgbiWBETDD7T+oy20BmQ7xfn5sFXuIwxX3BU3C5OK7n7J7sBf47SLndbvXtT1pkPryV5sTDoZ+Xc3YiIUzum2vsR+8TehXOFNSaOWwEoICiXa7Ob07yxLMzE7V4CofLOM0tAj1NHNR134mUZecGZXqd3beH0c1x5eYByRLobAz3NycUigqoSSdh6g41NcaZ7Mb47V4KG7SgV7zG0RvKRN+oGQMuf9MLfiOJAYi2J2Zvtw+40xtRY8hmVsXTJaaio6wG77MdGSU7oCgcF50I1PPUjlasH0LmNoi+qC0/74gQ3GEMe+fEfAJAJspwtk2FMQX0Tniq0MjZFWVzFqx80dJhPIHnenwVJGZHOJcd9zn3NxXioCQUuEiZne6R4EPjPfJ16EIJQPZCHhxaMGmrdWnV+C1TW3fI2LukFBLPj8ejHNwTEvmInBGc8K95zLiCYZZwfJXTZ5bDVyLwbv94451dHfix8f9Y5bKvwZvJHWSlhZ6Tdyjh5OPfqvH9k4hO1qxIE032mEhzIT8JbPOZDJEOwP04R8Xjn2izTIEJgW4Y2L2jQ== > myuser@myhost* > > *That is not what is sent over the wire.* > What is *actually* sent over the wire to the server is *awk '{print $2}' > ~/.ssh/id_rsa.pub | base64 -d | xxd -ps -c 0* > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/NTDVVUZOEIUGCVX4HREUX63NZRQYJ2D7/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/BOCXXPOKDPFPEG2QTYWTJRRW6CT3ZWTA/
