kernel/linux.git/crypto/Kconfig, branch v5.18

Merge tag 'for-5.18/64bit-pi-2022-03-25' of git://git.kernel.dk/linux-block

2022-03-26T19:01:35+00:00

Pull block layer 64-bit data integrity support from Jens Axboe: "This adds support for 64-bit data integrity in the block layer and in NVMe" * tag 'for-5.18/64bit-pi-2022-03-25' of git://git.kernel.dk/linux-block: crypto: fix crc64 testmgr digest byte order nvme: add support for enhanced metadata block: add pi for extended integrity crypto: add rocksoft 64b crc guard tag framework lib: add rocksoft model crc64 linux/kernel: introduce lower_48_bits function asm-generic: introduce be48 unaligned accessors nvme: allow integrity on extended metadata formats block: support pi with extended metadata

crypto: add rocksoft 64b crc guard tag framework

2022-03-07T19:48:35+00:00

Hardware specific features may be able to calculate a crc64, so provide a framework for drivers to register their implementation. If nothing is registered, fallback to the generic table lookup implementation. The implementation is modeled after the crct10dif equivalent. Signed-off-by: Keith Busch Link: https://lore.kernel.org/r/20220303201312.3255347-7-kbusch@kernel.org Signed-off-by: Jens Axboe

crypto: dh - implement private key generation primitive for ffdheXYZ(dh)

2022-03-02T22:47:51+00:00

The support for NVME in-band authentication currently in the works ([1]) needs to generate ephemeral DH keys for use with the RFC 7919 safe-prime FFDHE groups. In analogy to ECDH and its ecc_gen_privkey(), implement a dh_safe_prime_gen_privkey() and invoke it from the ffdheXYZ(dh) templates' common ->set_secret(), i.e. dh_safe_prime_set_secret(), in case the input ->key_size is zero. As the RFC 7919 FFDHE groups are classified as approved safe-prime groups by SP800-56Arev3, it's worthwhile to make the new dh_safe_prime_gen_privkey() to follow the approach specified in SP800-56Arev3, sec. 5.6.1.1.3 ("Key-Pair Generation Using Extra Random Bits") in order to achieve conformance. SP800-56Arev3 specifies a lower as well as an upper bound on the generated key's length: - it must be >= two times the maximum supported security strength of the group in question and - it must be <= the length of the domain parameter Q. For any safe-prime group Q = (P - 1)/2 by definition and the individual maximum supported security strengths as specified by SP800-56Arev3 have been made available as part of the FFDHE dh_safe_prime definitions introduced with a previous patch. Make dh_safe_prime_gen_privkey() pick twice the maximum supported strength rounded up to the next power of two for the output key size. This choice respects both, the lower and upper bounds given by SP800-90Arev3 for any of the approved safe-prime groups and is also in line with the NVME base spec 2.0, which requires the key size to be >= 256bits. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: dh - implement ffdheXYZ(dh) templates

2022-03-02T22:47:51+00:00

Current work on NVME in-band authentication support ([1]) needs to invoke DH with the FFDHE safe-prime group parameters specified in RFC 7919. Introduce a new CRYPTO_DH_RFC7919_GROUPS Kconfig option. If enabled, make dh_generic register a couple of ffdheXYZ(dh) templates, one for each group: ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh). Their respective ->set_secret() expects a (serialized) struct dh, just like the underlying "dh" implementation does, but with the P and G values unset so that the safe-prime constants for the given group can be filled in by the wrapping template. Internally, a struct dh_safe_prime instance is being defined for each of the ffdheXYZ(dh) templates as appropriate. In order to prepare for future key generation, fill in the maximum security strength values as specified by SP800-56Arev3 on the go, even though they're not needed at this point yet. Implement the respective ffdheXYZ(dh) crypto_template's ->create() by simply forwarding any calls to the __dh_safe_prime_create() helper introduced with the previous commit, passing the associated dh_safe_prime in addition to the received ->create() arguments. [1] https://lore.kernel.org/r/20211202152358.60116-1-hare@suse.de Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: lrw - Add dependency on ecb

2022-02-18T05:21:08+00:00

The lrw template relies on ecb to work. So we need to declare a Kconfig dependency as well as a module softdep on it. Signed-off-by: Herbert Xu

crypto: kdf - Select hmac in addition to sha256

2022-01-31T00:21:43+00:00

In addition to sha256 we must also enable hmac for the kdf self-test to work. Reported-by: kernel test robot Fixes: 304b4acee2f0 ("crypto: kdf - select SHA-256 required...") Fixes: 026a733e6659 ("crypto: kdf - add SP800-108 counter key...") Signed-off-by: Herbert Xu

crypto: x86/sm3 - add AVX assembly implementation

2022-01-28T05:51:11+00:00

This patch adds AVX assembly accelerated implementation of SM3 secure hash algorithm. From the benchmark data, compared to pure software implementation sm3-generic, the performance increase is up to 38%. The main algorithm implementation based on SM3 AES/BMI2 accelerated work by libgcrypt at: https://gnupg.org/software/libgcrypt/index.html Benchmark on Intel i5-6200U 2.30GHz, performance data of two implementations, pure software sm3-generic and sm3-avx acceleration. The data comes from the 326 mode and 422 mode of tcrypt. The abscissas are different lengths of per update. The data is tabulated and the unit is Mb/s: update-size | 16 64 256 1024 2048 4096 8192 ------------+------------------------------------------------------- sm3-generic | 105.97 129.60 182.12 189.62 188.06 193.66 194.88 sm3-avx | 119.87 163.05 244.44 260.92 257.60 264.87 265.88 Signed-off-by: Tianjia Zhang Signed-off-by: Herbert Xu

crypto: sm3 - make dependent on sm3 library

2022-01-28T05:51:11+00:00

SM3 generic library is stand-alone implementation, it is necessary making the sm3-generic implementation to depends on SM3 library. The functions crypto_sm3_*() provided by sm3_generic is no longer exported. Signed-off-by: Tianjia Zhang Signed-off-by: Herbert Xu

crypto: sm2 - make dependent on sm3 library

2022-01-28T05:51:10+00:00

SM3 generic library is stand-alone implementation, it is necessary for the calculation of sm2 z digest to depends on SM3 library instead of sm3-generic. Signed-off-by: Tianjia Zhang Signed-off-by: Herbert Xu

lib/crypto: add prompts back to crypto libraries

2022-01-18T12:03:55+00:00

Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took away a number of prompt texts from other crypto libraries. This makes values flip from built-in to module when oldconfig runs, and causes problems when these crypto libs need to be built in for thingslike BIG_KEYS. Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") Cc: Herbert Xu Cc: linux-crypto@vger.kernel.org Signed-off-by: Justin M. Forbes [Jason: - moved menu into submenu of lib/ instead of root menu - fixed chacha sub-dependencies for CONFIG_CRYPTO] Signed-off-by: Jason A. Donenfeld