Re: [PATCH] crypto: ecdsa: Fix the public key format description

[Jarkko Sakkinen]

On Tue May 28, 2024 at 3:37 PM EEST, Stefan Berger wrote:
>
>
> On 5/27/24 18:59, Jarkko Sakkinen wrote:
> > On Tue May 28, 2024 at 1:49 AM EEST, Jarkko Sakkinen wrote:
> >> On Tue May 28, 2024 at 1:31 AM EEST, Jarkko Sakkinen wrote:
> >>>>          ret = crypto_akcipher_set_pub_key(tfm, data, 3 * x_size + 1);
> >>
> >> Noticed this mistake i.e. fixed it with "2 * x_size + 1"
> >>
> >> This is results earlier failure:
> >>
> >> ecdsa: (tpm2_key_ecdsa_query+0x10d/0x170 <- ecdsa_set_pub_key) arg1=0xffffffea
> >>
> >> Totally lost with the expected input format after trying out various
> >> options.
> > 
> > OK got it working with:
> > 
> >          ptr = &data[0];
> >          *ptr++ = 0x04; /* uncompressed */
> >          memcpy(&ptr[0], &x[2], x_size);
> >          memcpy(&ptr[x_size], &x[2 + x_size + 2], x_size);
> >          ret = crypto_akcipher_set_pub_key(tfm, data, 2 * x_size + 1);
> >          crypto_free_akcipher(tfm);
> > 
> > Had still a few "off-bys".
> > 
> > Makes me wonder why this is not in ASN.1.
> > E.g. TPM2 stuff and for instance RSA code takes ASN.1.
> > 
> > This all and the required prefix byte really should be explained in
> > the documentation of this function. I.e. follows the RFC in the sense
> > that number is big-endian and has the prefix byte, but it does not
> > follow it in the sense that x and y are not in input octect strings.
> > 
> > Why is that? Does not feel right intuitively.
>
> You found the appropriate documentation -- thanks.
> The old function documentation stated that it takes 'raw uncompressed 
> key data from an x509 certificate'. So, one should take the data from 
> the x509 certificate starting with 0x04 as shown here.
>
>          Subject Public Key Info:
>              Public Key Algorithm: id-ecPublicKey
>                  Public-Key: (256 bit)
>                  pub:
>                      04:c0:55:b4:68:7a:80:bc:0e:ba:b3:66:40:5f:07:
>                      aa:27:d4:da:b4:79:2e:4d:a4:f4:f4:33:b1:22:6a:
>                      6c:e9:8c:30:8d:6c:df:ac:65:f0:93:d9:7a:70:7a:
>                      05:dc:7a:7d:b3:91:18:22:9a:5c:86:9a:87:72:3b:
>                      32:1a:92:81:1d
>                  ASN1 OID: prime256v1
>                  NIST CURVE: P-256
>
>
> These are two concatenated x & y coordinates with a leading 0x4. The 
> numbers are not ints in ASN.1 format but 'plain' integers.
>
> A *signature*, however, is in ASN.1:
>
>      Signature Value:
>          30:45:02:21:00:d9:d7:64:ba:5d:03:07:ee:20:a0:12:16:46:
>          31:e6:8e:66:0c:17:0d:74:07:87:58:5a:13:fc:14:62:98:9a:
>          99:02:20:59:ff:29:9c:52:b9:0a:35:3c:4b:03:bb:47:0e:c8:
>          3e:2d:cb:3e:1c:d3:51:88:91:b1:40:e3:03:86:1b:2a:e8
>
> 30:45 => sequence containing 69 bytes
>    02:21: => first coordinate with 0x21 bytes
>      00:d9 => 0x21 bytes of ASN.1 integer with leading 0 to make the 
> following 0x20-byte integer a positive number (its most significant bit 
> is set).
>    02:20: => int with 0x20 bytes
>     ...

Ah, thanks for this insight! I found this out by trial and error but
good to see that it matches with the "theory". Thank you.

BR, Jarkko