Edward Shishkin wrote: > 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.
If you have root, you can inspect the items on the raw device, and from them construct the compressed size. The problem is not encrypting the attribute, it is preventing persons with access to the raw device from constructing the size. > >> 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. but it does not prevent determining whether the linux kernel tree is present in a directory. the cipher block is something like 64 bytes, so you still have enough size info to guess that the kernel source code is in a directory. You will often be able to guess things like whether two users are probably sharing the same file based on file size. So, we offer one tool. This tool does not meet all needs, just some needs. I wish I was using it on my home directory, we need to get this stuff shipped.;-)
