Re: [PATCH 1/1]: Revised CTR mode implementation

2007-10-04 Thread Herbert Xu
On Wed, Oct 03, 2007 at 03:43:58PM -0500, Joy Latten wrote: On Wed, 2007-10-03 at 18:28 +0800, Herbert Xu wrote: On Wed, Oct 03, 2007 at 06:21:49PM +0800, Herbert Xu wrote: static void __ctr_inc_byte(u8 *a, int size) { __be8 *b = (__be8 *)(a + size); u8 c; do {

Re: [PATCH 1/1]: Revised CTR mode implementation

2007-10-04 Thread Herbert Xu
On Wed, Oct 03, 2007 at 06:17:08PM -0500, Joy Latten wrote: Since the last block of data to CTR may be a partial block, I changed the following in crypto_ctr_crypt_segment(), Good catch. In that case we can probably merge in_place and _segment into one function. while (walk.nbytes) {

Re: {twofish,aes}-{x86_64,i586} versus C implementations

2007-10-04 Thread Herbert Xu
On Thu, Oct 04, 2007 at 10:35:12AM +0200, Sebastian Siewior wrote: Two last questions: - What about the i386 assembly vs generic implementation? Do you prefer the patch that I have send earlier (choose the assembly by default making the generic optional) or do you want both of them loaded

[PATCH] [crypto] load the DES module by an alias

2007-10-04 Thread Sebastian Siewior
Loading the crypto algorithm by the alias instead of by module directly has the advantage that all possible implementations of this algorithm are loaded automatically and the crypto API can choose the best one depending on its priority. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] ---

[PATCH] [crypto] load the SHA1[1|256] module by an alias

2007-10-04 Thread Sebastian Siewior
Loading the crypto algorithm by the alias instead of by module directly has the advantage that all possible implementations of this algorithm are loaded automatically and the crypto API can choose the best one depending on its priority. Additionally it ensures that the generic implementation as

Re: {twofish,aes}-{x86_64,i586} versus C implementations

2007-10-04 Thread Sebastian Siewior
* Herbert Xu | 2007-10-03 15:35:22 [+0800]: On Sun, Sep 30, 2007 at 02:42:39PM +0200, Sebastian Siewior wrote: Herbert, I tried to implement a MODULE_PRIO() macro which would be used by the module loader and I noticed that it may not be required. If there are two modules providing the same

Re: {twofish,aes}-{x86_64,i586} versus C implementations

2007-10-04 Thread Herbert Xu
On Thu, Oct 04, 2007 at 11:31:56AM +0200, Andi Kleen wrote: I also think it is a bad idea to install the generic function by default -- it increases the risk the user ends up with a unnecessary slow implementation With Sebastian's change this won't be possible at all since modprobe will

Re: [1/1 take 2] HIFN 795x driver.

2007-10-04 Thread Herbert Xu
On Thu, Oct 04, 2007 at 01:22:20PM +0400, Evgeniy Polyakov wrote: I use ablkcipher_enqueue_request() when hardware can not handle new request, so this should be ok. Good point. I missed that. So there is no problem with the backlog case. But we still need to fix the partial block case.

Re: [1/1 take 2] HIFN 795x driver.

2007-10-04 Thread Evgeniy Polyakov
On Thu, Oct 04, 2007 at 01:49:23PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote: What is may backlog option? I did not find it in cryptd.c, which I used for reference. I found a backlog variables in the driver, but without any signs for the outside world - queue is initialized and backlog is

Re: {twofish,aes}-{x86_64,i586} versus C implementations

2007-10-04 Thread Andi Kleen
On Thursday 04 October 2007 10:48, Herbert Xu wrote: On Thu, Oct 04, 2007 at 10:35:12AM +0200, Sebastian Siewior wrote: Two last questions: - What about the i386 assembly vs generic implementation? Do you prefer the patch that I have send earlier (choose the assembly by default making

Re: {twofish,aes}-{x86_64,i586} versus C implementations

2007-10-04 Thread Sebastian Siewior
* Herbert Xu | 2007-10-04 16:48:18 [+0800]: On Thu, Oct 04, 2007 at 10:35:12AM +0200, Sebastian Siewior wrote: Two last questions: - What about the i386 assembly vs generic implementation? Do you prefer the patch that I have send earlier (choose the assembly by default making the generic