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
prev 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®