Messages in this thread |  | | Date | Fri, 13 Oct 2000 16:02:24 -0500 | From | kernel <> | Subject | Re: A patch to loop.c for better cryption support |
| |
On Fri, Oct 13, 2000 at 04:28:30AM +0200, 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. >
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 rhp@draper.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |