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.

loop-AES

[Sami]

Have you tried the loop-AES patch [sourceforge.net]? It isn't exactly an encrypted FS, but you can create encrypted virtual drives with it.

Stuck in Windows? Bestcrypt works okay...

[Bonker]

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.

Reiser4

[jeffphil]

If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin. [namesys.com]

Re:FreeBSD & NFS

[stygian]

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

SuSE does this out of the box...

[pwagland]

I am not sure about the other distributions, but as of SuSE 7.2, they do this out of the box. The support was improved in 7.3.

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:

* A highlight of SuSE Linux security technology: the so-called "crypto file system". Secret or sensitive data is encrypted on your own PC. This method is so safe that even if your notebook ist stolen, nobody, absolutely nobody (!) has even the slightest chance of decrypting your data. In addition, the crypto file system is so smart that the thief will not even notice that encrypted data exists.

XOR encryption is supported out of the box...

[grytpype]

... 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.

Deniability

[Tet]

Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org [rubberhose.org]

50 ways to leave your lover

[mAsterdam]

...and at least 10 ways to encrypt your data:
http://koeln.ccc.de/~drt/crypto/linux-disk.html
gives them.

Re:SuSE does this out of the box...

[MKalus]

Actually I am using this activly on my Notebook and I haven't really seen any performance degredation (It's a PII 366). The nice thing about it is: It completly prevents you from booting the box at all so the security on the notebook is greatly enhanced:

- Login Bios Password (Yeah, no security there I know)
- crypto FS
- OS Security

Now the two weak links are the BIOS password as well as the OS Security (just boot from CDROM and on you go), but everything on the /data/ partition is encrypted and the parition is invisible if you boot from a boot disk.

Really neat.

Michael

cryptfs

[sdxxx]

There is a cryptographic file system you can get for SFS [fs.net]. If you go to the download page [fs.net], it's called cryptfs. Unfortunately, you have to install SFS first to compile cryptfs.

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 [nyu.edu] in which the students build a fully-functional cryptographic file system as an NFS loopback server.

More recent CryptoAPI patches can be found at...

[NeoTron]

ftp://ftp.kernel.org/pub/linux/kernel/people/hvr

Try that :)

Try BestCrypt

[Wee]

I know it's not really an encrypted filesystem, per se, but BestCrypt [jetico.com] might be enough for you. It's a bit like NAI's PGPDisk. Essentially, you mount an encrypted file and then access it like any other disk (it has a mount point, etc). The nice part (for me) is that they have a Win32 version as well, so using BestCrypt and Samba means that I can have my wife's securely store her Quicken stuff on my fileserver (which is the only machine that gets a backup). The only "bad" thing about BestCrypt is installation. You have to make real sure your kernel sources are in good shape. I had a few issues installing it because I had a few different kernel sources laying around (not good, I know, I know...). Anyway, it's not that hard to install, but not a userland type thing either.

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

Re:win2k

[TheCabal]

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!

CryptoAPI

[Agent_Leprechaun]

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.

SuSE Linux comes with an encrypted filesystem

[nakana82]

When you are at the partitioning stage there is a box you can check that allows encrypted filesystems.

Re:It's Really Pretty Trivial

[Lethyos]

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.

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. :) But it's trouble prone.

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. :)

Re:FreeBSD & NFS

[Marcus Brody]

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 [suse.com] 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.

some possible solutions

[jjermann]

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

twofish loopback encryption

[aCC]

Twofish loopback encryption [in.tum.de] is a module to encrypt loopback devices "independent[ly] from the medium on which the filesystem is stored".

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.

swap encryption ? use OpenBSD

[^BR]

By setting just one sysctl [openbsd.org] (vm.swapencrypt.enable=1)OpenBSD [openbsd.org] encrypt its swap using AES.

You just have to uncomment one line in /etc/sysctl.conf to activate it permanently.

StegFS?

[lnxslak]

What about StegFS [mcdonald.org.uk] 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 [www.tcfs.it].

Fighting for Peace, is Like Fucking for Virginity

Re:XOR encryption is supported out of the box...

[Wumpus]

Don't do this.

cat /dev/loop0 is likely to produce the key in the first page or so of output, since the plaintext is likely to have long stretches of 0 someplace. Remember, K xor 0 = K.

Re:Lame, Windows XP implementation

[Icy]

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.

OpenBSD filesystem encryption

[friscolr]

Why not just use OpenBSD, which has filesystem encryption by default

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 [demon.co.uk] 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.

Re:Which is better for FreeBSD? CFS or Rubberhose?

[Anonymous Coward]

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.

Re:Deniability

[Syberghost]

But that means nothing compared to actual precendence, of which I am not aware, 'cause I don't really keep up with this stuff. I assume it's protected, as the recent case against that mobster was borderline and it wasn't a question of whether the guy would be forced to give his password, but what to do once it had been aquired.

There's a great analysis on the Rubberhose web site, talking about the legal precedents and arguments currently existing.

The argument that Fifth Amendment protection doesn't extend to things you've already said, such as information on a hard drive already, is scary, even if you don't find it compelling. Courts don't always rule in accordance with a particular interpretation of the law, much less in accordance with logic.

Re:win2k

[TheCabal]

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?

sleeping laptop defeats encryption

[bmidgley]

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... :)

Re:SuSE does this out of the box...

[Anonymous Coward]

Some laptops (such as IBM's) have a more secure BIOS password system that can't just be jumpered away. If you forget the password, you have to replace the systemboard.

Re:I've used it the last 2 years

[sheldon]

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?