user/sven/linux.git/crypto/tcrypt.h, branch tmp/leds/core

crypto: cryptomgr - Add test infrastructure

2008-08-29T05:49:55Z

This patch moves the newly created alg_test infrastructure into cryptomgr. This shall allow us to use it for testing at algorithm registrations. Signed-off-by: Herbert Xu

crypto: tcrypt - Avoid using contiguous pages

2008-08-29T05:48:57Z

If tcrypt is to be used as a run-time integrity test, it needs to be more resilient in a hostile environment. For a start allocating 32K of physically contiguous memory is definitely out. This patch teaches it to use separate pages instead. Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Add self test for des3_ebe cipher operating in cbc mode

2008-07-10T12:35:16Z

Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2 compliance mandates that any supported mode of operation must include a self test. This satisfies that requirement for cbc(des3_ede). The included test vector was generated by me using openssl. Key/IV was generated with the following command: openssl enc -des_ede_cbc -P input and output values were generated by repeating the string "Too many secrets" a few times over, truncating it to 128 bytes, and encrypting it with openssl using the aformentioned key. Tested successfully by myself Signed-off-by: Neil Horman Acked-by: Adrian-Ken Rueegsegger Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Add test vectors for RIPEMD-256 and RIPEMD-320

2008-07-10T12:35:13Z

This patch adds test vectors for RIPEMD-256 and RIPEMD-320 hash algorithms. The test vectors are taken from Signed-off-by: Adrian-Ken Rueegsegger Signed-off-by: Herbert Xu

[CRYPTO] tcrpyt: Get rid of change log in source

2008-07-10T12:35:10Z

Change logs should be kept in source control systems, not the source. This patch removes the change log from tcrpyt to stop people from extending it any more. Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Add test vectors for RIPEMD-128 and RIPEMD-160

2008-07-10T12:35:10Z

This patch adds test vectors for RIPEMD-128 and RIPEMD-160 hash algorithms and digests (HMAC). The test vectors are taken from ISO:IEC 10118-3 (2004) and RFC2286. Signed-off-by: Adrian-Ken Rueegsegger Signed-off-by: Herbert Xu

[CRYPTO] cts: Add CTS mode required for Kerberos AES support

2008-04-21T02:19:23Z

Implement CTS wrapper for CBC mode required for support of AES encryption support for Kerberos (rfc3962). Signed-off-by: Kevin Coffman Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Change the XTEA test vectors

2008-04-21T02:19:22Z

The third test vector of ECB-XTEA-ENC fails for me all other are fine. I could not find a RFC or something else where they are defined. The test vector has not been modified since git started recording histrory. The implementation is very close (not to say equal) to what is available as Public Domain (they recommend 64 rounds and the in kernel uses 32). Therefore I belive that there is typo somewhere and tcrypt reported always *fail* instead of *okey*. This patch replaces input + result of the third test vector with result + input from the third decryption vector. The key is the same, the other three test vectors are also the reverse. Signed-off-by: Sebastian Siewior Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Shrink the tcrypt module

2008-04-21T02:19:22Z

Currently the tcrypt module is about 2 MiB on x86-32. The main reason for the huge size is the data segment which contains all the test vectors for each algorithm. The test vectors are staticly allocated in an array and the size of the array has been drastically increased by the merge of the Salsa20 test vectors. With a hint from Benedigt Spranger I found a way how I could convert those fixed-length arrays to strings which are flexible in size. VIM and regex were also very helpfull :) So, I am talking about a shrinking of ~97% on x86-32: text data bss dec hex filename 18309 2039708 20 2058037 1f6735 tcrypt-b4.ko 45628 23516 80 69224 10e68 tcrypt.ko Signed-off-by: Sebastian Siewior Signed-off-by: Herbert Xu

[CRYPTO] tcrypt: Shrink speed templates

2008-04-21T02:19:21Z

The speed templates as it look always the same. The key size is repeated for each block size and we test always the same block size. The addition of one inner loop makes it possible to get rid of the struct and it is possible to use a tiny u8 array :) Signed-off-by: Sebastian Siewior Signed-off-by: Herbert Xu