Messages in this thread | | | Date | Tue, 7 Sep 1999 07:20:03 -0500 | From | kernel@draper ... | Subject | Re: loop.c transfer module api |
| |
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/
| |