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