Helpful FAQ about securefs HOT 8 CLOSED

The problem with transparent compressed writable filesystem is that each block must be separately compressed. That makes compression ratio unsatisfying. You are compressing a whole file, which is very different from block level compression. The latter won't have such drastic effects.

from securefs.

I'm glad that you find my software useful. I do not plan currently to set up a wiki since not many people have asked questions so there aren't really an estimation of frequency (as in frequently asked questions).

As for your questions:

• If an attacker does not have access to your config file, he/she cannot brute force your password. In fact, even if he/she knows the password, he/she cannot unlock the filesystem without the config file. The only possibility is to brute force the 256-bit master key, which, barring any weaknesses in Crypto++'s random number generator, is simply impossible. So basically, no access to config file, no access to the content. However, you may increase the risk of losing the config file yourself if you don't store it along with the content, and if you lose it, you will forever lose all the data you have encrypted.
• securefs is not a block level encryption system. It operates on the abstraction of files, not disk blocks. If you lose some files in the underlying storage, you need to run securefs fix to recover the directory structure. If the file you lose corresponds to a regular file in the virtual filesystem, you will simply lose the file. If it corresponds to a directory in the virtual filesystem, the content of files and directories in that directory will not be impacted, but their filenames will. It is recommended that you backup your storage before you run the fix, as the fix command is not tested as often as other commands.
• The reason that compression may leak information is that it alters data size, which is public knowledge in most crypto systems. It is a complicated matter. In fact, the file sizes may leak information even if no compression is present. It all depends on how much attackers know a priori about the content you store.
• I don't understand this last question.

from securefs.

A critical security vulnerability has been found in securefs version 0.4.0 to 0.6.0. If you have used these version to encrypt your data, please either migrate to the newest version or some other encryption software.

from securefs.

About compression, I have a question. Since compression alters the original size of a file, why this might be an information link? Shouldn't the original file size provide "more" information instead?

On top of this, I would be interested on encrypting a huge amount of private really sensitive data, that could be highly compressed. I could just zip them and store the zip file inside securefs, but this is far from the original securefs idea. It defeats the purpose of using a "live" filesystem after all.

Can I do do something like this? Or is it out of the scope of this project?

from securefs.

About compression, I have a question. Since compression alters the original size of a file, why this might be an information link? Shouldn't the original file size provide "more" information instead?

See CRIME attack and Why is compression not recommended in OpenVPN?

It's not impossible to do compression + security correctly, but I have few experience with compression so I don't have confidence in doing that combination correctly.

If you really want compression + encryption, you can layer some other transparent compression FUSE on top of securefs.

from securefs.

I got it. This again makes sense when communication is involved, but maybe not in the context of a filesystem layer where there is no knowledge of what is encrypted actually.

I totally understand your point of view about the confidence, especially in things dealing with encryption. I know that I can use something like fuse-zip, by putting a zip file inside the securefs encrypted folder, and it looks safe since zip is a common file format. If something goes bad, the file is still in zip format.

The problem with this approach is, all files will be inside a giant file, like in veracrypt. So no real gain here. I'd prefer the compression to be performed per-file, having again all these little things lying around, even easy to incrementally backup.

from securefs.

I don't mean fuse-zip, but some fuse system that transparent compresses each file individually. To be more accurate, each block has to be independently compressed because fuse support random read-write. That compression ratio will be very unsatisfying.

from securefs.

Our of curiosity I did some tests. I used zip on top of securefs, meaning that I had a securefs layer and inside I put a zip file and inside the files I wanted to test. My test was a 20MB file, that can be compressed to ~4.5MB. With this approach the securefs folder was about 4.6MB.

The other way around, to encrypt and then zip (or whatever) was very unsatisfying indeed, but also expected. The folder size was just above 20MB. But of course, this is what encryption is about.

That's why the ideal solution would have been, instead of treating any file stored inside securefs as "raw" data, to compress any file autonomously and encrypt this data block instead.

from securefs.