Re: loop.c transfer module api

Alexander S A Kjeldaas (Alexander.Kjeldaas@fast.no)
Tue, 7 Sep 1999 11:11:31 +0200

On Mon, Sep 06, 1999 at 12:13:40PM -0500, kernel@draper.net wrote:
>
> 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.
>

If you want to guarantee that ciphertext is NEVER duplicated, you
_have_ to store the IV somewhere. You can not rely on a block offset
to be unique for a given system. For instance, I imagine that someone
will come up with a simple modification to RedHat where all
filesystems are encrypted to protect the machine in case it is stolen
[should be pretty easy to so using initrd by the way, hint hint]. If
the machine has multiple disks, each disk will have duplicated
ciphertext whether they use absolute or relative block numbers as IV.

So when you use relative offsets, you get duplicated ciphertext when
you have several encrypted filesystems. When you use absolute
offsets, you get duplicated ciphertext when you have several encrypted
filesystems starting from the beginning of each disk. To me it seems
that using relative offsets is a security/useability tradeoff that a
lot of users will want.

If you think this is a serious problem it should be dealt with
properly. Three reasonable ways of doing it are:

1) Store random IVs in the loopback filesystem.

You then have to waste some space, but you'll get your added security
in all cases, and users will be able to move the files since the IVs
are stored internally. I can imagine a loopback file having a layout
like this:

<512 bytes IVs><512*(512/num_iv_bytes) ciphertext>
<512 bytes IVs><512*(512/num_iv_bytes) ciphertext>
...

So to store block x you calculate:

blocknum = x + (x >> 9) + 1
ivblocknum = (x & ~511)
ivoffset = (x & 511) * num_iv_bytes

You fetch the IVs from /dev/urandom, and the buffer cache will take
care of keeping the IVs handy.

2) Give a random initial IV during losetup and use offsets relative to
this value

This just changes the calculation of IVs from

IV = absolute_block_offset

to

IV = initial_iv ^ relative_block_offset

3) Reserve 64 bytes at the start/end of each loopback filesystem to store
the data for (2).

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/