shouldn't cvc/plain-ecdsa encode to group size?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

shouldn't cvc/plain-ecdsa encode to group size?

dave_thompson_2
(For Java) the asymmetric.ec.SignatureSpi implementation for
{varioushashes}withCVC-ECDSA, aliased as PLAIN-ECDSA, use
PlainDSAEncoder which concatenates r and s each expressed as unsigned
(bigendian) both with the same size which is the larger of the
two. If both r and s are sufficiently smaller than the group order,
that chosen size is smaller than the size of the group order. On
curves like P-256 and P-384, whose order is very close to 256 or 384
bits, having r and s both that small will be rare, but for P-521 aka
secp521r1 it happens for about 25% of signatures.

I think this is wrong, or at least unconventional.

https://www.bouncycastle.org/specifications.html (found by searching
but not linked anywhere I could find?) doesn't list these signature
schemes at all, much less specify the encoding for either the usual
ASN.1 (X9.62/SEC1) versions or the 'plain' versions. The release notes
section for 1.51 calls it 'BSI plain ECDSA'. Guessing that means BSI
TR-03111, that says (5.2.1) to concatenate "R = I2OS(r; l) and S =
I2OS(s; l) with l = ceil(log256 n)" where 'l' the second argument to
I2OS is the required length, and 'n' is the group order, i.e. the
order of the basepoint on the curve. (Since P-521 was chosen with
cofactor 1, the group/point order is the same as the curve order, but
that is not true in general. For P-521 ceil(log256 n) is 66.)

I believe P1363 says the same, but don't have money to check. XMLDSIG
definitely does, at https://tools.ietf.org/html/rfc6931#section-2.3.6 
The output of the ECDSA algorithm consists of a pair of integers
 usually referred by the pair (r, s).  The signature value consists of
 the base64 encoding of the concatenation of two octet streams that
 respectively result from the octet-encoding of the values r and s in
 that order.  Conversion from integer to octet stream must be done
 according to the I2OSP operation defined in the [RFC3447]
 specification with the l parameter equal to the size of the base
 point order of the curve in bytes (e.g., 32 for the P-256 curve and
 66 for the P-521 curve [FIPS186-3]).

(186-3 is a reference for the curves, but not the encoding.)

The previous version https://tools.ietf.org/html/rfc4050#section-3.3
referenced P1363 (2000) which I take as fairly strong confirmation
that P1363 is the same, since 6931 shouldn't have made an incompatible
change without at least warning about it.

Cheers. - [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: shouldn't cvc/plain-ecdsa encode to group size?

David Hook-3

This is correct. I've fixed the encoder accordingly.

Should appear on github soon and in the next beta.

Thanks for letting us know.

Regards,

David

On 04/09/18 11:21, [hidden email] wrote:

> (For Java) the asymmetric.ec.SignatureSpi implementation for
> {varioushashes}withCVC-ECDSA, aliased as PLAIN-ECDSA, use
> PlainDSAEncoder which concatenates r and s each expressed as unsigned
> (bigendian) both with the same size which is the larger of the
> two. If both r and s are sufficiently smaller than the group order,
> that chosen size is smaller than the size of the group order. On
> curves like P-256 and P-384, whose order is very close to 256 or 384
> bits, having r and s both that small will be rare, but for P-521 aka
> secp521r1 it happens for about 25% of signatures.
>
> I think this is wrong, or at least unconventional.
>
> https://www.bouncycastle.org/specifications.html (found by searching
> but not linked anywhere I could find?) doesn't list these signature
> schemes at all, much less specify the encoding for either the usual
> ASN.1 (X9.62/SEC1) versions or the 'plain' versions. The release notes
> section for 1.51 calls it 'BSI plain ECDSA'. Guessing that means BSI
> TR-03111, that says (5.2.1) to concatenate "R = I2OS(r; l) and S =
> I2OS(s; l) with l = ceil(log256 n)" where 'l' the second argument to
> I2OS is the required length, and 'n' is the group order, i.e. the
> order of the basepoint on the curve. (Since P-521 was chosen with
> cofactor 1, the group/point order is the same as the curve order, but
> that is not true in general. For P-521 ceil(log256 n) is 66.)
>
> I believe P1363 says the same, but don't have money to check. XMLDSIG
> definitely does, at https://tools.ietf.org/html/rfc6931#section-2.3.6 
> The output of the ECDSA algorithm consists of a pair of integers
>  usually referred by the pair (r, s).  The signature value consists of
>  the base64 encoding of the concatenation of two octet streams that
>  respectively result from the octet-encoding of the values r and s in
>  that order.  Conversion from integer to octet stream must be done
>  according to the I2OSP operation defined in the [RFC3447]
>  specification with the l parameter equal to the size of the base
>  point order of the curve in bytes (e.g., 32 for the P-256 curve and
>  66 for the P-521 curve [FIPS186-3]).
>
> (186-3 is a reference for the curves, but not the encoding.)
>
> The previous version https://tools.ietf.org/html/rfc4050#section-3.3
> referenced P1363 (2000) which I take as fairly strong confirmation
> that P1363 is the same, since 6931 shouldn't have made an incompatible
> change without at least warning about it.
>
> Cheers. - [hidden email]
>
>