All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Nicolai Stange <nstange@suse.de>
Cc: Hannes Reinecke <hare@suse.de>, Torsten Duwe <duwe@suse.de>,
	David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	keyrings@vger.kernel.org, Nicolai Stange <nstange@suse.de>
Subject: Re: [PATCH v3 00/15] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance
Date: Thu, 03 Feb 2022 18:11:53 +0100	[thread overview]
Message-ID: <8937519.l8FpVtv5Hg@tauon.chronox.de> (raw)
In-Reply-To: <20220202104012.4193-1-nstange@suse.de>

Am Mittwoch, 2. Februar 2022, 11:39:57 CET schrieb Nicolai Stange:

Hi Nicolai,

> 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 4/15. It would be
> great to get ACKs for that...
> 
> This is a complete rework of the v2 patchset to be found at [1]. Most
> notably, the ffdheXYZ groups are now made accessible by means of templates
> wrapping the generic dh: ffdhe2048(dh) ffdhe3072(dh), etc, rather than by
> that fixed enum dh_group_id as before. For your reference, this change has
> been suggested at [2].
> 
> Plain "dh" usage will be disallowed in FIPS mode now, which will break
> keyctl(KEYCTL_DH_COMPUTE) functionality in FIPS mode. As per the
> discussion from [2], this is acceptable or perhaps even desirable.
> 
> The only motivation to include the RFC 3526 MODP groups in the previous v2
> had been to keep keyctl(KEYCTL_DH_COMPUTE) somewhat workable in FIPS mode.
> These groups have been dropped accordingly now and this patchset only
> introduces support for the RFC 7919 FFDHE groups, which is what is needed
> by NVM in-band authentication.
> 
> In order to be able to restrict plain "dh" usage in FIPS mode while
> still allowing the usage of those new ffdheXYZ(dh) instantiations, I
> incorporated a modified version of the patch posted by Herbert at
> [3] ("crypto: api - Disallow sha1 in FIPS-mode while allowing hmac(sha1)")
> into this series here as [12/15] ("crypto: api - allow algs only in
> specific constructions in FIPS mode"). There had been two changes worth
> mentioning:
> - An attempt to make it more generic by having crypto_grab_spawn()
>   to include FIPS_INTERNAL in the lookup and also, to let
>   crypto_register_instance() to propagate this flag from the
>   child spawns into the instance to be registered.
> - To skip the actual self-test executions for !->fips_allowed algorithms,
>   just as before. The rationale for this can be found in the discussion to
>   [3].
> With these changes, all breakage is to blame on me and thus, I assumed
> authorship of this patch. I reflected the fact that this is heavily based
> on Herbert's work by means of an Originally-by tag and sincerely hope this
> is an appropriate way of recording the patch's history.
> 
> This series has been tested on x86_64 and s390x (big endian) with FIPS mode
> both enabled and disabled each.

Using the NIST ACVP reference implementation, shared secret computation and 
key generation was successfully tested.

Tested-by: Stephan Mueller <smueller@chronox.de>


Ciao
Stephan



      parent reply	other threads:[~2022-02-03 17:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 10:39 [PATCH v3 00/15] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance Nicolai Stange
2022-02-02 10:39 ` [PATCH v3 01/15] crypto: kpp - provide support for KPP template instances Nicolai Stange
2022-02-02 10:39 ` [PATCH v3 02/15] crypto: kpp - provide support for KPP spawns Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 03/15] crypto: dh - remove struct dh's ->q member Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 04/15] crypto: dh - constify struct dh's pointer members Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 05/15] crypto: dh - split out deserialization code from crypto_dh_decode() Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 06/15] crypto: dh - introduce common code for built-in safe-prime group support Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 07/15] crypto: dh - implement ffdheXYZ(dh) templates Nicolai Stange
2022-02-11  9:09   ` Herbert Xu
2022-02-14  8:38     ` Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 08/15] crypto: testmgr - add known answer tests for " Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 09/15] crypto: dh - implement private key generation primitive for ffdheXYZ(dh) Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 10/15] crypto: testmgr - add keygen tests for ffdheXYZ(dh) templates Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 11/15] crypto: dh - allow for passing NULL to the ffdheXYZ(dh)s' ->set_secret() Nicolai Stange
2022-02-11  9:09   ` Herbert Xu
2022-02-14  8:53     ` Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 12/15] crypto: api - allow algs only in specific constructions in FIPS mode Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 13/15] crypto: dh - disallow plain "dh" usage " Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 14/15] lib/mpi: export mpi_rshift Nicolai Stange
2022-02-02 10:40 ` [PATCH v3 15/15] crypto: dh - calculate Q from P for the full public key verification Nicolai Stange
2022-02-03 17:11 ` Stephan Mueller [this message]

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=8937519.l8FpVtv5Hg@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=duwe@suse.de \
    --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=nstange@suse.de \
    /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.