- 26 May, 2018 18 commits
-
-
Eric Biggers authored
crc32c has an unkeyed test vector but crc32 did not. Add the crc32c one (which uses an empty input) to crc32 too, and also add a new one to both that uses a nonempty input. These test vectors verify that crc32 and crc32c implementations use the correct default initial state. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
Since testmgr uses a single tfm for all tests of each hash algorithm, once a key is set the tfm won't be unkeyed anymore. But with crc32 and crc32c, the key is really the "default initial state" and is optional; those algorithms should have both keyed and unkeyed test vectors, to verify that implementations use the correct default key. Simply listing the unkeyed test vectors first isn't guaranteed to work yet because testmgr makes multiple passes through the test vectors. crc32c does have an unkeyed test vector listed first currently, but it only works by chance because the last crc32c test vector happens to use a key that is the same as the default key. Therefore, teach testmgr to split hash test vectors into unkeyed and keyed sections, and do all the unkeyed ones before the keyed ones. Signed-off-by:
-
Eric Biggers authored
The Blackfin CRC driver was removed by commit 9678a8dc ("crypto: bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove the corresponding "hmac(crc32)" test vectors. I see no point in keeping them since nothing else appears to implement or use "hmac(crc32)", which isn't an algorithm that makes sense anyway because HMAC is meant to be used with a cryptographically secure hash function, which CRC's are not. Thus, remove the unneeded test vectors. Signed-off-by:
-
Eric Biggers authored
The __crc32_le() wrapper function is pointless. Just call crc32_le() directly instead. Signed-off-by:
-
Eric Biggers authored
crc32c-generic sets an alignmask, but actually its ->update() works with any alignment; only its ->setkey() and outputting the final digest assume an alignment. To prevent the buffer from having to be aligned by the crypto API for just these cases, switch these cases over to the unaligned access macros and remove the cra_alignmask. Note that this also makes crc32c-generic more consistent with crc32-generic. Signed-off-by:
-
Eric Biggers authored
crc32-generic doesn't have a cra_alignmask set, which is desired as its ->update() works with any alignment. However, it incorrectly assumes 4-byte alignment in ->setkey() and when outputting the final digest. Fix this by using the unaligned access macros in those cases. Signed-off-by:
-
Wenwen Wang authored
In do_chtls_setsockopt(), the tls crypto info is first copied from the poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the 'version' of the crypto info is checked. If the version is not as expected, i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that the provided crypto info is not supported yet. Then, the 'cipher_type' field of the 'tmp_crypto_info' is also checked to see if it is TLS_CIPHER_AES_GCM_128. If it is, the whole struct of tls12_crypto_info_aes_gcm_128 is copied from the pointer 'optval' and then the function chtls_setkey() is invoked to set the key. Given that the 'optval' pointer resides in userspace, a malicious userspace process can race to change the data pointed by 'optval' between the two copies. For example, a user can provide a crypto info with TLS_1_2_VERSION and TLS_CIPHER_AES_GCM_128. After the first copy, the user can modify the 'version' and the 'cipher_type' fields to any versions and/or cipher types that are not allowed. This way, the user can bypass the checks, inject bad data to the kernel, cause chtls_setkey() to set a wrong key or other issues. This patch reuses the data copied in the first try so as to ensure these checks will not be bypassed. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
Antoine Tenart authored
This patch adds the authenc(hmac(sha1),cbc(aes)) AEAD algorithm support to the Inside Secure SafeXcel driver. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Antoine Tenart authored
This patch adds the authenc(hmac(sha224),cbc(aes)) AEAD algorithm support to the Inside Secure SafeXcel driver. Signed-off-by:
-
Antoine Tenart authored
This patch adds support for the first AEAD algorithm in the Inside Secure SafeXcel driver, authenc(hmac(sha256),cbc(aes)). As this is the first AEAD algorithm added to this driver, common AEAD functions are added as well. Signed-off-by:
-
Antoine Tenart authored
This patch improves the error reporting from the Inside Secure driver to the upper layers and crypto consumers. All errors reported by the engine aren't fatal, and some may be genuine. Signed-off-by:
-
Antoine Tenart authored
This commit fixes the CONTEXT_CONTROL_TYPE_HASH_ENCRYPT_OUT and CONTEXT_CONTROL_TYPE_HASH_DECRYPT_OUT types by assigning the right value, and by renaming CONTEXT_CONTROL_TYPE_HASH_DECRYPT_OUT to CONTEXT_CONTROL_TYPE_HASH_DECRYPT_IN. This is not submitted as a fix for older kernel versions as these two defines weren't used back then. Signed-off-by:
-
Antoine Tenart authored
This patches makes the key and context size computation dynamic when using memzero_explicit() on these two arrays. This is safer, cleaner and will help future modifications of the driver when these two parameters sizes will changes (the context size will be bigger when using AEAD algorithms). Signed-off-by:
-
Antoine Tenart authored
This patch makes the context control size computation dynamic, not to rely on hardcoded values. This is better for the future, and will help adding the AEAD support. Signed-off-by:
-
Antoine Tenart authored
This patches reworks the way the algorithm type is set in the context, by using the fact that the decryption algorithms are just a combination of the algorithm encryption type and CONTEXT_CONTROL_TYPE_NULL_IN. This will help having simpler code when adding the AEAD support, to avoid ending up with an endless switch case block. Signed-off-by:
-
Antoine Tenart authored
This patch reworks the Inside Secure cipher functions, to remove all skcipher specific information and structure from all functions generic enough to be shared between skcipher and aead algorithms. This is a cosmetic only patch. Signed-off-by:
-
Antoine Tenart authored
This patch removes the use of VLAs to allocate requests on the stack, by removing both SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. As we still need to allocate requests on the stack to ease the creation of invalidation requests a new, non-VLA, definition is used: EIP197_REQUEST_ON_STACK. Signed-off-by:
-
Atul Gupta authored
removed redundant check and made TLS PDU and header recv handling common as received from HW. Ensure that only tls header is read in cpl_rx_tls_cmp read-ahead and skb is freed when entire data is processed. Signed-off-by:
Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
Harsh Jain <harsh@chelsio.com> Signed-off-by:
-
- 18 May, 2018 11 commits
-
-
Ondrej Mosnacek authored
This patch adds optimized implementations of MORUS-640 and MORUS-1280, utilizing the SSE2 and AVX2 x86 extensions. For MORUS-1280 (which operates on 256-bit blocks) we provide both AVX2 and SSE2 implementation. Although SSE2 MORUS-1280 is slower than AVX2 MORUS-1280, it is comparable in speed to the SSE2 MORUS-640. Signed-off-by:
Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by:
-
Ondrej Mosnacek authored
This patch adds a common glue code for optimized implementations of MORUS AEAD algorithms. Signed-off-by:
-
Ondrej Mosnacek authored
This patch adds test vectors for MORUS-640 and MORUS-1280. The test vectors were generated using the reference implementation from SUPERCOP (see code comments for more details). Signed-off-by:
-
Ondrej Mosnacek authored
This patch adds the generic implementation of the MORUS family of AEAD algorithms (MORUS-640 and MORUS-1280). The original authors of MORUS are Hongjun Wu and Tao Huang. At the time of writing, MORUS is one of the finalists in CAESAR, an open competition intended to select a portfolio of alternatives to the problematic AES-GCM: https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/round3/morusv2.pdfSigned-off-by:
-
Ondrej Mosnacek authored
This patch adds optimized implementations of AEGIS-128, AEGIS-128L, and AEGIS-256, utilizing the AES-NI and SSE2 x86 extensions. Signed-off-by:
-
Ondrej Mosnacek authored
This patch adds test vectors for the AEGIS family of AEAD algorithms (AEGIS-128, AEGIS-128L, and AEGIS-256). The test vectors were generated using the reference implementation from SUPERCOP (see code comments for more details). Signed-off-by:
-
Ondrej Mosnacek authored
This patch adds the generic implementation of the AEGIS family of AEAD algorithms (AEGIS-128, AEGIS-128L, and AEGIS-256). The original authors of AEGIS are Hongjun Wu and Bart Preneel. At the time of writing, AEGIS is one of the finalists in CAESAR, an open competition intended to select a portfolio of alternatives to the problematic AES-GCM: https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/round3/aegisv11.pdfSigned-off-by:
-
Gilad Ben-Yossef authored
Due to a snafu "paes" testmgr tests were not ordered lexicographically, which led to boot time warnings. Reorder the tests as needed. Fixes: a794d8d8 ("crypto: ccree - enable support for hardware keys") Reported-by:
Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Tested-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Atul Gupta authored
-Tx request and data is copied to HW Q in 64B desc, check for end of queue and adjust the current position to start from beginning before passing the additional request info. -key context copy should check key length only -Few reverse christmas tree correction Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in CSB_ERR error message text Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in dev_err error message Signed-off-by:
-
- 11 May, 2018 11 commits
-
-
Michael Ellerman authored
In p8_aes_xts_init() we do a printk(KERN_INFO ...) to report the fallback implementation we're using. However with a slow console this can significantly affect the speed of crypto operations. So remove it. Fixes: c07f5d3d ("crypto: vmx - Adding support for XTS") Cc: stable@vger.kernel.org # v4.8+ Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Michael Ellerman authored
In the vmx AES init routines we do a printk(KERN_INFO ...) to report the fallback implementation we're using. However with a slow console this can significantly affect the speed of crypto operations. Using 'cryptsetup benchmark' the removal of the printk() leads to a ~5x speedup for aes-cbc decryption. So remove them. Fixes: 8676590a ("crypto: vmx - Adding AES routines for VMX module") Fixes: 8c755ace ("crypto: vmx - Adding CBC routines for VMX module") Fixes: 4f7f60d3 ("crypto: vmx - Adding CTR routines for VMX module") Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
Ard Biesheuvel authored
Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by:
-
