| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I'm cc-ing this to the SISWG mailing list, in case someone wants to add something to my pro-LRW argumentation. James Morris is also the Linux CryptoAPI maintainer. On Tue, 2004-12-14 at 02:46 -0500, James Morris wrote: > > At the moment I'm currently extending tcrypt.c to accommodate LRW test > > vectors, so my LRW patch isn't ready yet, but I would like to ask you to > > merge it's precursors, so I don't have to maintain the whole splitted > > patch set. > > I'd rather not put code in upstream unless it is needed. > Also, I'm not sure what LRW is really about and what it really gives us > over well established modes like CBC. In a nutshell, CBC sucks: http://clemens.endorphin.org/LinuxHDEncSettings This page is entirely devoted to the (in)security of CBC. Beside a presentation of the attack arsenal against CBC, this page gives a short introduction to LRW too. Further, a whole IEEE working group was founded to work on a secure CBC replacement. This should put some weight on that topic. > It's new (still not standardized?) and relatively untested, > so that itself is a concern. Good question. Let me point you to the answer the LRW designer, Clemens Kent, gave me: http://grouper.ieee.org/groups/1619/email/msg00226.html > Can you shed some > light on what LRW gives us and why we need to care about it? :-) Well, CBC has many problems when used as hard disk cipher mode. My "full disclosure" document lists four attacks which can be mounted against any cipher when operating in CBC mode. "Content leaks, malleable, movable..". Admitted, these attacks are mostly theoretical, but why should we be satisfied with that, when there is a better alternative? My LRW implementation is faster than CBC according to my benchmarks (marginally however), and is likely to be secure against the 3 of 4 CBC attacks. What more do you want? Faster, more secure, nicely encapsulated in 2 files. And GPL ;) -- Fruhwirth Clemens <clemens@endorphin.org> http://clemens.endorphin.org
This is a digitally signed message part