[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHvY9JveFyhtETALCH=AFGMGVbGGFMNDGc6ZVngEKbyDQ@mail.gmail.com>
Date: Thu, 28 Jan 2021 11:30:23 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Meng Yu <yumeng18@...wei.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Zaibo Xu <xuzaibo@...wei.com>, wangzhou1@...ilicon.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Daniele Alessandrelli <daniele.alessandrelli@...ux.intel.com>,
Mark Gross <mgross@...ux.intel.com>,
"Khurana, Prabhjot" <prabhjot.khurana@...el.com>,
"Reshetova, Elena" <elena.reshetova@...el.com>
Subject: Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
On Thu, 28 Jan 2021 at 06:04, Herbert Xu <herbert@...dor.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?
Powered by blists - more mailing lists