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
ker
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
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
---
crypto/crypt
* 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 f
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. Thi
