Re: [PATCH 0/14] Crypto Update

2005-07-06 Thread David S. Miller
From: Herbert Xu <[EMAIL PROTECTED]> Subject: [PATCH 0/14] Crypto Update Date: Wed, 6 Jul 2005 19:54:37 +1000 > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/ A pull from this tree fails: Trying to merge be290a204bf73623c796f270ae74f239db1f7daa into b4634484815e187951

Re: [PATCH 0/14] Crypto Update

2005-07-06 Thread Herbert Xu
On Wed, Jul 06, 2005 at 12:52:29PM -0700, David S. Miller wrote: > > Trying to merge be290a204bf73623c796f270ae74f239db1f7daa into > b4634484815e1879512a23e4f59eef648135c30a > error: cannot read sha1_file for da0456b37109513b472f29241a26addd69bdedbb Oops, I had an old object in the tree whose per

[PATCH 10/14] [CRYPTO] Update IV correctly for Padlock CBC encryption

2005-07-06 Thread Herbert Xu
[CRYPTO] Update IV correctly for Padlock CBC encryption When the Padlock does CBC encryption, the memory pointed to by EAX is not updated at all. Instead, it updates the value of EAX by pointing it to the last block in the output. Therefore to maintain the correct semantics we need to copy the I

[PATCH 12/14] [CRYPTO] Add x86_64 asm AES

2005-07-06 Thread Herbert Xu
[CRYPTO] Add x86_64 asm AES Implementation: === The encrypt/decrypt code is based on an x86 implementation I did a while ago which I never published. This unpublished implementation does include an assembler based key schedule and precomputed tables. For simplicity and best acceptance,

[PATCH 11/14] [CRYPTO] Add null short circuit to crypto_free_tfm

2005-07-06 Thread Herbert Xu
[CRYPTO] Add null short circuit to crypto_free_tfm As far as I'm aware there's a general concensus that functions that are responsible for freeing resources should be able to cope with being passed a NULL pointer. This makes sense as it removes the need for all callers to check for NULL, thus elli

[PATCH 9/14] [CRYPTO] Handle unaligned iv from encrypt_iv/decrypt_iv

2005-07-06 Thread Herbert Xu
[CRYPTO] Handle unaligned iv from encrypt_iv/decrypt_iv Even though cit_iv is now always aligned, the user can still supply an unaligned iv through crypto_cipher_encrypt_iv/crypto_cipher_decrypt_iv. This patch will check the alignment of the user-supplied iv and copy it if necessary. Signed-off-b

[PATCH 1/14] [CRYPTO] Don't check for NULL before kfree()

2005-07-06 Thread Herbert Xu
[CRYPTO] Don't check for NULL before kfree() Checking a pointer for NULL before calling kfree() on it is redundant. This patch removes such checks from crypto/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/cipher.c |3 +-- crypto/hma

[PATCH 5/14] [PADLOCK] Move fast path work into aes_set_key and upper layer

2005-07-06 Thread Herbert Xu
[PADLOCK] Move fast path work into aes_set_key and upper layer Most of the work done aes_padlock can be done in aes_set_key. This means that we only have to do it once when the key changes rather than every time we perform an encryption or decryption. This patch also sets cra_alignmask to let th

[PATCH 13/14] [CRYPTO] Remove unused iv field from context structure

2005-07-06 Thread Herbert Xu
[CRYPTO] Remove unused iv field from context structure The iv field in des_ctx/des3_ede_ctx/serpent_ctx has never been used. This was noticed by Dag Arne Osvik. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/des.c |2 -- crypto/serpent.c |1 - 2 files changed, 3 deletions(

[PATCH 2/14] [CRYPTO] Add plumbing for multi-block operations

2005-07-06 Thread Herbert Xu
[CRYPTO] Add plumbing for multi-block operations The VIA Padlock device is able to perform much better when multiple blocks are fed to it at once. As this device offers an exceptional throughput rate it is worthwhile to optimise the infrastructure specifically for it. We shift the existing page-

[PATCH 6/14] [PADLOCK] Implement multi-block operations

2005-07-06 Thread Herbert Xu
[PADLOCK] Implement multi-block operations By operating on multiple blocks at once, we expect to extract more performance out of the VIA Padlock. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- drivers/crypto/padlock-aes.c | 55 +-- 1 files changed, 5

[PATCH 3/14] [CRYPTO] Add support for low-level multi-block operations

2005-07-06 Thread Herbert Xu
[CRYPTO] Add support for low-level multi-block operations This patch adds hooks for cipher algorithms to implement multi-block ECB/CBC operations directly. This is expected to provide significant performance boots to the VIA Padlock. It could also be used for improving software implementations s

[PATCH 4/14] [CRYPTO] Add alignmask for low-level cipher implementations

2005-07-06 Thread Herbert Xu
[CRYPTO] Add alignmask for low-level cipher implementations The VIA Padlock device requires the input and output buffers to be aligned on 16-byte boundaries. This patch adds the alignmask attribute for low-level cipher implementations to indicate their alignment requirements. The mid-level crypt

[PATCH 7/14] [CRYPTO] Make crypto_alg_lookup static

2005-07-06 Thread Herbert Xu
[CRYPTO] Make crypto_alg_lookup static This patch makes a needlessly global function static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> --- crypto/api.c | 10 +- crypto/internal.h | 10 -- 2 files changed, 9 insertions(+

[PATCH 8/14] [CRYPTO] Ensure cit_iv is aligned correctly

2005-07-06 Thread Herbert Xu
[CRYPTO] Ensure cit_iv is aligned correctly This patch ensures that cit_iv is aligned according to cra_alignmask by allocating it as part of the tfm structure. As a side effect the crypto layer will also guarantee that the tfm ctx area has enough space to be aligned by cra_alignmask. This allows

[PATCH 0/14] Crypto Update

2005-07-06 Thread Herbert Xu
Hi Dave: Here is the crypto tree update for 2.6.13. The big changes are core updates to support multi-block operations with Padlock, a new DES implementation, and AES assembly implementation for x86-64. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/