The audit linked says that it ecryptfs might not have been designed/written by a cryptographer. What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be?
Truecrypt is simulated hardware encryption. It creates a virtual encrypted hard disk, which your operating system can more or less treat like an ordinary hard disk, but for the kernel hooks Truecrypt adds to lock and unlock the disk.
EcryptFS is an encrypted filesystem. Unlike Truecrypt, which encrypts individual disk blocks, systems like EcryptFS encrypt and decrypt whole files.
All else being equal, you'd prefer an encrypted filesystem to a simulated encrypted hard disk. Some of the reasons are technical: the crypto involved in encrypting a block device is crappier than the crypto involved in protecting a file (most notably, block crypto is typically not authenticated). But at a higher level, the reason is that you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.
All things are not equal though, and to select EcryptFS over Truecrypt, you also have to select EcryptFS's design and implementation over Truecrypt's. Truecrypt's design is simple and has been looked at more carefully than EcryptFS's. On the other hand, Truecrypt is an XTS cryptosystem, which isn't great. I would have a hard time making a recommendation between the two.
It's more important that you understand the limitations of transparent disk encryption. Unless you are pretty regularly telling your crypto software that it's OK to unlock a given file or disk or whatever, then it's probably "always on", and your keys are always resident in memory, and your files are more or less always exposed to malware. Malware is a much scarier threat (for most people) than police raids.
If you're interested: we work in a pretty high-risk environment (we handle a lot of hazmat). Our general crypto regime at Matasano is:
* Everyone uses Filevault2's native XTS disk encryption (along with some fiddly rules for what state your machine needs to be in if it's in your bag).
* Everyone uses OS X encrypted DMGs (I don't remember what the block crypto design for DMGs is, but you can check out John the Ripper if you're curious) to isolate different projects; we audit machines to make sure keys aren't in the keyring.
* Everyone uses PGP for email and to encrypt specific files.
If this sounds like a pain in the ass, be aware that this is pretty close to the minimum viable amount of security you can be providing a mobile device; if you're skipping one of these steps, you should know why.
I disagree for these reasons:
1. This decreases composability. With encrypted filesystems, I can't mix and match filesystems and cryptosystems to suit my needs. There is no reason they need to be convolved.
2. This increases complexity. Now, the person writing the software has to be an expert in both filesystems and cryptosystems if they want to do a good job. There is more room for error. (You might say it violates the UNIX philosophy of "do one thing and do it well".)
3. This leaks information to an attacker. They know the layout of my files even without my password. I'm more comfortable with absolutely everything looking like a giant monolithic block of random data.
I should have explained my reasoning for originally choosing ecryptfs. I find it really convenient doing a backup of ecryptfs' cipher-text. Since it's simple files, an rsync will do. If I wanted to backup virtual encrypted disks, I would first have to mount source and destination to do an rsync, or painstakingly do an entire dd without the mount... maybe I'm just doing it wrong?
Use a non-local encrypted filesystem per project to get the isolation and to avoid your local storage. Mount the project filesystem when needed, unmount it when done, and when not in use it is simply inaccessible to the laptop.
While any encrypted filesystem not stored on your laptop would work for this, ours[1] makes this workflow very easy.
Is this simple oversight?
you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.
Doesn't this leak information? An attacker knows very little about an opaque block, but may be able to use file length and modification order to some advantage.
It has the extreme disadvantage that I can't mount my disk on anything except windows. Which is a no-go given that I mostly live in Linux and most of my colleagues do a lot of work with MacOS. We all have Windows machines for the bureaucratic stuff we must do (word documents, excel, various internal web portals that require IE or some sort of ActiveX plugin). The things is: when it comes to closed source companies, Microsoft is one that I am willing to accept that they have sound engineering and release policies. But they refuse to explain how it works, so we can't inter-operate and we have to do something else.
(Which for me means that I use a FIPS certified hardware encrypted USB drive with a built in keypad that you use to enter a pin, but for everyone else it basically means they don't bother and just use stupid unencrypted FAT drives and don't care if they "get caught". Or they try to use the awful Box sync shit IT is currently trying to foist on us)
But on topic, BitLocker is only suitable for enterprise because it's simply unavailable for home versions.
Just to push back on this a bit, I don't think it's particularly likely that TrueCrypt is in any way compromised. It's been stable software for quite some time now, it's open source, and there have been no identified flaws with it. The main problem with TrueCrypt is that it may be nearing the end of its useful life as filesystem technology changes and TrueCrypt is not updated along with it (this has already happened with GPT/UEFI and TrueCrypt's full-disk encryption). If TrueCrypt will work for you, at the moment you don't really have to worry that it's been compromised or worry about "lack of support" (note it hadn't been updated for over two years before the abrupt departure of the anonymous devs).
It's quite possible that you won't even run into any compatibility issues in the future, as future encryption tools will likely offer support for TrueCrypt volumes - once the phase II (crypto) audit is complete, assuming no major flaws are found, it will be a vetted, open technology, so it'd be a no-brainer to write an implementation based on it.
