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 valuesp256_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
According to RFD 5656, an
ecdsa_signature_blobis a pair ofmpintvalues(r, s).The encoding for
mpintis specified in RFC 4251. Here's a notable requirement:This means that it's possible to see "short"
mpintvalues, e.g. this is a validecdsa_signature_blobfor thep256curve (which normally has 32-byte coordinates):ssh_key::Signature::decodedoes not currently handle shortmpintvalues, returningencoding::Error::Length.I haven't managed to generate such signatures when using
ssh_key::PrivateKey::sign(not sure why!), but they can be generated usingssh-agent, e.g. when using a Yubikey to sign things.I have an example program at
mkeeter/ssh-agent-testwhich repeatedly signs random blobs usingssh-agent. It fails about 0.7% percent of the time, which is almost exactly the probability that at least one of thempintvalues 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_sizechecks that thempintbe exactly the curve length; it should also accept shorter valuesp256_signature_from_openssh_bytes(and equivalent) callsp256::FieldBytes::try_from(..)onMpint::positive_bytes, which fails if theMpintis short; it should instead pad with leading zeros