#
46b3ff73 |
| 31-May-2024 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: sm2 - Remove sm2 algorithm
The SM2 algorithm has a single user in the kernel. However, it's never been integrated properly with that user: asymmetric_keys.
The crux of the issue is that th
crypto: sm2 - Remove sm2 algorithm
The SM2 algorithm has a single user in the kernel. However, it's never been integrated properly with that user: asymmetric_keys.
The crux of the issue is that the way it computes its digest with sm3 does not fit into the architecture of asymmetric_keys. As no solution has been proposed, remove this algorithm.
It can be resubmitted when it is integrated properly into the asymmetric_keys subsystem.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
a7d45ba7 |
| 04-Apr-2024 |
Stefan Berger <stefanb@linux.ibm.com> |
crypto: ecdsa - Register NIST P521 and extend test suite
Register NIST P521 as an akcipher and extend the testmgr with NIST P521-specific test vectors.
Add a module alias so the module gets automat
crypto: ecdsa - Register NIST P521 and extend test suite
Register NIST P521 as an akcipher and extend the testmgr with NIST P521-specific test vectors.
Add a module alias so the module gets automatically loaded by the crypto subsystem when the curve is needed.
Tested-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
203a6763 |
| 13-Mar-2024 |
Eric Biggers <ebiggers@google.com> |
Revert "crypto: pkcs7 - remove sha1 support"
This reverts commit 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and appar
Revert "crypto: pkcs7 - remove sha1 support"
This reverts commit 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.
It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.
Reported-by: Karel Balej <balejk@matfyz.cz> Closes: https://lore.kernel.org/r/CZSHRUIJ4RKL.34T4EASV5DNJM@matfyz.cz Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Tested-by: Karel Balej <balejk@matfyz.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
d4bd2102 |
| 30-Nov-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: testmgr - Remove cfb and ofb Remove test vectors for CFB/OFB.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
16ab7cb5 |
| 10-Oct-2023 |
Dimitri John Ledkov <dimitri.ledkov@canonical.com> |
crypto: pkcs7 - remove sha1 support
Removes support for sha1 signed kernel modules, importing sha1 signed x.509 certificates.
rsa-pkcs1pad keeps sha1 padding support, which seems to be used by virt
crypto: pkcs7 - remove sha1 support
Removes support for sha1 signed kernel modules, importing sha1 signed x.509 certificates.
rsa-pkcs1pad keeps sha1 padding support, which seems to be used by virtio driver.
sha1 remains available as there are many drivers and subsystems using it. Note only hmac(sha1) with secret keys remains cryptographically secure.
In the kernel there are filesystems, IMA, tpm/pcr that appear to be using sha1. Maybe they can all start to be slowly upgraded to something else i.e. blake3, ParallelHash, SHAKE256 as needed.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
30febae7 |
| 30-Aug-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: testmgr - Remove zlib-deflate
Remove zlib-deflate test vectors as it no longer exists in the kernel.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Ard Biesheuvel <ard
crypto: testmgr - Remove zlib-deflate
Remove zlib-deflate test vectors as it no longer exists in the kernel.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
ba24b8eb |
| 13-Apr-2023 |
David Howells <dhowells@redhat.com> |
crypto: testmgr - Add some test vectors for cmac(camellia)
Add some test vectors for 128-bit cmac(camellia) as found in draft-kato-ipsec-camellia-cmac96and128-01 section 6.2.
The document also show
crypto: testmgr - Add some test vectors for cmac(camellia)
Add some test vectors for 128-bit cmac(camellia) as found in draft-kato-ipsec-camellia-cmac96and128-01 section 6.2.
The document also shows vectors for camellia-cmac-96, and for VK with a length greater than 16, but I'm not sure how to express those in testmgr.
This also leaves cts(cbc(camellia)) untested, but I can't seem to find any tests for that that I could put into testmgr.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Chuck Lever <chuck.lever@oracle.com> cc: Scott Mayhew <smayhew@redhat.com> cc: linux-nfs@vger.kernel.org cc: linux-crypto@vger.kernel.org Link: https://datatracker.ietf.org/doc/pdf/draft-kato-ipsec-camellia-cmac96and128-01 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
c24ee936 |
| 27-Oct-2022 |
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> |
crypto: testmgr - add SM4 cts-cbc/xts/xcbc test vectors
This patch newly adds the test vectors of CTS-CBC/XTS/XCBC modes of the SM4 algorithm, and also added some test vectors for SM4 GCM/CCM.
Sign
crypto: testmgr - add SM4 cts-cbc/xts/xcbc test vectors
This patch newly adds the test vectors of CTS-CBC/XTS/XCBC modes of the SM4 algorithm, and also added some test vectors for SM4 GCM/CCM.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
9d2bb9a7 |
| 17-Jul-2022 |
Ignat Korchagin <ignat@cloudflare.com> |
crypto: testmgr - some more fixes to RSA test vectors
Two more fixes:
* some test vectors in commit 79e6e2f3f3ff ("crypto: testmgr - populate RSA CRT parameters in RSA test vectors") had misp
crypto: testmgr - some more fixes to RSA test vectors
Two more fixes:
* some test vectors in commit 79e6e2f3f3ff ("crypto: testmgr - populate RSA CRT parameters in RSA test vectors") had misplaced commas, which break the test and trigger KASAN warnings at least on x86-64
* pkcs1pad test vector did not have its CRT parameters
Fixes: 79e6e2f3f3ff ("crypto: testmgr - populate RSA CRT parameters in RSA test vectors") Reported-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
01ce31de |
| 04-Jul-2022 |
Taehee Yoo <ap420073@gmail.com> |
crypto: testmgr - add ARIA testmgr tests
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[
crypto: testmgr - add ARIA testmgr tests
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 <ap420073@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
79e6e2f3 |
| 04-Jul-2022 |
Ignat Korchagin <ignat@cloudflare.com> |
crypto: testmgr - populate RSA CRT parameters in RSA test vectors
Changes from v1: * replace some accidental spaces with tabs
In commit f145d411a67e ("crypto: rsa - implement Chinese Remainder Th
crypto: testmgr - populate RSA CRT parameters in RSA test vectors
Changes from v1: * replace some accidental spaces with tabs
In commit f145d411a67e ("crypto: rsa - implement Chinese Remainder Theorem for faster private key operations") we have started to use the additional primes and coefficients for RSA private key operations. However, these additional parameters are not present (defined as 0 integers) in the RSA test vectors.
Some parameters were borrowed from OpenSSL, so I was able to find the source. I could not find the public source for 1 vector though, so had to recover the parameters by implementing Appendix C from [1].
[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br1.pdf
Fixes: f145d411a67e ("crypto: rsa - implement Chinese Remainder Theorem for faster private key operations") Reported-by: Tasmiya Nalatwad <tasmiya@linux.vnet.ibm.com> Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
0bb8f125 |
| 24-Jun-2022 |
lei he <helei.sig11@bytedance.com> |
crypto: testmgr - fix version number of RSA tests
According to PKCS#1 standard, the 'otherPrimeInfos' field contains the information for the additional primes r_3, ..., r_u, in order. It shall be om
crypto: testmgr - fix version number of RSA tests
According to PKCS#1 standard, the 'otherPrimeInfos' field contains the information for the additional primes r_3, ..., r_u, in order. It shall be omitted if the version is 0 and shall contain at least one instance of OtherPrimeInfo if the version is 1, see: https://www.rfc-editor.org/rfc/rfc3447#page-44
Replace the version number '1' with 0, otherwise, some drivers may not pass the run-time tests.
Signed-off-by: lei he <helei.sig11@bytedance.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
2d16803c |
| 28-May-2022 |
Jason A. Donenfeld <Jason@zx2c4.com> |
crypto: blake2s - remove shash module
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 wer
crypto: blake2s - remove shash module
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 <gaochao49@huawei.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
7ff554ce |
| 20-May-2022 |
Nathan Huckleberry <nhuck@google.com> |
crypto: hctr2 - Add HCTR2 support
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
crypto: hctr2 - Add HCTR2 support
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 <nhuck@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
f3c923a0 |
| 20-May-2022 |
Nathan Huckleberry <nhuck@google.com> |
crypto: polyval - Add POLYVAL support
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 no
crypto: polyval - Add POLYVAL support
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 <nhuck@google.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
17fee07a |
| 20-May-2022 |
Nathan Huckleberry <nhuck@google.com> |
crypto: xctr - Add XCTR support
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-e
crypto: xctr - Add XCTR support
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 <nhuck@google.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
1e212706 |
| 22-Mar-2022 |
Keith Busch <kbusch@kernel.org> |
crypto: fix crc64 testmgr digest byte order
The result is set in little endian, so the expected digest needs to be consistent for big endian machines.
Fixes: f3813f4b287e ("crypto: add rocksoft 64b
crypto: fix crc64 testmgr digest byte order
The result is set in little endian, so the expected digest needs to be consistent for big endian machines.
Fixes: f3813f4b287e ("crypto: add rocksoft 64b crc guard tag framework") Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/20220322142107.4581-1-kbusch@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
f3813f4b |
| 03-Mar-2022 |
Keith Busch <kbusch@kernel.org> |
crypto: add rocksoft 64b crc guard tag framework
Hardware specific features may be able to calculate a crc64, so provide a framework for drivers to register their implementation. If nothing is regis
crypto: add rocksoft 64b crc guard tag framework
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 <kbusch@kernel.org> Link: https://lore.kernel.org/r/20220303201312.3255347-7-kbusch@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
209b7fc9 |
| 21-Feb-2022 |
Nicolai Stange <nstange@suse.de> |
crypto: testmgr - add keygen tests for ffdheXYZ(dh) templates
Now that the ffdheXYZ(dh) templates support ephemeral key generation, add ->keygen = 1 TVs for each of them to the testmgr.c.
In order
crypto: testmgr - add keygen tests for ffdheXYZ(dh) templates
Now that the ffdheXYZ(dh) templates support ephemeral key generation, add ->keygen = 1 TVs for each of them to the testmgr.c.
In order to facilitate string merging by the compiler, set party B's secret and public keys to the ones specified for party A in the respective existing known answer test. With GCC 7.5 on x86_64, this leads to an increase of testmgr.o size by less than half a kB.
Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
60a273e9 |
| 21-Feb-2022 |
Nicolai Stange <nstange@suse.de> |
crypto: testmgr - add known answer tests for ffdheXYZ(dh) templates
Add known answer tests for the ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh) templates introduced w
crypto: testmgr - add known answer tests for ffdheXYZ(dh) templates
Add known answer tests for the ffdhe2048(dh), ffdhe3072(dh), ffdhe4096(dh), ffdhe6144(dh) and ffdhe8192(dh) templates introduced with the previous patch to the testmgr. All TVs have been generated with OpenSSL.
Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
48c6d8b8 |
| 21-Feb-2022 |
Nicolai Stange <nstange@suse.de> |
crypto: dh - remove struct dh's ->q member
The only current user of the DH KPP algorithm, the keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q in struct dh. Remove it and any
crypto: dh - remove struct dh's ->q member
The only current user of the DH KPP algorithm, the keyctl(KEYCTL_DH_COMPUTE) syscall, doesn't set the domain parameter ->q in struct dh. Remove it and any associated (de)serialization code in crypto_dh_encode_key() and crypto_dh_decode_key. Adjust the encoded ->secret values in testmgr's DH test vectors accordingly.
Note that the dh-generic implementation would have initialized its struct dh_ctx's ->q from the decoded struct dh's ->q, if present. If this struct dh_ctx's ->q would ever have been non-NULL, it would have enabled a full key validation as specified in NIST SP800-56A in dh_is_pubkey_valid(). However, as outlined above, ->q is always NULL in practice and the full key validation code is effectively dead. A later patch will make dh_is_pubkey_valid() to calculate Q from P on the fly, if possible, so don't remove struct dh_ctx's ->q now, but leave it there until that has happened.
Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
37f36e57 |
| 01-Feb-2022 |
Stephan Müller <smueller@chronox.de> |
crypto: hmac - disallow keys < 112 bits in FIPS mode
FIPS 140 requires a minimum security strength of 112 bits. This implies that the HMAC key must not be smaller than 112 in FIPS mode.
This restri
crypto: hmac - disallow keys < 112 bits in FIPS mode
FIPS 140 requires a minimum security strength of 112 bits. This implies that the HMAC key must not be smaller than 112 in FIPS mode.
This restriction implies that the test vectors for HMAC that have a key that is smaller than 112 bits must be disabled when FIPS support is compiled.
Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
c9c28ed0 |
| 01-Feb-2022 |
Stephan Müller <smueller@chronox.de> |
crypto: hmac - add fips_skip support
By adding the support for the flag fips_skip, hash / HMAC test vectors may be marked to be not applicable in FIPS mode. Such vectors are silently skipped in FIPS
crypto: hmac - add fips_skip support
By adding the support for the flag fips_skip, hash / HMAC test vectors may be marked to be not applicable in FIPS mode. Such vectors are silently skipped in FIPS mode.
Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
a9887010 |
| 05-Nov-2021 |
Lei He <helei.sig11@bytedance.com> |
crypto: testmgr - Fix wrong test case of RSA
According to the BER encoding rules, integer value should be encoded as two's complement, and if the highest bit of a positive integer is 1, should add a
crypto: testmgr - Fix wrong test case of RSA
According to the BER encoding rules, integer value should be encoded as two's complement, and if the highest bit of a positive integer is 1, should add a leading zero-octet.
The kernel's built-in RSA algorithm cannot recognize negative numbers when parsing keys, so it can pass this test case.
Export the key to file and run the following command to verify the fix result:
openssl asn1parse -inform DER -in /path/to/key/file
Signed-off-by: Lei He <helei.sig11@bytedance.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
39ef0851 |
| 22-Oct-2021 |
Lei He <helei.sig11@bytedance.com> |
crypto: testmgr - fix wrong key length for pkcs1pad
Fix wrong test data at testmgr.h, it seems to be caused by ignoring the last '\0' when calling sizeof.
Signed-off-by: Lei He <helei.sig11@bytedan
crypto: testmgr - fix wrong key length for pkcs1pad
Fix wrong test data at testmgr.h, it seems to be caused by ignoring the last '\0' when calling sizeof.
Signed-off-by: Lei He <helei.sig11@bytedance.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|