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

From: kernel (
Date: Fri Oct 13 2000 - 16:02:24 EST

On Fri, Oct 13, 2000 at 04:28:30AM +0200, Andi Kleen wrote:
> 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.

Caution is advised when depending upon crypto systems that use relative
block numbers as IV. The security may not be a strong as hoped.
There are some who believe that "not unique" IVs (across multiple
filesystems) facilitates some methods of cryptanalysis.

Strong security is the reason absolute block numbers were chosen at
the time I introduced loop.c cipher-block-chaining support (in
kernel 2.1.130). This has the unfortunate side effect of preventing
filesystem relocation... leading some to claim that loop.c is now
broken. A crypto system is only as strong as its weakest link.

Perhaps losetup can allow the user to specify a "IVseed" value
and then pass to the transfer modules IVseed + relative block.
This would also allow existing absolute block based encrypted file
systems to be relocated (IVseed = absolute # of 1st block), satisfy
those among us who demand unique IVs, and allow those who prefer
operational convenience at the cost of weaker security to do so.

Reed H. Petty
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:26 EST