[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A patch to loop.c for better cryption support
Andi Kleen wrote:
> On Fri, Oct 13, 2000 at 05:04:08PM +0000, Marc Mutz wrote:
> > Andi Kleen wrote:
> > >
> > <snip>
> > > 2.4 has already broken backwards compatibility to 2.2 (IV changed
> > > from disk absolute to relative). When you change it now (before 2.4.0)
> > > it is relatively painless. I think the change is a good idea.
> > <snip>
> >
> > You're wrong. All kernels from int- onwards can be configured to
> > use relative block numbers as IV's. Both the FAQ in Documentation/crypto
> > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'.
> That is not a standard kernel option. I'm not talking about any unofficial
> patchkits like the i* patches, just about what the standard loop device does.
> An encryption module can be backwards compatible itself by mapping the blocks
> itself, but without changes it will have an incompatible on disk format.

This thread was about encryption. And it was about IV's. The only
encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'.
None is just that: a no-op. And xor does not use an IV. So the only
ciphers that could possibly have been adressed by this patch are the
ones in the kerneli patch. So the on-disk format did _not_ change
between recent int-2.2.x.y kernels and 2.4-testx, provided the user
followed the recommendations and used the previously mentioned option to
use relative block numbers as IV's.


Marc Mutz <>
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.132 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site