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 Mon, Sep 06, 1999 at 05:02:28PM +0200, Alexander Kjeldaas wrote:
> 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

My concern is not key space entropy, it is that relative block numbers
enable exposures by which ciphertext can be duplicated. If the user
utilizes multiple encrypted filesystems, and the same key on each,
ciphertext duplication occurs in areas of the filesystem having known
plain text (parts of the superblock, etc).

At that point, we now of two sets of ciphertext using the same
underlying encryption algorithm with parts of the plain text are known
in both cases. Recovery of the unknown plain text has been greatly
facilitated. Several military grade crypto systems have been compromised
given this exposure alone.

One may counter my argument by stating that good operating practices
negate the exposure. This is true. However, I respond that strong
cryptosystems stay strong even when used by fools.

Yes, there are other attacks. Brute force scans of the entire key space
is often the most costly cryptanalysis method available. Techniques
which limit the key material to be searched do exist and are documented
in papers by Ben-Aroya, Biham, Shamir, and others.

Further, one must always assume that well funded opponents (with or
without a TLA) can and do apply methods of cryptanalysis which are
not published.

As for me and my systems, I find it prudent NEVER to allow ciphertext
to be duplicated. Even in cases where the opponent is aware of both the
method used to derive the initial vectors and underlying segments
of the plain text.

The last thing I want to do is to advertise to my opponent is that two or
more filesystems are using the same key material... accidents can and
do compromise good operating procedures.

Reed,

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