Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp135511pxb; Wed, 24 Feb 2021 21:06:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQr1MbIeYT+R0WQgJ/GzwLbj/xbBkN4H1vcAo8j09GJbXpXYnCXNd6/lQHLfWmUmKG4Hop X-Received: by 2002:a17:906:26c9:: with SMTP id u9mr1032715ejc.166.1614229576449; Wed, 24 Feb 2021 21:06:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614229576; cv=none; d=google.com; s=arc-20160816; b=vYCnGlbf2aFca2jOGErnGbNsJ409RqRw3zkRQFUX+oYn9SF+TNNSnGqRG7YCLfiEZF hxxkH25Jw8qebMiulfda9a6kk9me4fI+G2O8YnOGhXEh8uuebAw9t25h568+1k32SFfz ToQ6AKYgdnfggyGU5RmU4N0UIJqDru0Z6CCvbt7DvjmSbl4e5xCdmfbEiG8iyr0bQiiI WKfYhPcVPd7vj8vH3GXT+QJ3S9zPqO2td0ZU08S18DJVIcPNzxy8BNib3D88dMFnuGXL 0dXH4xDvMfrjCvuqh3iMCIxdK+M6pY/3cRYGHhfB2hn0KMNpWuw9X4VkCnKw2IxBp0zs RMIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=IkE0U83QkbsxmQQuSly018LRRpsowSUwaV4rHhkLfPw=; b=aVAGUTnfZEcrltbWdDFowUP7ptV2CqvSy8yJUiShvvtQTEsk1PJVxk983ew4t2Rj/0 4lWRnMQ3J0bsJ3HpEFRW6mfB7nhphqRSJCPMl5qSCL0F1gkDZx95ITFn5bK4NN3WbT8G 2zElY3pYUega8jys2a6jBnjNwkiqBnJOzn7K4a8sKgrEQmjvXOfN1+kaP6tM6BGbkbpA 0AAEgjV0ymqEprUM0ymlS6q+elIpi7MmTtDj2MaXicQu1jk9Iwijn19EvFGEJDQcNMGo jCbu+ZOcLrOJ2SHnWbqRATJcOSOyST/n62N9Uxw7P/7mqv1h2Qwzol4UUgsy5FYfy45V BJeg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc10si2755727edb.153.2021.02.24.21.05.53; Wed, 24 Feb 2021 21:06:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236609AbhBYA6S (ORCPT + 99 others); Wed, 24 Feb 2021 19:58:18 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:12997 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236664AbhBYA5w (ORCPT ); Wed, 24 Feb 2021 19:57:52 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DmDq81WnszjS6b; Thu, 25 Feb 2021 08:55:32 +0800 (CST) Received: from [10.67.103.10] (10.67.103.10) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.498.0; Thu, 25 Feb 2021 08:57:01 +0800 Subject: Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name To: , , , , , CC: , , , , References: <1614064219-40701-1-git-send-email-yumeng18@huawei.com> <1614064219-40701-4-git-send-email-yumeng18@huawei.com> <8b96c136-dca9-5b6a-2221-e906d265c40b@microchip.com> From: yumeng Message-ID: Date: Thu, 25 Feb 2021 08:56:55 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.10] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/2/24 18:15, Tudor.Ambarus@microchip.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. > OK, thanks, I will remove it. But I'd like to wait 2 more days, as maybe the owners of other modules (like crypto or bluetooth) have any comments. thanks.