ECDSA signatures falsely reject points with leading zeros

[mkeeter]

According to RFD 5656, an ecdsa_signature_blob is a pair of mpint values (r, s).

The encoding for mpint is specified in RFC 4251. Here's a notable requirement:

Unnecessary leading bytes with the value 0 or 255 MUST NOT be included.

This means that it's possible to see "short" mpint values, e.g. this is a valid ecdsa_signature_blob for the p256 curve (which normally has 32-byte coordinates):

0000002056A3EF43B4008E74169481F44C0BAB56EE651EDFDA4847DB37F992517A603544
0000001F01B02CDFB08568C910D7E7BB8942637D51ED48440E4E1F149CC483027F3D3F

ssh_key::Signature::decode does not currently handle short mpint values, returning encoding::Error::Length.

---

I haven't managed to generate such signatures when using ssh_key::PrivateKey::sign (not sure why!), but they can be generated using ssh-agent, e.g. when using a Yubikey to sign things.

I have an example program at mkeeter/ssh-agent-test which repeatedly signs random blobs using ssh-agent. It fails about 0.7% percent of the time, which is almost exactly the probability that at least one of the mpint values has a leading 0 byte (1 - (255/256)**2 = 0.0077).

Looking through the code, there are two places where things go wrong:

• ecdsa_sig_size checks that the mpint be exactly the curve length; it should also accept shorter values
• p256_signature_from_openssh_bytes (and equivalent) calls p256::FieldBytes::try_from(..) on Mpint::positive_bytes, which fails if the Mpint is short; it should instead pad with leading zeros

[mkeeter]

Fixed by #291