lkml.org 
[lkml]   [2000]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A patch to loop.c for better cryption support
Andi Kleen wrote:
>
> On Fri, Oct 13, 2000 at 10:15:21PM +0000, Marc Mutz wrote:
<snip>
> > This thread was about encryption. And it was about IV's. The only
> > encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'.
> > None is just that: a no-op. And xor does not use an IV. So the only
> > ciphers that could possibly have been adressed by this patch are the
> > ones in the kerneli patch. So the on-disk format did _not_ change
>
> And any other filter modules which use the open loadable block
> converter interface in the loop device. That kerneli exists as a patch is
> IMHO just an historical accident, near all of it can be done fine without
> ever touching any linux source at all. Please take a small peek out of
> your small world ;)
>

OK, I did not think of such. Are there any? Can you give an example and
pointers?

> BTW, kerneli would also not handle the case of switching block sizes anyways,
> with relative IVs or not, because it does not restart its CFB chain inside
> the device blocks every 512 byte blocks with a new IV. When you switch
> from a bigger block size to a smaller you would need backwards peeking to
> earlier blocks (and know the block size anyways). Similar problem for
> going to bigger blocks. Ingo's change makes it a bit less painless, but
> still not trivial to handle.
<snip>

Please re-read my mails. I never said that the current kerneli patch
does this right. In the end, I just suggest that Ingos patch included
some mechanism to allow for backwards compatibility.

Marc Mutz wrote in reply to Ingo Rohloff:
<snip>
> Your approach is not so far away from what I suggested (which is a
> simplification of what Alex suggested to me when I came up with pretty
> much the same idea as you). In fact, your approach could well be default
> way of encryption, but there should be a way to set the block size. At
> least to the block size of the underlying (call it compatibility mode or
> so). <interrupted>

So, the only provision that needs to be made to ensure backwards
compatibility (both with the kerneli patch and other modules that still
use absolute block numbers) is a way to switch between the new approach
and the old, defaulting to the new. The easiest way to do this, IMO, is
to allocate a new field 'encryption_chunk_size' or so from the set of
reserved words in struct loop_info. One might even get away with a
single bit, indicating whether to use 512 byte blocks or underlying
blocks as encryption chunks. Maybe lo_flags could be used when it
becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or
so. Then teach losetup to set this bit unless instructed not to.

- Old losetups would still work the same way they do today.
- When switching to new losetups, one can do the conversion using the
command line switch (e.g.) --use-compatibility-IVs

You can even make compatibility mode support in the kernel a
compile-time option. Is this mechanism acceptable?

> Yet, I think that there may be some clever uses for a completely
> free choice of the encryption chunk size, down to one cipher block size
> and up to the underlying's block size.
<snip>

The above snippet was just a train of thoughts.

Marc

--
Marc Mutz <Marc@Mutz.com> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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