All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Cc: Meng Yu <yumeng18@huawei.com>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Zaibo Xu <xuzaibo@huawei.com>,
	wangzhou1@hisilicon.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Daniele Alessandrelli <daniele.alessandrelli@linux.intel.com>,
	Mark Gross <mgross@linux.intel.com>,
	"Khurana, Prabhjot" <prabhjot.khurana@intel.com>,
	"Reshetova, Elena" <elena.reshetova@intel.com>,
	Patrick Uiterwijk <patrick@puiterwijk.org>
Subject: Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
Date: Thu, 28 Jan 2021 21:49:41 -0500	[thread overview]
Message-ID: <ff63fffd-2d65-337f-d802-adcf4352fdc3@linux.ibm.com> (raw)
In-Reply-To: <CAMj1kXHvY9JveFyhtETALCH=AFGMGVbGGFMNDGc6ZVngEKbyDQ@mail.gmail.com>

On 1/28/21 5:30 AM, Ard Biesheuvel wrote:
> On Thu, 28 Jan 2021 at 06:04, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
>>> 1. Add ecc curves(P224, P384, P521) for ECDH;
>> OK I think this is getting unwieldy.
>>
>> In light of the fact that we already have hardware that supports
>> a specific subset of curves, I think perhaps it would be better
>> to move the curve ID from the key into the algorithm name instead.
>>
>> IOW, instead of allocating ecdh, you would allocate ecdh-nist-pXXX.
>>
>> Any comments?
>>
> Agreed. Bluetooth appears to be the only in-kernel user at the moment,
> and it is hard coded to use p256, so it can be easily updated.
>
> But this also begs the question which ecdh-nist-pXXX implementations
> we actually need? Why are we exposing these curves in the first place?

In the patch series that I just submitted I would like to expose at 
least NIST p256 to users. Fedora 34 is working to add signatures for 
files to rpms for the Integrity Measurment Architecture (IMA) to be able 
to enforce signatures on executables, libraries etc. The signatures are 
written out into security.ima extended attribute upon rpm installation. 
IMA accesses keys on a keyring to verify these file signatures. RSA 
signatures are much larger, so elliptic curve signatures are much better 
in terms of storage size needed for storing them in rpms. They add like 
1% of size. Fedora is using a NIST P256 key.

Besides that Fedora and RHEL support only these curves here in openssl 
(Ubuntu supports a lot more):

$ openssl ecparam -list_curves
   secp224r1 : NIST/SECG curve over a 224 bit prime field
   secp256k1 : SECG curve over a 256 bit prime field
   secp384r1 : NIST/SECG curve over a 384 bit prime field
   secp521r1 : NIST/SECG curve over a 521 bit prime field
   prime256v1: X9.62/SECG curve over a 256 bit prime field

So from that perspective it makes a lot of sense to support some of 
these and allow users to load them into the kernel.


In my patch series I initially had registered the akciphers under the 
names ecc-nist-p192 and ecc-nist-p256 but now, in V4, joined them 
together as 'ecdsa'. This may be too generic for a name. Maybe it should 
be called ecsda-nist for the NIST family.

    Stefan


  parent reply	other threads:[~2021-01-29  2:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  7:09 [PATCH v7 0/7] add ECDH and CURVE25519 algorithms support for Kunpeng 930 Meng Yu
2021-01-22  7:09 ` [PATCH v7 1/7] crypto: hisilicon/hpre - add version adapt to new algorithms Meng Yu
2021-01-22  7:09 ` [PATCH v7 2/7] crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930 Meng Yu
2021-01-22  7:09 ` [PATCH v7 3/7] crypto: hisilicon/hpre - add algorithm type Meng Yu
2021-01-22  7:09 ` [PATCH v7 4/7] crypto: add ecc curve and expose them Meng Yu
2021-01-28  5:03   ` Herbert Xu
2021-01-28 10:30     ` Ard Biesheuvel
2021-01-28 10:39       ` Herbert Xu
2021-02-01 17:09         ` Daniele Alessandrelli
2021-02-02  5:13           ` Herbert Xu
2021-02-02  9:27             ` Alessandrelli, Daniele
2021-02-02  9:42               ` Herbert Xu
2021-02-02 12:35                 ` Alessandrelli, Daniele
2021-02-04  5:31                   ` Herbert Xu
2021-01-29  2:49       ` Stefan Berger [this message]
2021-01-29  3:00         ` Herbert Xu
2021-02-08  6:35           ` Vitaly Chikunov
2021-02-08  6:47             ` Ard Biesheuvel
2021-02-08 21:27               ` Vitaly Chikunov
2021-02-01  3:45     ` yumeng
2021-02-03 18:03     ` Saulo Alessandre
2021-02-04  5:41       ` Herbert Xu
2021-01-22  7:09 ` [PATCH v7 5/7] crypto: add curve 25519 " Meng Yu
2021-01-22  7:09 ` [PATCH v7 6/7] crypto: hisilicon/hpre - add 'ECDH' algorithm Meng Yu
2021-01-22  7:09 ` [PATCH v7 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=ff63fffd-2d65-337f-d802-adcf4352fdc3@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=ardb@kernel.org \
    --cc=daniele.alessandrelli@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=elena.reshetova@intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=patrick@puiterwijk.org \
    --cc=prabhjot.khurana@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.