kernel/linux.git/crypto/tcrypt.c, branch linux-6.0.y

crypto: tcrypt - Fix multibuffer skcipher speed test mem leak

2022-12-31T12:26:20+00:00

[ Upstream commit 1aa33fc8d4032227253ceb736f47c52b859d9683 ] In the past, the data for mb-skcipher test has been allocated twice, that means the first allcated memory area is without free, which may cause a potential memory leakage. So this patch is to remove one allocation to fix this error. Fixes: e161c5930c15 ("crypto: tcrypt - add multibuf skcipher...") Signed-off-by: Zhang Yiqun Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: tcrypt - fix return value for multiple subtests

2022-12-31T12:26:16+00:00

[ Upstream commit 65c92cbb3f2365627a10cf97560d51e88fb4e588 ] When a test mode invokes multiple tests (e.g., mode 0 invokes modes 1 through 199, and mode 3 tests three block cipher modes with des), don't keep accumulating the return values with ret += tcrypt_test(), which results in a bogus value if more than one report a nonzero value (e.g., two reporting -2 (-ENOENT) end up reporting -4 (-EINTR)). Instead, keep track of the minimum return value reported by any subtest. Fixes: 4e033a6bc70f ("crypto: tcrypt - Do not exit on success in fips mode") Signed-off-by: Robert Elliott Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: tcrypt - Remove the static variable initialisations to NULL

2022-07-29T10:29:18+00:00

Initialise global and static variable to NULL is always unnecessary. Remove the unnecessary initialisations. Signed-off-by: Jason Wang Signed-off-by: Herbert Xu

crypto: testmgr - add ARIA testmgr tests

2022-07-15T08:43:20+00:00

It contains ARIA ecb(aria), cbc(aria), cfb(aria), ctr(aria), and gcm(aria). ecb testvector is from RFC standard. cbc, cfb, and ctr testvectors are from KISA[1], who developed ARIA algorithm. gcm(aria) is from openssl test vector. [1] https://seed.kisa.or.kr/kisa/kcmvp/EgovVerification.do (Korean) Signed-off-by: Taehee Yoo Signed-off-by: Herbert Xu

crypto: blake2s - remove shash module

2022-06-10T08:43:49+00:00

BLAKE2s has no currently known use as an shash. Just remove all of this unnecessary plumbing. Removing this shash was something we talked about back when we were making BLAKE2s a built-in, but I simply never got around to doing it. So this completes that project. Importantly, this fixs a bug in which the lib code depends on crypto_simd_disabled_for_test, causing linker errors. Also add more alignment tests to the selftests and compare SIMD and non-SIMD compression functions, to make up for what we lose from testmgr.c. Reported-by: gaochao Cc: Eric Biggers Cc: Ard Biesheuvel Cc: stable@vger.kernel.org Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in") Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu

crypto: hctr2 - Add HCTR2 support

2022-06-10T08:40:17+00:00

Add support for HCTR2 as a template. HCTR2 is a length-preserving encryption mode that is efficient on processors with instructions to accelerate AES and carryless multiplication, e.g. x86 processors with AES-NI and CLMUL, and ARM processors with the ARMv8 Crypto Extensions. As a length-preserving encryption mode, HCTR2 is suitable for applications such as storage encryption where ciphertext expansion is not possible, and thus authenticated encryption cannot be used. Currently, such applications usually use XTS, or in some cases Adiantum. XTS has the disadvantage that it is a narrow-block mode: a bitflip will only change 16 bytes in the resulting ciphertext or plaintext. This reveals more information to an attacker than necessary. HCTR2 is a wide-block mode, so it provides a stronger security property: a bitflip will change the entire message. HCTR2 is somewhat similar to Adiantum, which is also a wide-block mode. However, HCTR2 is designed to take advantage of existing crypto instructions, while Adiantum targets devices without such hardware support. Adiantum is also designed with longer messages in mind, while HCTR2 is designed to be efficient even on short messages. HCTR2 requires POLYVAL and XCTR as components. More information on HCTR2 can be found here: "Length-preserving encryption with HCTR2": https://eprint.iacr.org/2021/1441.pdf Signed-off-by: Nathan Huckleberry Reviewed-by: Ard Biesheuvel Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: polyval - Add POLYVAL support

2022-06-10T08:40:17+00:00

Add support for POLYVAL, an ε-Δ-universal hash function similar to GHASH. This patch only uses POLYVAL as a component to implement HCTR2 mode. It should be noted that POLYVAL was originally specified for use in AES-GCM-SIV (RFC 8452), but the kernel does not currently support this mode. POLYVAL is implemented as an shash algorithm. The implementation is modified from ghash-generic.c. For more information on POLYVAL see: Length-preserving encryption with HCTR2: https://eprint.iacr.org/2021/1441.pdf AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption: https://datatracker.ietf.org/doc/html/rfc8452 Signed-off-by: Nathan Huckleberry Reviewed-by: Eric Biggers Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: xctr - Add XCTR support

2022-06-10T08:40:16+00:00

Add a generic implementation of XCTR mode as a template. XCTR is a blockcipher mode similar to CTR mode. XCTR uses XORs and little-endian addition rather than big-endian arithmetic which has two advantages: It is slightly faster on little-endian CPUs and it is less likely to be implemented incorrect since integer overflows are not possible on practical input sizes. XCTR is used as a component to implement HCTR2. More information on XCTR mode can be found in the HCTR2 paper: https://eprint.iacr.org/2021/1441.pdf Signed-off-by: Nathan Huckleberry Reviewed-by: Eric Biggers Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: api - allow algs only in specific constructions in FIPS mode

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

Currently we do not distinguish between algorithms that fail on the self-test vs. those which are disabled in FIPS mode (not allowed). Both are marked as having failed the self-test. Recently the need arose to allow the usage of certain algorithms only as arguments to specific template instantiations in FIPS mode. For example, standalone "dh" must be blocked, but e.g. "ffdhe2048(dh)" is allowed. Other potential use cases include "cbcmac(aes)", which must only be used with ccm(), or "ghash", which must be used only for gcm(). This patch allows this scenario by adding a new flag FIPS_INTERNAL to indicate those algorithms that are not FIPS-allowed. They can then be used as template arguments only, i.e. when looked up via crypto_grab_spawn() to be more specific. The FIPS_INTERNAL bit gets propagated upwards recursively into the surrounding template instances, until the construction eventually matches an explicit testmgr entry with ->fips_allowed being set, if any. The behaviour to skip !->fips_allowed self-test executions in FIPS mode will be retained. Note that this effectively means that FIPS_INTERNAL algorithms are handled very similarly to the INTERNAL ones in this regard. It is expected that the FIPS_INTERNAL algorithms will receive sufficient testing when the larger constructions they're a part of, if any, get exercised by testmgr. Note that as a side-effect of this patch algorithms which are not FIPS-allowed will now return ENOENT instead of ELIBBAD. Hopefully this is not an issue as some people were relying on this already. Link: https://lore.kernel.org/r/YeEVSaMEVJb3cQkq@gondor.apana.org.au Originally-by: Herbert Xu Signed-off-by: Nicolai Stange Reviewed-by: Hannes Reinecke Signed-off-by: Herbert Xu

crypto: tcrypt - remove all multibuffer ahash tests

2022-02-05T04:10:52+00:00

The multibuffer algorithms was removed already in 2018, so it is necessary to clear the test code left by tcrypt. Suggested-by: Herbert Xu Signed-off-by: Tianjia Zhang Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu