Re: Announce: cryptoapi-2.4.3 [aka international crypto (non-)patch]

[Andrew McGuinness <andrew_mcguinness@bigfoot.com>]

Quoting Herbert Valerio Riedel <hvr@hvrlab.org>:

> hello!
> 
> On Thu, 26 Apr 2001, Jari Ruusu wrote:
> > Herbert Valerio Riedel wrote:
> > > On Tue, 24 Apr 2001, Jari Ruusu wrote:
> > > it should have been more or less:
> > >
> > > unsigned long IV = loop_get_iv(lo,
> > >   page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
> > >   + (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));
> > I hope not exactly like that. What happens when "lo->lo_offset" is
> larger
> > than "offset". Oops. Besides, the + operator takes precedence over the
> >>
> > operator on the third line.
> ...you are right again :-)
> 
> do you have any objections about...
> 
> unsigned long IV = loop_get_iv(lo,
>    page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
>    + (offset >> LO_IV_SECTOR_BITS)
>    - (lo->lo_offset >> LO_IV_SECTOR_BITS));
> 
> 
> ...then? ;-)
> 
> the assumption is, offset % LO_IV_SECTOR_BITS == 0
> this calculation may overflow anyway... for file sizes around terabytes
> or
> so I guess... but another thing is, that every IV calculation should
> overflow at the same boundary... since it's just an IV value...
> 
> (maybe that calculation should be done in a 64bit domain anyway)
> 
> > Have you ever observed the sizes of the transfer requests? The sizes
> of
> > transfer requests change on the fly (and I'm not not talking about the
> last
> > partial block of a file). Meaning, any IV computation that depends on
> the
> > block size of a filesystem, is broken and must die! We do not have an
> option
> > here.
> I know that issue, I've already pointed that out some time ago, but
> there
> are compatibility problems as well, at first I thought the international
> crypto patch was the only filter to make use of that IV, but then I
> learned there were a few others as well...
> (btw, the int crypto patch had the compatibility option for absolute
> block
> numbers for quite some time too... just for the sake of
> compatibility...)
> 
> and btw, many people seem to be quite happy with their non-512 based IV
> encrypted volumes... so why forcing them to switch?
> 
> btw, depending on the filesystem using the loop device, and the
> underlying
> file or device, the transfer requests size may be constant... e.g. at 4k
> blocks... but other filesystems, such as XFS do have different sections
> with different blocksizes... they clearly break things...
> 
> breaking up transfers into 512 bytes _everytime_ isn't a solution
> either... it is unefficient, especially for filters not making use of
> the
> IV at all...
> 

It would help the compatibility if there were a conversion program for old
volumes to the new style.  I was going to try writing one, but I don't think
you can call the international crypto patch functions from a user-space 
program.  Would it be possible to put ifdefs in the code so you could compile
the transfer functions as user space functions?

--
Andrew McGuinness     Luton, UK        andrew_mcguinness@bigfoot.com

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/