Re: [PATCH v7 4/7] crypto: add ecc curve and expose them

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/28/21 5:30 AM, Ard Biesheuvel wrote:
On Thu, 28 Jan 2021 at 06:04, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux