Slashdot Mirror
Seeking Current Info on Linux Encrypted FS?
slick_rick asks: "I'm looking for info on encrypted file systems under Linux to help my employers company move away from Microsoft centric solutions. However the latest HOWTO is two years old, the latest kernel patch dates back to April (and 2.4.3) and even the Sourceforge project has nearly zero documentation and appears to be very dead. Are slashdotters using encrypted file systems? If so, what are your experiences?" We last talked about this topic, just
over a year ago, in this article.
Have you tried the loop-AES patch? It isn't exactly an encrypted FS, but you can create encrypted virtual drives with it.
It's a fairly decent encrypted filesystem implementation. I'm certain is has it downsides, but besides being non-free, I haven't found any others.
BC allows you to create encrypted volumes up to the max size of your harddrive, and encrypts anything therein with your choice of encryption schemas. It also comes with a 'Wipe' command that will allow you to delete a file or clean a drive with a 7-stage delete process.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin.
csfd - that's what it was. The Cryptographic File System.... The readme for the FreeBSD port is:
This is CFS, Matt Blaze's Cryptographic File System. It provides transparent encryption and decryption of selected directory trees. It is implemented as a user-level NFS server and thus does not require any kernel modifications.
ftp://research.att.com/dist/mab/cfs.ps
Note that this filesystem based encryption, not user based. I.e. you must enter a password to mount the filesystem, but after that it acts as a normal filesystem (but slower due to the aforementioned encryption).
The way that SuSE do it is to have an encrypted block device, so that you can throw anything you want on top of it. Typically this would be a filesytem ;-)
From the SuSE webpage:
... take a look at "man losetup", which has a good example of setting up an XOR encrypted loopback filesystem. XOR is pretty crappy encryption however.
- Have a picture
Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...and at least 10 ways to encrypt your data:
http://koeln.ccc.de/~drt/crypto/linux-disk.html
gives them.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
Like I said, it's not a filesystem, but it might get you by. I personally don't care if /etc is encrypted or not. But I might care if /home was encrypted. It's easy enough to mount a BestCrypt container file at /home, so that might be enough.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Do a search on google for CryptoAPI. That's the new encrypted filesystem interface for linux. The pathes for 2.4.3 are old. I have an encrypted file system working with 2.4.16 patched with GRSecurity. You no longer need to patch the kernel with CryptoAPI, it just creates kernel modules that you install. It's pretty easy to do.
By setting just one sysctl (vm.swapencrypt.enable=1)OpenBSD encrypt its swap using AES.
You just have to uncomment one line in /etc/sysctl.conf to activate it permanently.
It has the code for it, but it isn't enabled by default.
Enabling swap encryption is easiest, you just modify you /etc/sysctl.conf (it's labelled well in that file) and/or use the sysctl command.
i use swap encryption on my 1.2 athlon, but not on my 486's running openbsd.
Enabling filesystem encryption requires a kernel build (you need to add "option TCFS" to your config) and some commands to be compiled and run. i found this article to be helpful.
i just did this to see what it'd be like. the documentation is rather minimal but it is workable. You have the option of using 3DES, RC5 and Blowfish. Check out that link for more info.
-f
www.blackant.net
Can anyone fill us in on this windows folder/file encryption? How does it work? What does it use as a key, and how is that key accessed?
I read it uses AES
I would assume a key/certificate/whatever is stored in the user account profile....
But what prevents Administrator from changing your password, and signing into your account to read your files? I suppose this leaves a trail... but still.
The certificate is stored on the user's workstation. If they use multiple workstations, the user must carry their certificate with them. EFS works using 128-bit DESX. A symmetrical recovery key is generated and is encrypted using the Recovery Agent(s) public key, so that those people designated as people who can decrypt other's files can do so.
For those who still can't understand this, and think that a cracked account/BO Trojan and other absurd conditions are going to make a difference, the answer is Very Little. An agent still needs the certificate installed on the workstation that he/she is going to be recovering files from. Microsoft even recommends that a certificate be generated, the public key added as a recovery agent, and the certificate kept on removable media and stored securely until it is needed. They also recommend storing the certificate as a PKCS#12 cert since you can lock the private key with a password.
An Admin can't just change your password and sign in as you, unless he can do it at your workstation or wherever you have your certificate installed. He may be a designated Recovery Agent, though in which he can look at your files anyway. But this has always been the case on windows network, but even on Unix/Linux nobody can stop root from reading a file, right?