Re: Encryption/Compression and meta data (like file names)

[Hans Reiser <reiser@namesys.com>]

Instead of answering your questions as asked, let me explain what it does.

It encrypts the file data.  It makes some effort at avoiding
watermarking attacks by use of an initialization vector, but this effort
is not robust in that file size is not encryptable without an
unacceptable cost in space utilization (to encrypt file size you must
store each of the files with a random amount of padding proportional to
the size of the largest file stored), and for that reason we do not
encrypt file size.  Edward, do you do some minor (and not crypto-secure)
amount of padding?  (I think he does.)

It does not encrypt the filenames.

I believe that if you want to encrypt file size you really want a deeply
different approach.

The problem with not encrypting file size is that you can figure out
whether someone is storing, say, the linux kernel, in their home
directory, by looking at file sizes, and if for every file in the tree
you have a match in file size, you can be pretty sure the linux kernel
is what it is.

So, our encryption is useful for protecting data whose contents are
unique, like your personal accounting, and not useful for data that are
widely known and stored in a tree of many files, like the linux kernel.

Now that I have answered the questions you did not ask, could you repeat
your email to me with the questions that you still want me to answer?

Future work for future reiser4's: multi-file compression and encryption
based on encrypting and compressing (enlarged) nodes not files. 
Alternately, compressing and encrypting whole directories rather than
files.  Note how if files are 100 bytes, you are motivated to make
compression be implemented using multiple files if you want good
compression.

Hans

John Gilmore wrote:

>I seem to recall several people saying that the compression/encryption plugins 
>will only encrypt items, and not the filesystems metadata. And then saying 
>that this might be useless for their purposes, because being able to see the 
>filename might be enough for the attacker.
>
>However, I don't think that is correct. The only thing visible to an attacker 
>would be the tree structure, not the item, which contains the directory 
>information including the filenames.
>
>So at most an attacker would be able to browse the tree structure, and see the 
>keys used and the size of the item pointed to. If this is true, selection of 
>a good hash should entirely prevent the giving information away problem, 
>leaving only useless key->size->location data for an attacker.
>
>Is my understanding correct?
>
>
>  
>