Received-SPF: pass (google.com: domain of linux-crypto+bounces-4431-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 28 May 2024 01:59:23 +0300
Message-Id: <D1KSSWD7FA94.5705Z3J7LKZA@kernel.org>
Cc: <linux-crypto@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>,
 "Stefan Berger" <stefanb@linux.ibm.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crypto: ecdsa: Fix the public key format description
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>, "Herbert Xu"
 <herbert@gondor.apana.org.au>
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>
In-Reply-To: <D1KSLKGUWGFO.21T4OBXQQ88D@kernel.org>

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 =3D 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=3D0xf=
fffffea
>
> Totally lost with the expected input format after trying out various=20
> options.

OK got it working with:

        ptr =3D &data[0];
        *ptr++ =3D 0x04; /* uncompressed */
        memcpy(&ptr[0], &x[2], x_size);
        memcpy(&ptr[x_size], &x[2 + x_size + 2], x_size);
        ret =3D 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.

BR, Jarkko