Messages in this thread | | | Date | Tue, 7 Sep 1999 18:08:20 +0200 | From | Alexander S A Kjeldaas <> | Subject | Re: loop.c transfer module api |
| |
On Tue, Sep 07, 1999 at 09:10:25AM -0500, kernel@draper.net wrote: > On Tue, Sep 07, 1999 at 03:50:41PM +0200, Alexander S A Kjeldaas wrote: > > On Tue, Sep 07, 1999 at 07:20:03AM -0500, kernel@draper.net wrote: > > > > > > 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. > > > > > > > The IV should be _random_, not secret. Just look at the operation of > > CBC mode. Each block of ciphertext is the next block's "IV". So > > there is no reason to keep the first IV secret when all the other > > "IVs" are exposed. What we want to do is to keep the first IV > > _random_. > > > > You do not consider a hash of the device/file name to be sufficiently > random?
Sorry I was referring to your loop_rand which was keeping IVs secret. I'm not sure a hash of device/file is sufficiently random, but if that is introduced you still get a dependency on the location/name of the backing store. However, if #2 is implemented, people can do whatever they want. I think _I_ would prefer something like the following in a nice wrapping:
# dd if=/dev/urandom of=backingfile bs=32 count=1 # IV=`dd if=backingfile bs=32 count=1 | od -tx -w32 | ...` # losetup -e serpent -o 512 -iv $IV /dev/loop0 backingfile
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/
| |