All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>
Cc: "Stephan Müller" <smueller@chronox.de>,
	"Hannes Reinecke" <hare@suse.de>, "Torsten Duwe" <duwe@suse.de>,
	"Zaibo Xu" <xuzaibo@huawei.com>,
	"Giovanni Cabiddu" <giovanni.cabiddu@intel.com>,
	"David Howells" <dhowells@redhat.com>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	qat-linux@intel.com, keyrings@vger.kernel.org,
	"Nicolai Stange" <nstange@suse.de>
Subject: [PATCH 00/18] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance
Date: Wed,  1 Dec 2021 01:48:40 +0100	[thread overview]
Message-ID: <20211201004858.19831-1-nstange@suse.de> (raw)

Hi all,

first of all, to the people primarily interested in security/keys/, there's
a rather trivial change to security/keys/dh.c in patch 2/18. It would be
great to get ACKs for that...


Hannes' recent work on NVME in-band authentication ([1]) needs access to
the RFC 7919 DH group parameters and also some means to generate ephemeral
keys. He currently implements both as part of his patchset (patches 3/12
and 8/12). After some internal discussion, we decided to split off the bits
needed from crypto/dh into a separate series, i.e. this one here:
 - for the RFC 7919 DH group parameters, it's undesirable from a
   performance POV to serialize the well-known domain parameters via
   crypto_dh_encode_key() just to deserialize them shortly after again,
 - from an architectural POV, it would be preferrable to have the key
   generation code in crypto/dh.c rather than in drivers/nvme/,
   just in analogy to how key generation is supported by crypto/ecdh.c
   already.

Patches 1-13/18 implement all that is needed for the NVME in-band
authentication support. 

Unfortunately, due to the lack of HW, I have not been able to test
the changes to the QAT or HPRE drivers (other than mere compile tests).
Yet I figured it would be a good idea to have them behave consistently with
dh_generic, and so I chose to introduce support for privkey generation to
these as well.


By coincidence, NIST SP800-56Arev3 compliance effectively requires that
the domain parameters are checked against an approved set, which happens
to consists of those safe-prime group parameters specified in RFC 7919,
among others. Thus, introducing the RFC 7919 parameters to the kernel
allows for making the DH implementation to conform to SP800-56Arev3 with
only little effort. I used the opportunity to work crypto/dh towards
SP800-56Arev3 conformance with the rest of this patch series, i.e.
patches 14-18/18. I can split these into another series on its own, if you
like. But as they depend on the earlier patches 1-13/18, I sent them
alongside for now.

This patchset has been tested with and without fips_enabled on x86_64,
ppc64le and s390x, the latter being a big endian machine, which is relevant
for the new test vectors.

Thanks,

Nicolai

[1] https://lkml.kernel.org/r/20211123123801.73197-1-hare@suse.de

Nicolai Stange (18):
  crypto: dh - remove struct dh's ->q member
  crypto: dh - constify struct dh's pointer members
  crypto: dh - optimize domain parameter serialization for well-known
    groups
  crypto: dh - introduce RFC 7919 safe-prime groups
  crypto: testmgr - add DH RFC 7919 ffdhe2048 test vector
  crypto: dh - introduce RFC 3526 safe-prime groups
  crypto: testmgr - add DH RFC 3526 modp2048 test vector
  crypto: testmgr - run only subset of DH vectors based on config
  crypto: dh - implement private key generation primitive
  crypto: dh - introduce support for ephemeral key generation to
    dh-generic
  crypto: dh - introduce support for ephemeral key generation to hpre
    driver
  crypto: dh - introduce support for ephemeral key generation to qat
    driver
  crypto: testmgr - add DH test vectors for key generation
  lib/mpi: export mpi_rshift
  crypto: dh - store group id in dh-generic's dh_ctx
  crypto: dh - calculate Q from P for the full public key verification
  crypto: dh - try to match domain parameters to a known safe-prime
    group
  crypto: dh - accept only approved safe-prime groups in FIPS mode

 crypto/Kconfig                                |  20 +-
 crypto/dh.c                                   |  73 +-
 crypto/dh_helper.c                            | 691 +++++++++++++++++-
 crypto/testmgr.h                              | 342 ++++++++-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c   |  11 +
 drivers/crypto/qat/qat_common/qat_asym_algs.c |   9 +
 include/crypto/dh.h                           |  52 +-
 lib/mpi/mpi-bit.c                             |   1 +
 security/keys/dh.c                            |   2 +-
 9 files changed, 1141 insertions(+), 60 deletions(-)

-- 
2.26.2


             reply	other threads:[~2021-12-01  0:49 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01  0:48 Nicolai Stange [this message]
2021-12-01  0:48 ` [PATCH 01/18] crypto: dh - remove struct dh's ->q member Nicolai Stange
2021-12-01  7:11   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 02/18] crypto: dh - constify struct dh's pointer members Nicolai Stange
2021-12-01  7:13   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 03/18] crypto: dh - optimize domain parameter serialization for well-known groups Nicolai Stange
2021-12-01  7:17   ` Hannes Reinecke
2021-12-09  9:08     ` Nicolai Stange
2021-12-01  0:48 ` [PATCH 04/18] crypto: dh - introduce RFC 7919 safe-prime groups Nicolai Stange
2021-12-01  7:23   ` Hannes Reinecke
2021-12-09  9:10     ` Nicolai Stange
2021-12-01  0:48 ` [PATCH 05/18] crypto: testmgr - add DH RFC 7919 ffdhe2048 test vector Nicolai Stange
2021-12-01  7:24   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 06/18] crypto: dh - introduce RFC 3526 safe-prime groups Nicolai Stange
2021-12-01  7:24   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 07/18] crypto: testmgr - add DH RFC 3526 modp2048 test vector Nicolai Stange
2021-12-01  7:25   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 08/18] crypto: testmgr - run only subset of DH vectors based on config Nicolai Stange
2021-12-01  7:28   ` Hannes Reinecke
2021-12-09  9:18     ` Nicolai Stange
2021-12-01  0:48 ` [PATCH 09/18] crypto: dh - implement private key generation primitive Nicolai Stange
2021-12-01  7:28   ` Hannes Reinecke
2021-12-05  5:52   ` Stephan Müller
2021-12-08  6:20     ` Nicolai Stange
2021-12-08  7:16       ` Stephan Mueller
2021-12-01  0:48 ` [PATCH 10/18] crypto: dh - introduce support for ephemeral key generation to dh-generic Nicolai Stange
2021-12-01  7:29   ` Hannes Reinecke
2021-12-05  6:11   ` Stephan Müller
2021-12-08  6:32     ` Nicolai Stange
2021-12-01  0:48 ` [PATCH 11/18] crypto: dh - introduce support for ephemeral key generation to hpre driver Nicolai Stange
2021-12-01  7:30   ` Hannes Reinecke
2021-12-05  6:11   ` Stephan Müller
2021-12-01  0:48 ` [PATCH 12/18] crypto: dh - introduce support for ephemeral key generation to qat driver Nicolai Stange
2021-12-01  7:30   ` Hannes Reinecke
2021-12-05  6:11   ` Stephan Müller
2021-12-01  0:48 ` [PATCH 13/18] crypto: testmgr - add DH test vectors for key generation Nicolai Stange
2021-12-01  7:31   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 14/18] lib/mpi: export mpi_rshift Nicolai Stange
2021-12-01  7:32   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 15/18] crypto: dh - store group id in dh-generic's dh_ctx Nicolai Stange
2021-12-01  7:32   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification Nicolai Stange
2021-12-01  7:33   ` Hannes Reinecke
2021-12-05  6:07   ` Stephan Müller
2021-12-08  6:41     ` Nicolai Stange
2021-12-01  0:48 ` [PATCH 17/18] crypto: dh - try to match domain parameters to a known safe-prime group Nicolai Stange
2021-12-01  7:34   ` Hannes Reinecke
2021-12-01  0:48 ` [PATCH 18/18] crypto: dh - accept only approved safe-prime groups in FIPS mode Nicolai Stange
2021-12-01  7:34   ` Hannes Reinecke
2021-12-09  9:26     ` Nicolai Stange

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=20211201004858.19831-1-nstange@suse.de \
    --to=nstange@suse.de \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=duwe@suse.de \
    --cc=giovanni.cabiddu@intel.com \
    --cc=hare@suse.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qat-linux@intel.com \
    --cc=smueller@chronox.de \
    --cc=xuzaibo@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.