Re: [CFT][PATCH] loopback fixes for 2.3

[Andi Kleen]

On Sun, Feb 13, 2000 at 07:06:20AM +0100, [e-mail] wrote:
> 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.

There is an elegant way to solve this problem: do a hash over the plain
text data without the first block and use that as the IV. Then do CFB.
On decryption you decrypt everything but the first block and calculate
the hash, then use the hash to get the first block (this is from
Peter Gutmann's SFS). Cost are a few more cycles. 

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

I consider the absolute blocks broken too. The problem is just that
loop has no sanity checks at all (no format version number, no way to
check the password in advance). I think such an arbitary change is 
not manageable. 

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

Absolute block numbers are not for the paranoid (they are much better
with the hash technique above), but for compatibility. 

-Andi
-- 
This is like TV. I don't like TV.