[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
kernel wrote:
> 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.
Do you have a paper reference? I know that there are issues when using
sequence numbers as IVs for CBC, but that is an isolated problem for
CBC-like modes.

> 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 we should make Counter mode available for loop_gen.c. It does
not have the artifacts that CBC has when seqence numbers are used as
IVs. On the contrary: sequential IVs are an integral part of CTR mode
encryption. This mode is not only just as secure as CBC, but has also
the added bonus of only requiring encryption, something the AES would
benfit from immensely, since decryption is so much slower for Rijndael
than encryption and reads (decryption) are typically used more often in
a filesystem than writes (encryption).

> 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),

Hm, I don't get you here. If I was to use absolute block numbers as IVs
on a 1k block size ext2 filesystem, I could theoretically end up with
the following mapping of loop device blocks vs. ext2 blocks

Q> loop: 0 1 2 3 4 5
Q> ext2: 12 13 14 22 23 24

If I used IVseed = 12 here, the first three blocks would decrypt
correctly, yet the forth would decrypt to white noise.

> satisfy
> those among us who demand unique IVs, and allow those who prefer
> operational convenience at the cost of weaker security to do so.

As CTR mode _requires_ unique IVs (CBC does not), the upper half of the
IV could be initialized from the key, whose length would thus grow by
50%. The lower half would contain the relative block number in units of
512 bytes.

> Reed H. Petty


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.136 / U:2.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site