lkml.org 
[lkml]   [2000]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [CFT][PATCH] loopback fixes for 2.3
On Sun, Feb 13, 2000 at 01:12:51AM +0000, Alan Cox wrote:
> > Sigh... Alan, I'm sorry, but could you try to use /dev/loop on 2.3.43? And
> > watch the show. The most trivial test being: dd if=/dev/zero of=foo count=40
> > losetup /dev/loop0 foo; yes|dd count=20 >/dev/loop0; losetup -d /dev/loop0;
> > Now check foo. It was broken in many interesting ways.
>
> It works fine in 2.2.x. If I tweak my data it stops working in 2.2.x. You
> broke an on disk file system format, thats virtually a captal crime in my
> book 8)
>
> > The bottom line: encryption driver can trivially compensate for the change.
> > So if it's a problem with on-disk format - fine, let's keep the transformation
> > in the format-handling code.
>
> Ok. But we need to be able to keep the disk format constant. And yes putting
> any grunge in the crypto is a good idea
>

Alan,

I am the culprit that created this whole absolute block mess with my
extension to the loop transfer module API in kernel 2.1.130. I was trying
to implement a strong encrypting filesystem for my own use. Strong defined
in terms of resistance to cryptanalysis and minimizing information available
to opponents (such as number and sizes of files, access timestamps, etc,
all of which are visible in file based schemes like CFS).

Prior to 2.1.130 ECB mode was the only option. Cipher block chaining
(CBC) (known as cipher-driven codebook within the NSA and elsewhere)
having unique IV's per block is a "must have"... anything less is not worthy
of the implementation effort, imho.

I considered and rejected passing relative block numbers to the transfer
modules for use as IV seeds. The last thing I wanted to see was
duplication of ciphertext on my disk drive (occurs when multiple looped
filesystems exist on the same drive using the same cipher and key).
Such duplication at minimum is "interesting" to the cryptanalysis, and
at worst facilitates recovery of plain text.

Many of the Linux community consider loop.c to be broken. Astor in his
kerneli International Crypto Patches favors relative block, as does
Al Viro in this thread... and I too acknowledge that relocation of backing
files, in all its flavors, is desirable in some environments.

That said, there remain the exemptionally paranoid among us who need
access to absolute block numbers as IV seeds. Speaking for myself,
I have no concern adding bmap logic to my own transfer code.

Al's patch seems reasonable.

Reed H. Petty
rhp@draper.net

-
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:56    [W:0.052 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site