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
