#
4cc2dcf9 |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - convert hash testing to use testvec_configs
Convert alg_test_hash() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self-tests a
crypto: testmgr - convert hash testing to use testvec_configs
Convert alg_test_hash() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self-tests are enabled, randomly generated testvec_configs are tested as well.
This improves hash test coverage mainly because now all algorithms have a variety of data layouts tested, whereas before each algorithm was responsible for declaring its own chunked test cases which were often missing or provided poor test coverage. The new code also tests both the MAY_SLEEP and !MAY_SLEEP cases and buffers that cross pages.
This already found bugs in the hash walk code and in the arm32 and arm64 implementations of crct10dif.
I removed the hash chunked test vectors that were the same as non-chunked ones, but left the ones that were unique.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
ed96804f |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - convert aead testing to use testvec_configs
Convert alg_test_aead() to use the new test framework, using the same list of testvec_configs that skcipher testing uses.
This signific
crypto: testmgr - convert aead testing to use testvec_configs
Convert alg_test_aead() to use the new test framework, using the same list of testvec_configs that skcipher testing uses.
This significantly improves AEAD test coverage mainly because previously there was only very limited test coverage of the possible data layouts. Now the data layouts to test are listed in one place for all algorithms and optionally are also randomly generated. In fact, only one AEAD algorithm (AES-GCM) even had a chunked test case before.
This already found bugs in all the AEGIS and MORUS implementations, the x86 AES-GCM implementation, and the arm64 AES-CCM implementation.
I removed the AEAD chunked test vectors that were the same as non-chunked ones, but left the ones that were unique.
Note: the rewritten test code allocates an aead_request just once per algorithm rather than once per encryption/decryption, but some AEAD algorithms incorrectly change the tfm pointer in the request. It's nontrivial to fix these, so to move forward I'm temporarily working around it by resetting the tfm pointer. But they'll need to be fixed.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
4e7babba |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - convert skcipher testing to use testvec_configs
Convert alg_test_skcipher() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self
crypto: testmgr - convert skcipher testing to use testvec_configs
Convert alg_test_skcipher() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self-tests are enabled, randomly generated testvec_configs are tested as well.
This improves skcipher test coverage mainly because now all algorithms have a variety of data layouts tested, whereas before each algorithm was responsible for declaring its own chunked test cases which were often missing or provided poor test coverage. The new code also tests both the MAY_SLEEP and !MAY_SLEEP cases, different IV alignments, and buffers that cross pages.
This has already found a bug in the arm64 ctr-aes-neonbs algorithm. It would have easily found many past bugs.
I removed the skcipher chunked test vectors that were the same as non-chunked ones, but left the ones that were unique.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
25f9dddb |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - implement random testvec_config generation
Add functions that generate a random testvec_config, in preparation for using it for randomized fuzz tests.
Signed-off-by: Eric Biggers
crypto: testmgr - implement random testvec_config generation
Add functions that generate a random testvec_config, in preparation for using it for randomized fuzz tests.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
5b2706a4 |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - introduce CONFIG_CRYPTO_MANAGER_EXTRA_TESTS
To achieve more comprehensive crypto test coverage, I'd like to add fuzz tests that use random data layouts and request flags.
To be mo
crypto: testmgr - introduce CONFIG_CRYPTO_MANAGER_EXTRA_TESTS
To achieve more comprehensive crypto test coverage, I'd like to add fuzz tests that use random data layouts and request flags.
To be most effective these tests should be part of testmgr, so they automatically run on every algorithm registered with the crypto API. However, they will take much longer to run than the current tests and therefore will only really be intended to be run by developers, whereas the current tests have a wider audience.
Therefore, add a new kconfig option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS that can be set by developers to enable these extra, expensive tests.
Similar to the regular tests, also add a module parameter cryptomgr.noextratests to support disabling the tests.
Finally, another module parameter cryptomgr.fuzz_iterations is added to control how many iterations the fuzz tests do. Note: for now setting this to 0 will be equivalent to cryptomgr.noextratests=1. But I opted for separate parameters to provide more flexibility to add other types of tests under the "extra tests" category in the future.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
3f47a03d |
| 01-Feb-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - add testvec_config struct and helper functions
Crypto algorithms must produce the same output for the same input regardless of data layout, i.e. how the src and dst scatterlists ar
crypto: testmgr - add testvec_config struct and helper functions
Crypto algorithms must produce the same output for the same input regardless of data layout, i.e. how the src and dst scatterlists are divided into chunks and how each chunk is aligned. Request flags such as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either.
However, testing of this currently has many gaps. For example, individual algorithms are responsible for providing their own chunked test vectors. But many don't bother to do this or test only one or two cases, providing poor test coverage. Also, other things such as misaligned IVs and CRYPTO_TFM_REQ_MAY_SLEEP are never tested at all.
Test code is also duplicated between the chunked and non-chunked cases, making it difficult to make other improvements.
To improve the situation, this patch series basically moves the chunk descriptions into the testmgr itself so that they are shared by all algorithms. However, it's done in an extensible way via a new struct 'testvec_config', which describes not just the scaled chunk lengths but also all other aspects of the crypto operation besides the data itself such as the buffer alignments, the request flags, whether the operation is in-place or not, the IV alignment, and for hash algorithms when to do each update() and when to use finup() vs. final() vs. digest().
Then, this patch series makes skcipher, aead, and hash algorithms be tested against a list of default testvec_configs, replacing the current test code. This improves overall test coverage, without reducing test performance too much. Note that the test vectors themselves are not changed, except for removing the chunk lists.
This series also adds randomized fuzz tests, enabled by a new kconfig option intended for developer use only, where skcipher, aead, and hash algorithms are tested against many randomly generated testvec_configs. This provides much more comprehensive test coverage.
These improved tests have already exposed many bugs.
To start it off, this initial patch adds the testvec_config and various helper functions that will be used by the skcipher, aead, and hash test code that will be converted to use the new testvec_config framework.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.19 |
|
#
e3d90e52 |
| 28-Jan-2019 |
Christopher Diaz Riveros <chrisadr@gentoo.org> |
crypto: testmgr - use kmemdup
Fixes coccinnelle alerts:
/crypto/testmgr.c:2112:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c:2130:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c
crypto: testmgr - use kmemdup
Fixes coccinnelle alerts:
/crypto/testmgr.c:2112:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c:2130:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c:2152:9-16: WARNING opportunity for kmemdup
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.18 |
|
#
a8a34416 |
| 25-Jan-2019 |
Milan Broz <gmazyland@gmail.com> |
crypto: testmgr - mark crc32 checksum as FIPS allowed
The CRC32 is not a cryptographic hash algorithm, so the FIPS restrictions should not apply to it. (The CRC32C variant is already allowed.)
This
crypto: testmgr - mark crc32 checksum as FIPS allowed
The CRC32 is not a cryptographic hash algorithm, so the FIPS restrictions should not apply to it. (The CRC32C variant is already allowed.)
This CRC32 variant is used for in dm-crypt legacy TrueCrypt IV implementation (tcw); detected by cryptsetup test suite failure in FIPS mode.
Signed-off-by: Milan Broz <gmazyland@gmail.com> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
eb5e6730 |
| 23-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - skip crc32c context test for ahash algorithms
Instantiating "cryptd(crc32c)" causes a crypto self-test failure because the crypto_alloc_shash() in alg_test_crc32c() fails. This is
crypto: testmgr - skip crc32c context test for ahash algorithms
Instantiating "cryptd(crc32c)" causes a crypto self-test failure because the crypto_alloc_shash() in alg_test_crc32c() fails. This is because cryptd(crc32c) is an ahash algorithm, not a shash algorithm; so it can only be accessed through the ahash API, unlike shash algorithms which can be accessed through both the ahash and shash APIs.
As the test is testing the shash descriptor format which is only applicable to shash algorithms, skip it for ahash algorithms.
(Note that it's still important to fix crypto self-test failures even for weird algorithm instantiations like cryptd(crc32c) that no one would really use; in fips_enabled mode unprivileged users can use them to panic the kernel, and also they prevent treating a crypto self-test failure as a bug when fuzzing the kernel.)
Fixes: 8e3ee85e68c5 ("crypto: crc32c - Test descriptor context format") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.17 |
|
#
231baecd |
| 19-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: clarify name of WEAK_KEY request flag
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak k
crypto: clarify name of WEAK_KEY request flag
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do).
Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.)
Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.16 |
|
#
a0d608ee |
| 13-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - unify the AEAD encryption and decryption test vectors
Currently testmgr has separate encryption and decryption test vectors for AEADs. That's massively redundant, since usually th
crypto: testmgr - unify the AEAD encryption and decryption test vectors
Currently testmgr has separate encryption and decryption test vectors for AEADs. That's massively redundant, since usually the decryption tests are identical to the encryption tests, just with the input/result swapped. And for some algorithms it was forgotten to add decryption test vectors, so for them currently only encryption is being tested.
Therefore, eliminate the redundancy by removing the AEAD decryption test vectors and updating testmgr to test both AEAD encryption and decryption using what used to be the encryption test vectors. Naming is adjusted accordingly: each aead_testvec now has a 'ptext' (plaintext), 'plen' (plaintext length), 'ctext' (ciphertext), and 'clen' (ciphertext length) instead of an 'input', 'ilen', 'result', and 'rlen'. "Ciphertext" here refers to the full ciphertext, including the authentication tag.
For now the scatterlist divisions are just given for the plaintext length, not also the ciphertext length. For decryption, the last scatterlist element is just extended by the authentication tag length.
In total, this removes over 5000 lines from testmgr.h, with no reduction in test coverage since prior patches already copied the few unique decryption test vectors into the encryption test vectors.
The testmgr.h portion of this patch was automatically generated using the following awk script, except that I also manually updated the definition of 'struct aead_testvec' and fixed the location of the comment describing the AEGIS-128 test vectors.
BEGIN { OTHER = 0; ENCVEC = 1; DECVEC = 2; DECVEC_TAIL = 3; mode = OTHER }
/^static const struct aead_testvec.*_enc_/ { sub("_enc", ""); mode = ENCVEC } /^static const struct aead_testvec.*_dec_/ { mode = DECVEC } mode == ENCVEC { sub(/\.input[[:space:]]*=/, ".ptext\t=") sub(/\.result[[:space:]]*=/, ".ctext\t=") sub(/\.ilen[[:space:]]*=/, ".plen\t=") sub(/\.rlen[[:space:]]*=/, ".clen\t=") print } mode == DECVEC_TAIL && /[^[:space:]]/ { mode = OTHER } mode == OTHER { print } mode == ENCVEC && /^};/ { mode = OTHER } mode == DECVEC && /^};/ { mode = DECVEC_TAIL }
Note that git's default diff algorithm gets confused by the testmgr.h portion of this patch, and reports too many lines added and removed. It's better viewed with 'git diff --minimal' (or 'git show --minimal'), which reports "2 files changed, 1235 insertions(+), 6491 deletions(-)".
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
5bc3de58 |
| 13-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - skip AEAD encryption test vectors with novrfy set
In preparation for unifying the AEAD encryption and decryption test vectors, skip AEAD test vectors with the 'novrfy' (verificatio
crypto: testmgr - skip AEAD encryption test vectors with novrfy set
In preparation for unifying the AEAD encryption and decryption test vectors, skip AEAD test vectors with the 'novrfy' (verification failure expected) flag set when testing encryption rather than decryption. These test vectors only make sense for decryption.
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.15 |
|
#
cb9dde88 |
| 10-Jan-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: testmgr - handle endianness correctly in alg_test_crc32c()
The crc32c context is in CPU endianness, whereas the final digest is little endian. alg_test_crc32c() got this mixed up. Fix it.
crypto: testmgr - handle endianness correctly in alg_test_crc32c()
The crc32c context is in CPU endianness, whereas the final digest is little endian. alg_test_crc32c() got this mixed up. Fix it.
The test passes both before and after, but this patch fixes the following sparse warning:
crypto/testmgr.c:1912:24: warning: cast to restricted __le32
Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.14 |
|
#
0507de94 |
| 07-Jan-2019 |
Vitaly Chikunov <vt@altlinux.org> |
crypto: testmgr - split akcipher tests by a key type
Before this, if akcipher_testvec have `public_key_vec' set to true (i.e. having a public key) only sign/encrypt test is performed, but verify/dec
crypto: testmgr - split akcipher tests by a key type
Before this, if akcipher_testvec have `public_key_vec' set to true (i.e. having a public key) only sign/encrypt test is performed, but verify/decrypt test is skipped.
With a public key we could do encrypt and verify, but to sign and decrypt a private key is required.
This logic is correct for encrypt/decrypt tests (decrypt is skipped if no private key). But incorrect for sign/verify tests - sign is performed no matter if there is no private key, but verify is skipped if there is a public key.
Rework `test_akcipher_one' to arrange tests properly depending on value of `public_key_vec` and `siggen_sigver_test'.
No tests were missed since there is only one sign/verify test (which have `siggen_sigver_test' set to true) and it has a private key, but future tests could benefit from this improvement.
Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3 |
|
#
059c2a4d |
| 16-Nov-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: adiantum - add Adiantum support
Add support for the Adiantum encryption mode. Adiantum was designed by Paul Crowley and is specified by our paper:
Adiantum: length-preserving encryptio
crypto: adiantum - add Adiantum support
Add support for the Adiantum encryption mode. Adiantum was designed by Paul Crowley and is specified by our paper:
Adiantum: length-preserving encryption for entry-level processors (https://eprint.iacr.org/2018/720.pdf)
See our paper for full details; this patch only provides an overview.
Adiantum is a tweakable, length-preserving encryption mode designed for fast and secure disk encryption, especially on CPUs without dedicated crypto instructions. Adiantum encrypts each sector using the XChaCha12 stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash function, and an invocation of the AES-256 block cipher on a single 16-byte block. On CPUs without AES instructions, Adiantum is much faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors Adiantum encryption is about 4 times faster than AES-256-XTS encryption, and decryption about 5 times faster.
Adiantum is a specialization of the more general HBSH construction. Our earlier proposal, HPolyC, was also a HBSH specialization, but it used a different εA∆U hash function, one based on Poly1305 only. Adiantum's εA∆U hash function, which is based primarily on the "NH" hash function like that used in UMAC (RFC4418), is about twice as fast as HPolyC's; consequently, Adiantum is about 20% faster than HPolyC.
This speed comes with no loss of security: Adiantum is provably just as secure as HPolyC, in fact slightly *more* secure. Like HPolyC, Adiantum's security is reducible to that of XChaCha12 and AES-256, subject to a security bound. XChaCha12 itself has a security reduction to ChaCha12. Therefore, one need not "trust" Adiantum; one need only trust ChaCha12 and AES-256. Note that the εA∆U hash function is only used for its proven combinatorical properties so cannot be "broken".
Adiantum is also a true wide-block encryption mode, so flipping any plaintext bit in the sector scrambles the entire ciphertext, and vice versa. No other such mode is available in the kernel currently; doing the same with XTS scrambles only 16 bytes. Adiantum also supports arbitrary-length tweaks and naturally supports any length input >= 16 bytes without needing "ciphertext stealing".
For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in order to make encryption feasible on the widest range of devices. Although the 20-round variant is quite popular, the best known attacks on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial security margin; in fact, larger than AES-256's. 12-round Salsa20 is also the eSTREAM recommendation. For the block cipher, Adiantum uses AES-256, despite it having a lower security margin than XChaCha12 and needing table lookups, due to AES's extensive adoption and analysis making it the obvious first choice. Nevertheless, for flexibility this patch also permits the "adiantum" template to be instantiated with XChaCha20 and/or with an alternate block cipher.
We need Adiantum support in the kernel for use in dm-crypt and fscrypt, where currently the only other suitable options are block cipher modes such as AES-XTS. A big problem with this is that many low-end mobile devices (e.g. Android Go phones sold primarily in developing countries, as well as some smartwatches) still have CPUs that lack AES instructions, e.g. ARM Cortex-A7. Sadly, AES-XTS encryption is much too slow to be viable on these devices. We did find that some "lightweight" block ciphers are fast enough, but these suffer from problems such as not having much cryptanalysis or being too controversial.
The ChaCha stream cipher has excellent performance but is insecure to use directly for disk encryption, since each sector's IV is reused each time it is overwritten. Even restricting the threat model to offline attacks only isn't enough, since modern flash storage devices don't guarantee that "overwrites" are really overwrites, due to wear-leveling. Adiantum avoids this problem by constructing a "tweakable super-pseudorandom permutation"; this is the strongest possible security model for length-preserving encryption.
Of course, storing random nonces along with the ciphertext would be the ideal solution. But doing that with existing hardware and filesystems runs into major practical problems; in most cases it would require data journaling (like dm-integrity) which severely degrades performance. Thus, for now length-preserving encryption is still needed.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
26609a21 |
| 16-Nov-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: nhpoly1305 - add NHPoly1305 support
Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash function used in the Adiantum encryption mode.
CONFIG_NHPOLY1305 is not selectab
crypto: nhpoly1305 - add NHPoly1305 support
Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash function used in the Adiantum encryption mode.
CONFIG_NHPOLY1305 is not selectable by itself since there won't be any real reason to enable it without also enabling Adiantum support.
Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
aa762409 |
| 16-Nov-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: chacha - add XChaCha12 support
Now that the generic implementation of ChaCha20 has been refactored to allow varying the number of rounds, add support for XChaCha12, which is the XSalsa const
crypto: chacha - add XChaCha12 support
Now that the generic implementation of ChaCha20 has been refactored to allow varying the number of rounds, add support for XChaCha12, which is the XSalsa construction applied to ChaCha12. ChaCha12 is one of the three ciphers specified by the original ChaCha paper (https://cr.yp.to/chacha/chacha-20080128.pdf: "ChaCha, a variant of Salsa20"), alongside ChaCha8 and ChaCha20. ChaCha12 is faster than ChaCha20 but has a lower, but still large, security margin.
We need XChaCha12 support so that it can be used in the Adiantum encryption mode, which enables disk/file encryption on low-end mobile devices where AES-XTS is too slow as the CPUs lack AES instructions.
We'd prefer XChaCha20 (the more popular variant), but it's too slow on some of our target devices, so at least in some cases we do need the XChaCha12-based version. In more detail, the problem is that Adiantum is still much slower than we're happy with, and encryption still has a quite noticeable effect on the feel of low-end devices. Users and vendors push back hard against encryption that degrades the user experience, which always risks encryption being disabled entirely. So we need to choose the fastest option that gives us a solid margin of security, and here that's XChaCha12. The best known attack on ChaCha breaks only 7 rounds and has 2^235 time complexity, so ChaCha12's security margin is still better than AES-256's. Much has been learned about cryptanalysis of ARX ciphers since Salsa20 was originally designed in 2005, and it now seems we can be comfortable with a smaller number of rounds. The eSTREAM project also suggests the 12-round version of Salsa20 as providing the best balance among the different variants: combining very good performance with a "comfortable margin of security".
Note that it would be trivial to add vanilla ChaCha12 in addition to XChaCha12. However, it's unneeded for now and therefore is omitted.
As discussed in the patch that introduced XChaCha20 support, I considered splitting the code into separate chacha-common, chacha20, xchacha20, and xchacha12 modules, so that these algorithms could be enabled/disabled independently. However, since nearly all the code is shared anyway, I ultimately decided there would have been little benefit to the added complexity.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Martin Willi <martin@strongswan.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
de61d7ae |
| 16-Nov-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: chacha20-generic - add XChaCha20 support
Add support for the XChaCha20 stream cipher. XChaCha20 is the application of the XSalsa20 construction (https://cr.yp.to/snuffle/xsalsa-20081128.pdf
crypto: chacha20-generic - add XChaCha20 support
Add support for the XChaCha20 stream cipher. XChaCha20 is the application of the XSalsa20 construction (https://cr.yp.to/snuffle/xsalsa-20081128.pdf) to ChaCha20 rather than to Salsa20. XChaCha20 extends ChaCha20's nonce length from 64 bits (or 96 bits, depending on convention) to 192 bits, while provably retaining ChaCha20's security. XChaCha20 uses the ChaCha20 permutation to map the key and first 128 nonce bits to a 256-bit subkey. Then, it does the ChaCha20 stream cipher with the subkey and remaining 64 bits of nonce.
We need XChaCha support in order to add support for the Adiantum encryption mode. Note that to meet our performance requirements, we actually plan to primarily use the variant XChaCha12. But we believe it's wise to first add XChaCha20 as a baseline with a higher security margin, in case there are any situations where it can be used. Supporting both variants is straightforward.
Since XChaCha20's subkey differs for each request, XChaCha20 can't be a template that wraps ChaCha20; that would require re-keying the underlying ChaCha20 for every request, which wouldn't be thread-safe. Instead, we make XChaCha20 its own top-level algorithm which calls the ChaCha20 streaming implementation internally.
Similar to the existing ChaCha20 implementation, we define the IV to be the nonce and stream position concatenated together. This allows users to seek to any position in the stream.
I considered splitting the code into separate chacha20-common, chacha20, and xchacha20 modules, so that chacha20 and xchacha20 could be enabled/disabled independently. However, since nearly all the code is shared anyway, I ultimately decided there would have been little benefit to the added complexity of separate modules.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Martin Willi <martin@strongswan.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.19, v4.19.2, v4.18.18 |
|
#
25a0b9d4 |
| 06-Nov-2018 |
Vitaly Chikunov <vt@altlinux.org> |
crypto: streebog - add Streebog test vectors
Add testmgr and tcrypt tests and vectors for Streebog hash function from RFC 6986 and GOST R 34.11-2012, for HMAC-Streebog vectors are from RFC 7836 and
crypto: streebog - add Streebog test vectors
Add testmgr and tcrypt tests and vectors for Streebog hash function from RFC 6986 and GOST R 34.11-2012, for HMAC-Streebog vectors are from RFC 7836 and R 50.1.113-2016.
Cc: linux-integrity@vger.kernel.org Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.17, v4.19.1 |
|
#
196ad604 |
| 04-Nov-2018 |
Gilad Ben-Yossef <gilad@benyossef.com> |
crypto: testmgr - mark cts(cbc(aes)) as FIPS allowed
As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is allowed as a FIPS mode algorithm. Mark it as such.
[1] https://csrc.nist.gov/public
crypto: testmgr - mark cts(cbc(aes)) as FIPS allowed
As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is allowed as a FIPS mode algorithm. Mark it as such.
[1] https://csrc.nist.gov/publications/detail/sp/800-38a/addendum/final
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.19, v4.18.16 |
|
#
7da66670 |
| 19-Oct-2018 |
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> |
crypto: testmgr - add AES-CFB tests
Add AES128/192/256-CFB testvectors from NIST SP800-38A.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: D
crypto: testmgr - add AES-CFB tests
Add AES128/192/256-CFB testvectors from NIST SP800-38A.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.15, v4.18.14, v4.18.13 |
|
#
22a8118d |
| 07-Oct-2018 |
Michael Schupikov <michael@schupikov.de> |
crypto: testmgr - fix sizeof() on COMP_BUF_SIZE
After allocation, output and decomp_output both point to memory chunks of size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using sizeof(C
crypto: testmgr - fix sizeof() on COMP_BUF_SIZE
After allocation, output and decomp_output both point to memory chunks of size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using sizeof(COMP_BUF_SIZE) as parameter to memset(), because sizeof(COMP_BUF_SIZE) provides the size of the constant and not the size of allocated memory.
Instead, the whole allocated memory is meant to be zeroed out. Use COMP_BUF_SIZE as parameter to memset() directly in order to accomplish this.
Fixes: 336073840a872 ("crypto: testmgr - Allow different compression results")
Signed-off-by: Michael Schupikov <michael@schupikov.de> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.12, v4.18.11, v4.18.10 |
|
#
95ba5973 |
| 20-Sep-2018 |
Gilad Ben-Yossef <gilad@benyossef.com> |
crypto: testmgr - update sm4 test vectors
Add additional test vectors from "The SM4 Blockcipher Algorithm And Its Modes Of Operations" draft-ribose-cfrg-sm4-10 and register cipher speed tests for sm
crypto: testmgr - update sm4 test vectors
Add additional test vectors from "The SM4 Blockcipher Algorithm And Its Modes Of Operations" draft-ribose-cfrg-sm4-10 and register cipher speed tests for sm4.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14 |
|
#
578bdaab |
| 07-Aug-2018 |
Jason A. Donenfeld <Jason@zx2c4.com> |
crypto: speck - remove Speck
These are unused, undesired, and have never actually been used by anybody. The original authors of this code have changed their mind about its inclusion. While originall
crypto: speck - remove Speck
These are unused, undesired, and have never actually been used by anybody. The original authors of this code have changed their mind about its inclusion. While originally proposed for disk encryption on low-end devices, the idea was discarded [1] in favor of something else before that could really get going. Therefore, this patch removes Speck.
[1] https://marc.info/?l=linux-crypto-vger&m=153359499015659
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4 |
|
#
76715095 |
| 01-Jul-2018 |
Gilad Ben-Yossef <gilad@benyossef.com> |
crypto: testmgr - add hash finup tests
The testmgr hash tests were testing init, digest, update and final methods but not the finup method. Add a test for this one too.
While doing this, make sure
crypto: testmgr - add hash finup tests
The testmgr hash tests were testing init, digest, update and final methods but not the finup method. Add a test for this one too.
While doing this, make sure we only run the partial tests once with the digest tests and skip them with the final and finup tests since they are the same.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|