lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 03 Feb 2022 18:11:53 +0100 From: Stephan Mueller <smueller@...onox.de> To: Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, Nicolai Stange <nstange@...e.de> Cc: Hannes Reinecke <hare@...e.de>, Torsten Duwe <duwe@...e.de>, David Howells <dhowells@...hat.com>, Jarkko Sakkinen <jarkko@...nel.org>, linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, keyrings@...r.kernel.org, Nicolai Stange <nstange@...e.de> Subject: Re: [PATCH v3 00/15] crypto: dh - infrastructure for NVM in-band auth and FIPS conformance 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@...onox.de> Ciao Stephan
Powered by blists - more mailing lists