Re: loop.c transfer module api
Alexander S A Kjeldaas (Alexander.Kjeldaas@fast.no)
Tue, 7 Sep 1999 18:08:20 +0200
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/