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

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, [email protected] 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. - [email protected]
>
>