file Examples/ecdsa-examples/ecdsa-sig-01.json

[mcr]

This file says:

     "key":{
        "kty":"EC",
        "kid":"11",

but, page 38 of draft-ietf-cose-msg-24.txt says:

o  The 'kty' field MUST be present and it MUST be 'EC2'.

while the kty field is not part of the signature this did raise some concern that I'm verifying with the wrong group! Please confirm that this file using the NIST 'nistp256' curve? (not secp256XX?)

I'm feeding the following digest into the signature validation:
(byebug) sha256.unpack("H*")
["45e243bb7071e72a288416ccb9cfbd2932fe1926916fe85b344141ecce91e4bb"]

(byebug) sig01_pub_key
#<ECDSA::Point: nistp256, 0xbac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a09eff, 0x20138b0b706db558af8254ab7804a3a64b6d72ccf5adbedbb4a2eff045f8>

(byebug) signature
#<ECDSA::Signature:0x00000001f1df00 @s=51765963774164195565914350724151000343397507914291589008366842864028004758943, @r=106251839252054433277813174560343063247957774643926440805394321619487281072353>

I wonder if I've gotten something trivial screwed up? Order or r/s maybe.

[jimsch]

The curve to be used is controlled not by the kty field, but by the crv field. And yes this is the nistp256 curve. I can see changing the string to match the document, but JOSE uses the string 'EC' so that is what I kept for this purpose. (I have similar tests that run over JOSE as well.)

I have a different SHA256 value than what you are displaying. The string to be hashed is part of file - in "Intermediates"."ToBeSigned_Hex" - check for seeing what is different there

[mcr]

Thanks Jim. I confirmed that I am producing the same input to the SHA256 (yes, the ToBeSigned_Hex).
I realize that crv controls the curve, but that's identical. I was worried that maybe "EC" vs "EC2" might refer to some other set of families.
What is your SHA256 output?

[mcr]

Just to be sure my Ruby library wasn't doing something weird.... And I'm pretty sure this matches your ToBeSigned input.

obiwan-[~/Desktop/Downloads](2.2.1) mcr 10016 %hexdump -C ~/net/dooku/corp/projects/pandora/chariwt/n1.bin 
00000000  84 6a 53 69 67 6e 61 74  75 72 65 31 45 a2 01 26  |.jSignature1E..&|
00000010  03 00 f6 54 54 68 69 73  20 69 73 20 74 68 65 20  |...TThis is the |
00000020  63 6f 6e 74 65 6e 74 2e                           |content.|
00000028
obiwan-[~/Desktop/Downloads](2.2.1) mcr 10017 %sha256sum ~/net/dooku/corp/projects/pandora/chariwt/n1.bin
45e243bb7071e72a288416ccb9cfbd2932fe1926916fe85b344141ecce91e4bb  /home/mcr/net/dooku/corp/projects/pandora/chariwt/n1.bin

Maybe I'm ignorant of some aspect of how the SHA256 digest should be calculated? It's not in HMAC formulation is it?

[mcr]

I thought I'd go on to making my own signatures, and I'd use your private keys. So just for initial fun, I used the d value presented to derive the public key points again. That should be easy. The result was a surprise. The X values match, but the Y values did not!

(byebug) public_key.x
84479481090508879236361810314595438639920637850206250382769291656310074416895
(byebug) sig01_pub_key.x
84479481090508879236361810314595438639920637850206250382769291656310074416895
(byebug) public_key.y
14508547282523033594077281899984253063221771617900828323772342424228169781630
(byebug) sig01_pub_key.y
221382765198319077083920120796396551052321440967416757858684904626210296
~~~~~~~~

Here is the ecdsa-sig-02 example:

~~~~~~~~
     Failure/Error: expect(public_key.y).to eq(sig02_pub_key.y)

       expected: 91868384890031460649754685707864258145190135110235385393681494258596710557893535765907562207370466357656300190667
            got: 23518306531848053926337199541213250085168674588220258660782462530200758625213253354049701321900095587770936212451116
~~~~~~~~

so something is systematically wrong with this ecdsa library perhaps.   Here is the public key format that I generated, in case it helps. I am taking this point to the ecdsa github issue hub.

~~~~~~~~
(byebug) public_key_string
"\x02\xBA\xC5\xB1\x1C\xAD\x8F\x99\xF9\xC7+\x05\xCFK\x9E&\xD2D\xDC\x18\x9FtR(%Z!\x9A\x86\xD6\xA0\x9E\xFF"
(byebug) public_key_string.unpack("H*")
["02bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a09eff"]
~~~~~~~~

[mcr]

https://gist.github.com/mcr/b1c9dd9cfcab249e73200d0d056ac0da .
let me add the results. I wonder if there is something that has munged the y-coordinates?

[jimsch]

byte 12 in your input is different.

You decode to
84 # array(4)
6a # text(10)
5369676e617475726531 # "Signature1"
45 # bytes(5)
a201260300 # "\xA2\x01&\x03\x00"
f6 # primitive(22)
54 # bytes(20)
546869732069732074686520636f6e74656e742e # "This is the content."

I decode to
84 # array(4)
6a # text(10)
5369676e617475726531 # "Signature1"
45 # bytes(5)
a201260300 # "\xA2\x01&\x03\x00"
40 # bytes(0)
# ""
54 # bytes(20)
546869732069732074686520636f6e74656e742e # "This is the content."

[mcr]

Thanks for checking that. My eyes couldn't see it. It's that damn empty array encoding...