[PATCH 3/6] crypto: crc32-generic - remove __crc32_le()

From: Eric Biggers The __crc32_le() wrapper function is pointless. Just call crc32_le() directly instead. Signed-off-by: Eric Biggers --- crypto/crc32_generic.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH 2/6] crypto: crc32c-generic - remove cra_alignmask

From: Eric Biggers 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

[PATCH 6/6] crypto: testmgr - add more unkeyed crc32 and crc32c test vectors

From: Eric Biggers 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

[PATCH 1/6] crypto: crc32-generic - use unaligned access macros when needed

From: Eric Biggers 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

[PATCH 0/6] crypto: crc32 cleanups and unkeyed tests

This series fixes up alignment for crc32-generic and crc32c-generic, removes test vectors for bfin_crc that are no longer needed, and adds unkeyed test vectors for crc32 and an extra unkeyed test vector for crc32c. Adding the unkeyed test vectors also required a testmgr change to allow a single

[PATCH 4/6] crypto: testmgr - remove bfin_crc "hmac(crc32)" test vectors

From: Eric Biggers The Blackfin CRC driver was removed by commit 9678a8dc53c1 ("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

[PATCH 5/6] crypto: testmgr - fix testing OPTIONAL_KEY hash algorithms

From: Eric Biggers 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

Re: [PATCH 3/3] crypto: x86 - Add optimized AEGIS implementations

Hi Ondrej, On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > 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

[PATCH v2][RESEND] X.509: unpack RSA signatureValue field from BIT STRING

The signatureValue field of a X.509 certificate is encoded as a BIT STRING. For RSA signatures this BIT STRING is of so-called primitive subtype, which contains a u8 prefix indicating a count of unused bits in the encoding. We have to strip this prefix from signature data, just as we already do