From: "Jarkko Sakkinen" <jarkko@kernel.org>
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>,
"Stefan Berger" <stefanb@linux.ibm.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crypto: ecdsa: Fix the public key format description
Date: Tue, 28 May 2024 01:18:23 +0300 [thread overview]
Message-ID: <D1KRXI87G4S0.1ROKTQENIZHT7@kernel.org> (raw)
In-Reply-To: <D1KRILI1KRQ8.2CNPU7PFES0VI@kernel.org>
On Tue May 28, 2024 at 12:58 AM EEST, Jarkko Sakkinen wrote:
> On Tue May 28, 2024 at 12:05 AM EEST, Jarkko Sakkinen wrote:
> > On Mon May 27, 2024 at 11:28 PM EEST, Jarkko Sakkinen wrote:
> > > Public key blob is not just x and y concatenated. It follows RFC5480
> > > section 2.2. Address this by re-documenting the function with the
> > > correct description of the format.
> > >
> > > Link: https://datatracker.ietf.org/doc/html/rfc5480
> > > Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification")
> > > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > ---
> > > It is a bug fix that does not really need a stable backport. Still
> > > categorizes as a bug because by following the existing documentation
> > > you end up with an error code.
> > > crypto/ecdsa.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
> > > index 258fffbf623d..55114146ff84 100644
> > > --- a/crypto/ecdsa.c
> > > +++ b/crypto/ecdsa.c
> > > @@ -215,9 +215,8 @@ static int ecdsa_ecc_ctx_reset(struct ecc_ctx *ctx)
> > > }
> > >
> > > /*
> > > - * Set the public key given the raw uncompressed key data from an X509
> > > - * certificate. The key data contain the concatenated X and Y coordinates of
> > > - * the public key.
> > > + * Set the public ECC key as defined by RFC5480 section 2.2 "Subject Public
> > > + * Key". Only the uncompressed format is supported.
> > > */
> > > static int ecdsa_set_pub_key(struct crypto_akcipher *tfm, const void *key, unsigned int keylen)
> > > {
> >
> > Based on this, is this now along the lines of correct format":
> >
> > *ptr++ = 0x04; /* uncompressed */
> > ptr = asn1_encode_octet_string(&ptr[0], &in[sizeof(in)], &x[0], x_size);
> > ptr = asn1_encode_octet_string(&ptr[0], &in[sizeof(in)], &x[x_size + 2], x_size);
> > in_len = ptr - in;
> > ret = crypto_akcipher_set_pub_key(tfm, in, in_len);
>
>
> I fixed up the above as it should be only single octect string to this:
>
> ptr = &in[0];
> *ptr++ = 0x04; /* uncompressed */
> ptr = asn1_encode_octet_string(&ptr[0], &in[sizeof(in)],
> &data[0], 2 * x_size);
> in_len = ptr - in;
> pr_info("in_len=%u\n", in_len);
> ret = crypto_akcipher_set_pub_key(tfm, in, in_len);
> crypto_free_akcipher(tfm);
>
> It fails in:
>
> ndigits = DIV_ROUND_UP(digitlen, sizeof(u64));
> if (ndigits != ctx->curve->g.ndigits)
> return -EINVAL;
>
> I checked that in_len=67.
>
> The tfm is deleted at instant because the above code is part of *_query.
> TPM2 ECDSA asymmetric key that way that signature verification will work
> when it is needed. The key type signs with TPM and verifies with the
> software cipher.
3rd trial, i.e. no octect encoding at all but with the undocumented
(in the current mainline) prefix byte:
ptr = &data[0];
*ptr++ = 0x04; /* uncompressed */
memcpy(&ptr[0], &x[0], x_size);
memcpy(&ptr[x_size], &x[x_size + 2], x_size);
ret = crypto_akcipher_set_pub_key(tfm, data, 3 * x_size + 1);
crypto_free_akcipher(tfm);
I added also kprobe:
echo 'r:ecdsa ecdsa_set_pub_key $retval' >> /sys/kernel/tracing/kprobe_events
echo 1 > /sys/kernel/tracing/events/kprobes/enable
cat /sys/kernel/tracing/dynamic_events
Results:
ecdsa: (ecdsa_set_pub_key+0xc1/0xe0 <- ecc_is_pubkey_valid_full) arg1=0xffffffea
So I guess this is on a right track reverse engineering the format used
in this API at least :-)
BR, Jarkko
next prev parent reply other threads:[~2024-05-27 22:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 20:28 [PATCH] crypto: ecdsa: Fix the public key format description Jarkko Sakkinen
2024-05-27 21:05 ` Jarkko Sakkinen
2024-05-27 21:58 ` Jarkko Sakkinen
2024-05-27 22:18 ` Jarkko Sakkinen [this message]
2024-05-27 22:31 ` Jarkko Sakkinen
2024-05-27 22:49 ` Jarkko Sakkinen
2024-05-27 22:59 ` Jarkko Sakkinen
2024-05-28 12:37 ` Stefan Berger
2024-05-28 13:18 ` Jarkko Sakkinen
2024-05-28 13:26 ` Jarkko Sakkinen
2024-05-28 13:29 ` Jarkko Sakkinen
2024-05-28 11:18 ` Stefan Berger
2024-05-28 11:43 ` Jarkko Sakkinen
2024-06-07 11:53 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D1KRXI87G4S0.1ROKTQENIZHT7@kernel.org \
--to=jarkko@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).