Re: How to handle incorrectly-encoded public keys

> I recently ran into an SSH implementation that encodes its RSA public
> keys incorrectly, specifically:

> 0000: 00 00 01 1A                                       // string server key
>                   00 00 00 0C 72 73 61 2D 73 68 61 32   // string "rsa-sha2-256"
> 0016: 2D 32 35 36
>                   00 00 00 01 03                        // e = 3 (!!!)
>                                  00 00 01 01 00 CB 56   // n = ...
> 0032: 00 95 5B F0 BD 66 24 F5 2C 16 A2 CA 4E D8 5F 8C ..[..f$.,...N._.

> RFC 8332 says:

>    Since RSA keys are not dependent on the choice of hash function, the
>    new public key algorithms reuse the "ssh-rsa" public key format as
>    defined in [RFC4253]:
> 
>    string    "ssh-rsa"
>    mpint     e
>    mpint     n

Your adding (!!!) looks as though you're calling out the value of e as
the error.  I don't see that as erroneous; it is somewhat foolhardy in
view of the low encryption exponent attack, but not incorrect.

The only incorrect thing I see is rsa-sha2-256 instead of ssh-rsa as
the string.

> What are people doing when they see this incorrect encoding?

I'd have to try it to be sure, and it would be a bit difficult to rig
an instance of moussh to present such a key.  I would expect my
implementation would reject the key because it none of the key format
modules accept it (the ssh-rsa one should refuse to accept it because
it doesn't recognize the string).  But, my implementation of rsa-sha2-*
support is new enough there may be surprises in it.

Did you see this as a host key, or as a key offered for publickey
authentication, or what?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B