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
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
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
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
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
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
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
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-
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
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
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
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
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
13 matches
Mail list logo
