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
