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

[Edward Shishkin <edward@namesys.com>]

Hans Reiser wrote:

>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),
>

Why?
As I understand, to encrypt file size means to encrypt a 64-bit field in 
the appropriate
stat-data extension, also we need to make sure that nobody can observe 
this attribute
(except key owner) when inode is in memory.

> and for that reason we do not
>encrypt file size.  
>

We don't encrypt file size (and other attributes) because nobody tried 
to implement it
(not because of unresolved problems).

>Edward, do you do some minor (and not crypto-secure)
>amount of padding?  (I think he does.)
>  
>

We use get_random_bytes() to fill up each stream to be proportional to 
the cipher block
size before encryption.  This is safe.

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

Yes

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

This is a complex problem, but even in the simplest case, when attacker 
has only your hard drive,
all disk structures (including items) are available.
 

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