RE: [WIP] crypto: add support for Orion5X crypto engine

2009-03-04 Thread Ronen Shitrit
The only functional part is ecb-aes in encryption mode. The decryption seems to work in 16 byte key mode. According to the spec [1] the decryption key is different and has to be computed by the HW. Chapter 11.1.4 says, that the decryption key is computed by performing a dummy encrypt operation.

Re: [WIP] crypto: add support for Orion5X crypto engine

2009-03-04 Thread Sebastian Andrzej Siewior
* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]: However a SW calculation is also possible. Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes created by the expansion algorithm. So I picked the key expand routine from generic aes module and just passed the crypto test for

[PATCH 1/3] crypto: Fix tfm allocation in cryptd_alloc_ablkcipher

2009-03-04 Thread Huang Ying
Use crypto_alloc_base() instead of crypto_alloc_ablkcipher() to allocate underlying tfm in cryptd_alloc_ablkcipher. Because crypto_alloc_ablkcipher() prefer GENIV encapsulated crypto instead of raw one, while cryptd_alloc_ablkcipher needed the raw one. Signed-off-by: Huang Ying

[PATCH 2/3] crypto: Add fpu template, a wrapper for blkcipher touching FPU

2009-03-04 Thread Huang Ying
Blkcipher touching FPU need to be enclosed by kernel_fpu_begin() and kernel_fpu_end(). If they are invoked in cipher algorithm implementation, they will be invoked for each block, so that performance will be hurt, because they are slow operations. This patch implements fpu template, which makes

[PATCH 3/3] crypto: Add AES-NI support for more modes

2009-03-04 Thread Huang Ying
Because kernel_fpu_begin() and kernel_fpu_end() operations are too slow, the performance gain of general mode implementation + aes-aesni is almost all compensated. The AES-NI support for more modes are implemented as follow: - Add a new AES algorithm implementation named __aes-aesni without