Re: loop.c transfer module api

kernel@draper.net
Tue, 7 Sep 1999 07:20:03 -0500

On Tue, Sep 07, 1999 at 11:11:31AM +0200, Alexander S A Kjeldaas wrote:
>
> 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

Agreed. But, storing random IVs someplace doesn't sound very righteous.

Several months ago, as an experiment, I generated a large kernel module
(called loop_rand) filled with data taken from /dev/random. I then
modified the kerneli twofish code to derive IVs based on both the real_block
and data taken from the table. My twofish notes to myself:

* Jan 17, 1999 - Added exploitation of module loop_rand. This table
* contains a fairly large number of 96 bit entries of
* random data. A 128 bit block IV is derived by computing
* IV = E( real_block + loop_rand[ mod(real_block/entries ] )
* <-32bits-> + <-----------96bits---------------->
* <---------------------128 bit IV ------------------->
*
* The implication is now that two secrets must be known
* to recover the data: 1) The 128 bit key (pass phrase hash)
* and 2) the loop_rand kernel module (which is intended to
* be stored on *OTHER* than the encrypted disk)(preferably
* a diskette which is stored seperately from the machine).

The stength of the cipher should remain in the key, not in the IVs. I am
not comfortable with my loop_rand work, it strikes me as an overkill.

I think your #2 idea is perfect. Suppose one were to develop a
"filesystem signature" in losetup as a hash of the fully qualified
device/file name, stuff that into the loop_device structure, and then have
loop.c pass IV = relative_block + signature into the transfer module.
The result is both relocatable and avoids duplication of ciphertext...
the best of both worlds.

Your thoughts?

Reed,

P.S.

<RANT>

I could easily do this work in an evening. However, silly USA export
laws prevent me from changing loop.c from a BSD vnode psuedo device into
a crypto API.

Such is life behind the crypto iron curtain. I sincerely hope that
others in the world will continue to grow the technology. USA based
skill does atrophy behind clueless regulation.

</RANT>

-
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/