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.
ftp://ftp.kernel.org/pub/linux/kernel/people/hvr
:)
Try that
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.
I tried to use win2k's efs, and it ruined me.
Tell them that!
Ever heard of a File Recovery Agent? There's one set up by default on every Win2k system. And it gets better... you can add more!
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.
When you are at the partitioning stage there is a box you can check that allows encrypted filesystems.
As I already wrote in another post, I didn't do extensive testing to compare patch-int and cryptoapi, but I *did* have lost data with patch-int: some files got garbled beyond repair (to quantify, I'd say less than 1% of them). I was using twofish.
:) But it's trouble prone.
:)
I had this problem once or twice, but using either serpent or blowfish. It happened after typing a bad passphrase... and e2fsck kicked in and complained about fs errors. Of course, I've gone a little crazy with my set up. I have two hard disks, each encrypted with a different algorithm, that are then interleaved using RAID0. I love it.
Now I'm using cryptoapi, and I didn't have any trouble (at least not yet).
Got any links or should I just look in standard locations? (Kernel archives, freshmeat?)
Another point: you may have troubles with losetup/mount, depending on the distribution you use. In that case, download util-linux from the kernel site, apply the patches and recompile. I keep two separate copies (called losetup-crypto and (u)mount-crypto) of the utilities.
That's one reason I mentioned having the latest utilities. Older versions don't support crypto stuff (obviously). But there's really nothing wrong with making hte latest util-linux package your primary. Why do you keep separate binaries?
I don't think I agree with the the suggestion about reiserfs. ReiserFS has no trouble with fsck simply because it doesn't do fsck... I'd suggest use whatever you want but disable auto-checking or, even better, modify the startup scripts to make sure that the passphrase is good (just try to mount the fs) before attempting a fsck.
Well, I suggested Reiser because in light of things not being set up properly, I think it's a little more careful before it goes and tries to replay a journal on a corrupted fs. That may actually be a positive fault here, as giving up early protects your data. In general though, I prefer a journaled fs so I'm boasting some advocacy here.
Why bother.
I've never been able to find a good Linux equivalent.
Try SuSE. Because they are a European distro (ie no problems with US export controls), and also aimed at secure/server market (unlike mandrake), they have Very Good built in security measures. It is really very trivial to set up a crypto file system. You really should give it a go. See this for some breif details.
Only problem is SuSE dont make iso's downloadable, so you might need to buy (gasp!) a copy. Money well worth spent though.
normal:
cryptoloop (cryptoapi), loop-aes, cryptfs, bestcrypt, crypto-patch (up to ~2.4.12, you have to change the Makefile -> better use cvs-cryptoapi)
steg:
stegfs, vs3fs
network:
cfs, tcfs, sfs, vpn solutions
This is quite different to quite a lot of other methods. It allows to backup encrypted files to e.g. CDROM and still have them mountable from there. Works quite well.
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.
What about StegFS is a steganographic filesystem for linux. It encrypts the data and hides it. Although it does not work with 2.4.x kernels, a decently patched 2.2.20 kernel should do well enough. If that's not you particular cup of tea there is always cfs tcfs.
Fighting for Peace, is Like Fucking for Virginity
Fighting for Peace, is like Fucking for Virginity.
Turns out that NTFS cannot be used on removable disks
I use NTFS on my zip 100 disks all the time. Its not that it won't work on removable disks, its that they disable the use of NTFS on small disks (and i guess flash cards? never used them.). I have not formated one on WinXP yet, but I have on WinNT4 and Win2000.
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
The last time I tried, it worked fine...except for sparse files. They were handled properly as sparse files, but when you read the holes, cfs would try to decrypt it and return random garbage.
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?
Don't forget that if you put your laptop to sleep and it's stolen in that state that your encrypted filesystem may be left wide open.
:)
Unmount encrypted filesystems before you sleep the laptop and put a password on your screensaver in case you get lazy. (don't count on a password-protected screensaver to protect you though -- maybe someone will create a screensaver that unmounts any encrypted fs and prompts for the access password...
Wrong. EFS does not use 56-bit DES you idiot.
Microsoft is using 128-bit DESX encryption for EFS. What is DESX? It's a strengthened version of DES created by RSA Laboratories.
http://www.rsa.com/rsalabs/faq/3-2-7.html
As far as the back doors are concerned. If it's your own machine you have nothing to worry about because only you would know the backdoor. However for a corporation the administrative back door is regarded as a must-have feature in case an employee is fired, dies, leaves the company, whatever.
Why are Linux users so bloody ignorant?