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

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