Encrypted filesystems?

From the webpage: "Rubberhose is currently available for Linux 2.2. Userland daemons and tools are highly portable. NetBSD & FreeBSD kernel modules are nearing completion."

Might be nice to see OpenBSD support added in the future as well - but we'll see.

Last I checked I used CFS from the ports tree in OpenBSD 2.8. It's a cryptographic filesystem that's pretty tightly integrated w/ the system. Had no performance decline from using it, worked like a charm. I'm pretty sure it's been there a while, and last time this issue was brought up it was mentioned as well.

Nate

http://www.freebsd.org/cgi/getmsg.cgi?fetch=14565+17609+/usr/local/www/db/text/2002/freebsd-current/20020602.freebsd-current


Thoughts?

Ok here's the deal with production/mission-critical data, encryption protection and the loss of protection from theft or unauthorized eyes....

If the data NEEDS strong encryption so if, in the event the machine is stolen, or whatever... you must be prepared for the loss of that information. If you aren't prepared to lose that information, then any method of encryption is useless because you aren't prepared for the problems in a faulty encryption system that scrambles things, lost passwords which makes the data unrecoverable or a hardware failure which hoses the data anyways.

That said there is still a need for it (think military secrets), where, in the event the data being compromised whether being stolen or by failure, its better for NOBODY to have the information then to risk letting the enemy have it. But unless you accept that risk that you might lock yourself out or trash it, you shouldn't consider it.

It also comes down to the issue of whether you really need filesystem-wide encryption... the benefit of course is privacy.. and to eliminate the fact that specifically encrypted files are a big fat target when people are looking for the good stuff, if you're just wanting to keep missy from looking at your "image collection", stick with less encompassing schemes like cfs or something else.

As for the "wouldn't it be cool" factor... yeah it would be cool if someone wrote it instead of speculating on how cool it would be.. it'd also be cool if hard drives never failed, cd's never scratched and software bugs didn't exist.

how would backups for encrypted file systems work? dump and tar work on a file basis, so presumably you'd have to backup the actual device using something like dd. that means you'd have to have backup media that can support the entire size of your fs, as you won't be able to tell which parts actually contain files and compression will be useless (strong encrypted data will be quite apparently random and uncompressable).

that sounds real nasty so maybe you could use tar and dump provided you pass the data through an encrypting filter before it reaches the media.

From reading the comments on this thread, I've discovered that most people on deadly.org are not paranoid enough to be decent system administrators.

the link above covered vnconfig and the lack of HMAC protection which simply means someone can transperantly alter your data without you noticing immediately (at least theoretically)

so, have a really small root partition, encrypt everything else,and keep a cd you can mount to check all files in the root partition. if the other partitions dont mount, they were tampered with.

this is something good for laptops that may be stolen or tampered with (ie trojaned) without the
users knowledge.

http://www.tcfs.it/

Why do we ship cryptography?

In three words: because we can.

I hope you don't mean EFS for windows. Funny thing that, it keeps the password for your 'encrypted' share obfuscated on the disk, if your thief grabs the machine and changes the user password with a boot disk (pretty easy) then they can see your 'encrypted file system'...all the disadvantages of crypto with none of the advantages... I love MS. The Trusted(TM) computing platform of the masses.

Some others have pointed this out indirectly, but let's be explicit.

You have no need to encrypt your basic system. If you're paranoid you can store a set of checksums on a CD to verify that the executables haven't been compromised, but it's generally a waste of time to encrypt the contents of /usr, /bin, etc.

However, a laptop or intrinsically insecure system (e.g., in a dorm room) could decide to encrypt some partitions. /home, maybe some spool directories (e.g., protecting undelivered mail, unprinted documents, etc.), plus the swap space.

If you do it right, the part that's unencrypted could be a generic installation and everything that's encrypted could go onto a separate disk. In an insecure server environment, you could even mount the disk in one of those removable trays and lock your encrypted disk into a safe overnight. Even a student in a dorm room can get a cheap fire safe from Target and toss a disk into it when it's not in use, and that will probably provide better security than the encryption since it will be so easy for roommates and others to observe him typing it in.

(Do not underestimate this - in college, I once freaked somebody out by telling them the root password after hearing them type it once. I could figure it out from the slightly different sound of the keys and the timing of their keystrokes.)

u could build a cd boot that has a encrypted filesystem on it with only the boot loader/decryption engine the only plain code/text on the cd , if u want to use a swap space on a hd use the slack space and have it encrypted , or if all the drives are used and it has a windows system use the same file name + location as the windows swap file on the hd so it is overwriten on windows boot , encrypt that too , anyone interested in building one contact me