lkml.org 
[lkml]   [1999]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: loop.c transfer module api
On Sat, Sep 04, 1999 at 04:26:35AM -0500, kernel@draper.net wrote:
> Hi Alexander,
>
> After reading through the kerneli change logs recently, I see this
> statement:
>
> Added new config option for using relative block numbers instead
> of absolute ones when calling the loop block device's transfer
> function. This should fix the #1 issue with using loopback crypto
> filesystems.
>
> The #1 issue (I hope!) was that loopback crypto filesystems cannot be
> relocated.
>
> Perhaps it would be helpful to explain why I chose absolute rather
> than relative block numbers in the loop.c transfer changes made in
> 2.1.130, and carried forward into the 2.2 and 2.3 kernels.
>
> The answer is simple: a guaranteed uniquely seeded initial vector for
> each and every block on the backing device.
>
> Why? Relative block seeded IVs are more easily duplicated (either by
> the user himself through poor operating practices, or by an opponent),
> thus enabling identical ciphertext to occur in multiple looped filesystems
> on the same device. Duplicated ciphertext is helpful to the analyst
> seeking to recover plain text and/or key material.
>

This is the reason I chose to have the relative block numbers be an
option. However, I'm not sure how much the security is improved by
having absolute block numbers. The following is the attack I'm basing
my assumptions on. There are probably other attacks that I am unaware
of though:

Some TLA agency wants to break Linux ext2 file-systems. They know
each file-system start with a common header. Thus, they encrypt the
starting block of a linux file-system with 2^n different keys and put
them in a large table [ n is the number of bits in the cipher's key].
Then, to crack a file-system, they simply look up the first block of
the loop-device in their precalculated array and get the key.

But the above attack can be circumvented by using a cipher with a
longer key. If you use a 128-bit key and the entropy of your
passphrase is indeed 128 bit, then building the table above seems to
require _a lot_ of disk-space, even if they can do certain
optimizations that only require them to store 2^90 or so blocks.

Regarding the increased security given by using the absolute block
number I think that in some cases it is very low. For instance in the
case where you use a whole partition, chances are that you have
partitioned your HD on a MB boundary or a cylinder boundary. With
some statistics I doubt the block number gives you more than 10bits of
random data. For a file it might be more but to me it still seems
that increasing the key-length of the cipher you're using is a lot
easier than not being able to take backup of your encrypted files.


> The CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK (nice addition btw for those
> who insist on relocatable looped filesystems) Configure.help text might
> include a short caution:
>
> The use of relative block numbers may increase your vulnerability to
> certain methods of cryptanalysis.
>
> Sadly "looped transformation/absolute block seeded IV" filesystems
> cannot be relocated. We often must choose between "stronger security"
> and "operational convenience".
>

Do you know of other attacks than the one mentioned above?

astor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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