Re: A patch to loop.c for better cryption support

From: Andi Kleen (
Date: Thu Oct 12 2000 - 22:01:08 EST

On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote:
> >
> > On Fri, Oct 13, 2000 at 04:19:49AM +0000, Ingo Rohloff 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.
> I've been away from the list for a while, so this has probably been
> discussed.
> But, it seems to me that being able to have a different IV for
> each filesystem would be a good thing, but having it depend on something
> as volatile as sector of the disk, seems bad.
> What about the first block of the underlying file holding an IV?
> Then, if a loopback mount attempt finds a valid IV block at the
> start (heavily CRC'd or similar, so the likelyhood of it ever
> finding false magic is negligable (Say 10^-50)) it mounts
> the filesystem, using the IV found.
> Please tell me where the glaring error is :)

The loop device does not support any metadata. Such stuff
has to be stored somewhere else. If you want metadata in your loop
encryption module you can just supply it with a private ioctl from losetup.
I don't think such policy belongs in the main loop device, it already
carries enough cruft.

[if you wanted a loop device that supports metadata I would wait for
the new LVM IBM promised to release someday -- it'll apparently
support such things. But a simple user space solution looks cleaner
to me for now.]

Also the sector number AFAIK works fine as an IV as long as you use a cipher
with a sufficiently big block size (e.g. one of the AES candidates
with 128bit blocks). With short block sizes predictible IV is a bigger

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

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:24 EST