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