Received-SPF: pass (google.com: domain of linux-crypto+bounces-4449-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <b5ff9003-065f-437f-bf6b-7f1ae0a0364a@linux.ibm.com>
Date: Tue, 28 May 2024 08:37:37 -0400
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] crypto: ecdsa: Fix the public key format description
To: Jarkko Sakkinen <jarkko@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
        linux-kernel@vger.kernel.org
References: <20240527202840.4818-1-jarkko@kernel.org>
 <D1KQDPOZRWCW.1763CCYF1B84X@kernel.org>
 <D1KRILI1KRQ8.2CNPU7PFES0VI@kernel.org>
 <D1KRXI87G4S0.1ROKTQENIZHT7@kernel.org>
 <D1KS7LCALKD4.1J13QGYGZ6LBW@kernel.org>
 <D1KSLKGUWGFO.21T4OBXQQ88D@kernel.org> <D1KSSWD7FA94.5705Z3J7LKZA@kernel.org>
Content-Language: en-US
From: Stefan Berger <stefanb@linux.ibm.com>
In-Reply-To: <D1KSSWD7FA94.5705Z3J7LKZA@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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
    ...


> 
> BR, Jarkko