Re: LRW implementation, please comment

2006-09-01 Thread rsnel
Hello, On Fri, Sep 01, 2006 at 01:52:25PM +1000, Herbert Xu wrote: > On Thu, Aug 31, 2006 at 02:39:30PM +0200, Rik Snel wrote: > > This is an attempt at implementing LRW for the new blockcipher API. > > Please review, test and comment. > > Thanks a lot for doing this. It looks good to me. That

[PATCHv2 5/6] LRW, Liskov Rivest Wagner, a tweakable narrow block cipher mode

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> Main module, this implements the Liskov Rivest Wagner block cipher mode in the new blockcipher API. The implementation is based on ecb.c. The LRW-32-AES specification I used can be found at: http://grouper.ieee.org/groups/1619/email/pdf00017.pdf It implements t

[PATCHv2 3/6] crypto: some common 128-bit block operations, nicely centralized

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> 128bit is a common blocksize in linux kernel cryptography, so it helps to centralize some common operations. The data must be aligned at sizeof(int) for decent performance. The code, while mostly trivial, is based on a header file mode_hdr.h in http://fp.gladman

[PATCHv2 6/6] LRW testvectors in tcrypt.[ch]

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> Do modprobe tcrypt mode=10 to check the included test vectors, they are from: http://grouper.ieee.org/groups/1619/email/pdf00017.pdf and from http://www.mail-archive.com/stds-p1619@listserv.ieee.org/msg00173.html. To make the last test vector fit, I had to incre

[PATCHv2 1/6] crypto: trivial comment improvements

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> Just some minor comment nits. - little-endian is better than low-endian - and since it is called essiv everywere it should also be essiv in the comments (and not ess_iv) Signed-off-by: Rik Snel <[EMAIL PROTECTED]> --- drivers/md/dm-crypt.c |8 1

[PATCHv2 2/6] crypto: benbi IV, big endian narrow block count for LRW-32-AES

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> LRW-32-AES needs a certain IV. This IV should be provided dm-crypt. The block cipher mode could, in principle generate the correct IV from the plain IV, but I think that it is cleaner to supply the right IV directly. The sector -> narrow block calculation uses a

[PATCHv2 4/6] crypto: table driven multiplications in GF(2^128), needed by LRW (and in the future ABL)

2006-09-01 Thread rsnel
From: Rik Snel <[EMAIL PROTECTED]> WARNING: untested on bigendian, please test. A lot of cypher modes need multiplications in GF(2^128). LRW, ABL, GCM... I use functions from this library in my LRW implementation and I will also use them in my ABL (Arbitrary Block Length, an unencumbered (correct

Re: LRW... v2

2006-09-01 Thread rsnel
Hello Herbert/list, Here is the updated version of my LRW patch set. Greetings, Rik. -- VGER BF report: U 0.476584 - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-

Re: [PATCHv2 4/6] crypto: table driven multiplications in GF(2^128), needed by LRW (and in the future ABL)

2006-11-28 Thread rsnel
Hello Herbert, On Mon, Nov 27, 2006 at 10:56:07AM +1100, Herbert Xu wrote: > On Sat, Sep 02, 2006 at 03:00:25AM +0200, [EMAIL PROTECTED] wrote: > > Sorry it took so long. But I've been trying to modify the code so > that the same source is used for both BE and LE machines. I've > finally accumul

Re: [PATCHv2 4/6] crypto: table driven multiplications in GF(2^128), needed by LRW (and in the future ABL)

2006-11-28 Thread rsnel
Hello Herbert, On Wed, Nov 29, 2006 at 08:13:40AM +1100, Herbert Xu wrote: > > It's OK. The source will be more maintainable, but constantly converting > > between big and little-endian (on little endian machines) may have a > > significant performance impact (I will just test when your gf128 hits

proposed XTS implementation

2007-09-03 Thread rsnel
Hello list (cc: Herbert, Christoph), In my previous mail you will find a proposed patch to implement XTS (a block cipher mode alike LRW, but unlike LRW, no known security problems (LRW has problems encrypting it's own key)). An email from Cristoph sparked my interest, and the lrw.c file was a good

Re: [PATCH] an XTS blockcipher mode implementation without partial blocks

2007-09-06 Thread rsnel
Hello Sebastian, Thanks for your review of the patch. I will address your points below. On Wed, Sep 05, 2007 at 02:29:06AM +0200, Sebastian Siewior wrote: > >diff --git a/crypto/xts.c b/crypto/xts.c > [...] > >+/* key consists of keys of equal size concatenated, therefore > >+ * the lengt

Re: [PATCH] an XTS blockcipher mode implementation without partial blocks

2007-09-07 Thread rsnel
Hello, On Fri, Sep 07, 2007 at 08:38:32PM +0200, Sebastian Siewior wrote: > [...] > > >Christoph encountered a deadlock after a few hours and 16GB of data (on > >an aes-xts-plain partition). Assuming there is an error in xts.c, is > >there an obvious way of finding it? > > Haven't seen any locks