linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <yumeng18@huawei.com>, <herbert@gondor.apana.org.au>,
	<davem@davemloft.net>, <marcel@holtmann.org>,
	<johan.hedberg@gmail.com>, <luiz.dentz@gmail.com>
Cc: <linux-crypto@vger.kernel.org>, <xuzaibo@huawei.com>,
	<wangzhou1@hisilicon.com>, <linux-kernel@vger.kernel.org>,
	<Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
Date: Wed, 24 Feb 2021 10:15:40 +0000	[thread overview]
Message-ID: <e3b4c883-d2f3-0bf0-ffab-42ff5ffe31b8@microchip.com> (raw)
In-Reply-To: <fd3b7c0f-d7f2-3d27-cfef-98ec3614dd1a@huawei.com>

On 2/24/21 3:29 AM, yumeng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 在 2021/2/23 18:44, Tudor.Ambarus@microchip.com 写道:
>> Hi,
>>
>> On 2/23/21 9:10 AM, Meng Yu wrote:
>>> --- a/drivers/crypto/atmel-ecc.c
>>> +++ b/drivers/crypto/atmel-ecc.c
>>> @@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
>>>                  return -EINVAL;
>>>          }
>>>
>>> -       ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
>>> +       ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
>>>          if (!ctx->n_sz || params.key_size) {
>>>                  /* fallback to ecdh software implementation */
>>>                  ctx->do_fallback = true;
>>
>> Now that you moved the curve id info into the alg name, and it is
>> no longer dynamically discovered when decoding the key, does it
>> still make sense to keep the curve id, the key size checks, and
>> the fallback to the software implementation?
>> I think we can keep the curve id, the key size check if 'atmel-ecc' may
> support other curves in the future, and if you're sure P256 is the only
> curve 'atmel-ecc' uses, and it will be changed, we can delete it.
> 
> And fallback to ecdh software implementation is needed when
> params.key_size is zero.
> 

I've read the code again, now I remember. The fallback is needed indeed,
but for other reason. ecdh-nist-p256 will be handled in the crypto IP
only when its user provides a zero length private key: we will use a
pre-provisioned private key that can't be read outside of the device.
The fallback was needed for ecdh-nist-p256 when the user provides a
non-zero private key, or for other curve IDs.

Since the atecc508 and atecc608 (for which there isn't support in kernel
as of now) both support just NIST Standard P256 Elliptic Curve, and the
curve id is now unique per alg, the ctx->curve_id handling does no longer
make sense. So please remove the ctx->curve_id handling. ctx->n_sz can be
removed too and use instead directly ATMEL_ECC_NIST_P256_N_SIZE, similar
to how ATMEL_ECC_PUBKEY_SIZE is used.

  reply	other threads:[~2021-02-24 10:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23  7:10 [PATCH v9 0/7] add ECDH and CURVE25519 algorithms support for Kunpeng 930 Meng Yu
2021-02-23  7:10 ` [PATCH v9 1/7] crypto: hisilicon/hpre - add version adapt to new algorithms Meng Yu
2021-02-23  7:10 ` [PATCH v9 2/7] crypto: hisilicon/hpre - add algorithm type Meng Yu
2021-02-23  7:10 ` [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name Meng Yu
2021-02-23 10:44   ` Tudor.Ambarus
2021-02-24  1:19     ` yumeng
2021-02-24  1:29     ` yumeng
2021-02-24 10:15       ` Tudor.Ambarus [this message]
2021-02-25  0:56         ` yumeng
2021-02-23  7:10 ` [PATCH v9 4/7] crypto: and expose ecc curves Meng Yu
2021-02-23  7:10 ` [PATCH v9 5/7] crypto: hisilicon/hpre - add 'ECDH' algorithm Meng Yu
2021-02-23  7:10 ` [PATCH v9 6/7] crypto: add curve25519 params and expose them Meng Yu
2021-02-23  7:10 ` [PATCH v9 7/7] crypto: hisilicon/hpre - add 'CURVE25519' algorithm Meng Yu

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=e3b4c883-d2f3-0bf0-ffab-42ff5ffe31b8@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=wangzhou1@hisilicon.com \
    --cc=xuzaibo@huawei.com \
    --cc=yumeng18@huawei.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).