lkml.org 
[lkml]   [1999]   [Sep]   [7]   [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 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/

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