ECDSA signature verification include derivation of s1 and s2

[winstonDeGreef]

Section 23.7.2 defining the verification of ECDSA, step 6:

Perform the ECDSA verifying process, as specified in [RFC6090], Section 5.3, with M as the received message, signature as the received signature and using params as the EC domain parameters, and Q as the public key.

However, section 5.3 of RFC 6090 doesn't specify a way to turn a binary value into the two required integers s1 and s2. The previous section defining signing does define a way to turn the integers s1 and s2 into a binary value, so section 23.7.2 should too.

Also, as a developer It'd be nice to get an error saying that the signature has a length that means it can't possibly be in the right format for this function.

[winstonDeGreef]

Also it be nice to mention if the integers are encoded in little or big endian form. Maybe this could be done by saying r and s are bigints, which are defined to be big endia.

[Frosne]

Section 23.7.2 defining the verification of ECDSA, step 6:

Perform the ECDSA verifying process, as specified in [RFC6090], Section 5.3, with M as the received message, signature as the received signature and using params as the EC domain parameters, and Q as the public key.

However, section 5.3 of RFC 6090 doesn't specify a way to turn a binary value into the two required integers s1 and s2. The previous section defining signing does define a way to turn the integers s1 and s2 into a binary value, so section 23.7.2 should too.

Also, as a developer It'd be nice to get an error saying that the signature has a length that means it can't possibly be in the right format for this function.

Hi,
What do you think about https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf?
Section 6.4.1 for signatures/Section 6.4.2 for verification?

[winstonDeGreef]

I mean, that sure does look like a description of a cryptographic signature algorithm.

It doesn't however address my concerns about encoding, because in the sections you mentioned no encoding is specified.

What i'd like to see is something like:
6.1 verify that signature has length 64 bytes.
6.2 convert the first 32 bytes of signature to the integer r.
6.3 convert the last 32 bytes of the signature to the integer s
6.4 Perform the ECDSA verifying process, as specified in [RFC6090], Section 5.3, with M as the received message, the integer pair (r, s) as the received signature and using params as the EC domain parameters, and Q as the public key.

And then convert the bytes should probably link to a section just below convert to bytes to explain that integers should be parsed as big endian.

[davidben]

Also it be nice to mention if the integers are encoded in little or big endian form. Maybe this could be done by saying r and s are bigints, which are defined to be big endia.

Are you referring to BigInteger in the WebCrypto spec? That's a WebIDL type and your ECDSA code will typically be nowhere near WebIDL. It's also not the right fit because this encoding has r and s be fixed-width.

This encoding has many names because it tends to just be respecified everywhere. The most common, specific name I've seen is P1363, after IEEE P1363. But that document is hard to get access to. It's also used in PKCS#11, but calling it PKCS#11 is confusing because PKCS#11 usually refers to an API for crypto modules, not a format.

Just respecifying it, without resorting to anything clever seems the simplest. Possibly worth adding some non-normative that it's the same format as IEEE P1363 and PKCS#11, but not the same format as the DER encoding used by other systems, like TLS and X.509.

What do you think about https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf?
Section 6.4.1 for signatures/Section 6.4.2 for verification?

Those sections don't specify the encoding either. Indeed we are in this mess because of this failure of the underlying specs to specify things. (When NIST specified ECDSA, they should have picked an encoding.) There are now two different common encodings for ECDSA signatures because NIST didn't pick one. :-(

[winstonDeGreef]

idk, I just saw this in the spec when doing ctrl+f for endian

[winstonDeGreef]

Probably not relevant though, something like this is better:
6.2 convert the first 32 bytes of signature to the integer r.
6.3 convert the last 32 bytes of the signature to the integer s

[winstonDeGreef]

And then mention that when converting like this the bytes are in big endian order

[davidben]

Something like that, yeah, though it's not 32 but something depending on the group order. ("Let n be the smallest integer such that n * 8 is greater than the logarithm to base 2 of the order of the base point of the elliptic curve identified by params." is the phrasing used elsewhere.)

[Frosne]

Those sections don't specify the encoding either. Indeed we are in this mess because of this failure of the underlying specs to specify things. (When NIST specified ECDSA, they should have picked an encoding.) There are now two different common encodings for ECDSA signatures because NIST didn't pick one. :-(

But it references https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf. where deep inside we have
Appendix F.3. Conversion of an Integer to a Bit String, it's already something

[Frosne]

Then

Perform the ECDSA signing process, as specified in [[RFC6090](https://w3c.github.io/webcrypto/#bib-rfc6090)], Section 5.4, with M as the message, using params as the EC domain parameters, and with d as the private key.

-         Let r and s be the pair of integers resulting from performing the ECDSA signing process.

-         Let result be an empty [byte sequence](https://infra.spec.whatwg.org/#byte-sequence).

-         Let n be the smallest integer such that n * 8 is greater than the logarithm to base 2 of the order of the base point of the elliptic curve identified by params.

-         [**Convert the first n bytes of r** to a byte sequence of length n](https://w3c.github.io/webcrypto/#dfn-convert-integer-to-byte-sequence) and append it to result.

-         [**Convert the first n bytes of s** to a byte sequence of length n](https://w3c.github.io/webcrypto/#dfn-convert-integer-to-byte-sequence) and append it to result.

[davidben]

But it references https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf. where deep inside we have Appendix F.3. Conversion of an Integer to a Bit String, it's already something

Do you have a pointer to where Section 6.4.1 and Section 6.4.2 of FIPS 186-5 calls that procedure? Simply having that lying around isn't enough to define a format.

Hint, the sections you mention say:

Output: A pair of integers (r, s), each in the interval [1, n−1]

and

Input: [...] A pair of integers (r, s)

As far as FIPS 186-5 is concerned, ECDSA signatures are tuples of integers, not byte strings. That is the root of all this.

[Frosne]

Do you have a pointer to where Section 6.4.1 and Section 6.4.2 of FIPS 186-5 calls that procedure? Simply having that lying around isn't enough to define a format.

If I had it, the problem would have been solved :D

[Frosne]

Anyway, I think I would introduce a BigInteger section with a function containing a way to convert an integer to/from it, and then in the ecdsa section reference it, like

Convert the first n bytes of s* to a BigInteger following the algorithm described in (BigInteger section).

[winstonDeGreef]

I dont think that's a good idea, because bigints aren't supposed to have leading zeroes bytes, but about 1 in 256 ECDSA signatures will start with 0x00, and the encoding is fixed width.

[Frosne]

I dont think that's a good idea, because bigints aren't supposed to have leading zeroes bytes, but about 1 in 256 ECDSA signatures will start with 0x00, and the encoding is fixed width.

Make sense. Then independently from BigInteger to introduce a function to convert to/from byte sequence and describe/reference an encoding