[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
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

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