Not to mention how much the US governments advocates against encryption they can't have backdoors to. They have a lot more influence over the encryption in Windows than TrueCrypt. Not suggesting they DO have backdoors to Bitlocker, there's not enough evidence, but the probability is much higher.

They do in the form of OneDrive.

https://news.ycombinator.com/item?id=8546524

Short story is that if you use Windows 8{.1} and have a Microsoft account then it will upload your BitLocker keys by default. Seems to me like a backdoor if ever I heard one.

Tar the directory(s) and use GnuPG/libgcrypt aes-256-gcm https://www.gnupg.org/documentation/manuals/gcrypt/Available...

OpenSSL is on every system and can encrypt files with aes-256-gcm if for whatever reasons libgcrypt can't be used http://stackoverflow.com/questions/12153009/openssl-c-exampl...

Tarsnap you can copy keys to any platform that will run Tarsnap http://www.tarsnap.com/man-tarsnap-keygen.1.html http://jamesoff.net/site/2009/09/10/tarsnap-under-cygwin/

This is a huge pain for when you want to read it again. Truecrypt will let you define little mountable volumes which can be loaded as you need them.

I find tarsnap much easier/better than any block crypto mount. Intelligent backups that only synch what you've changed. Luks containers and tc-play exist if you must use a mounted container.

Both Bitlocker and Filevault allow this same UX. On Windows, you create and encrypt a VHD. On OSX, you create an encrypted DMG. There's even an OSX tool, "Knox", that (when we used it) did a really great job managing lots of little encrypted volumes.

If you want to move an encrypted file from Linux to Windows, though, you should use something like PGP.

So tptacek's argues that sector-based full-disk encryption is inherently vulnerable, especially if used on the boot volume, because if someone grabs your laptop everything's still loaded in memory.

What if my use case is different: keeping just a particular set of documents not in constant use secret? Perhaps stored on a removable drive? Truecrypt is great for this. It does have the risk of information leakage via tempfiles and swap, but it also makes you a lot harder to raid unless you've got the incriminating document open on your screen in a cafe (you fool).

(I was asked by someone I know who works in international human rights "How do I get my case files safely across borders?" and didn't have a good answer.)

If the documents aren't in constant use, the most secure way to encrypt them is with a userland program like PGP. Userland crypto knows where files begin and end, and can store metadata to improve the encryption. They can provide cryptographic integrity --- far more powerful than the incidental integrity check Bitlocker tried to provide, or the virtually zero integrity that XTS provides. They're randomized, so the ciphertext can have semantic security; it reveals nothing at all about the plaintext, even as the files are edited in place under the same key.

Sector crypto can't do anything even approximating this without contortions like geli.

If I was trying to protect files from nation state adversaries, I would not consider Truecrypt.

That doesn't mean I think you shouldn't run something like Truecrypt. I think you're better off with whatever your OS provides, but some kind of sector-level crypto, be it Bitlocker, Truecrypt, or Filevault, is still useful.

But if you're serious about protecting a specific set of files, encrypt them manually, no matter what else you do.

Can PGP do true edit-in-place, or do I have to decrypt to local disk first? Because decrypting to local disk is very likely to leave plaintext lying around somewhere unless my primary SSD supports "secure erase free space" and I remember to use it.

Good point. It doesn't; you need to securely delete temporary files. Mitigating that:

* Sector-level crypto is cryptographically incapable of secure in-place editing; they can gradually leak information about the plaintext as edits happen. That's not a big deal for a PDF, which aren't on-line live real-time edited, but it can be a big deal for other kinds of files. I tend to err on the side of systems programming weaknesses rather than crypto weaknesses. We're better at dealing with them.

* No matter what kind of cryptography you're using, the assumption you should be making is that plaintext is at some point exposed to someone who owns up your live running system.

I think concern about unlinked plaintext-containing sectors is reasonable, and a good reason to use both sector-level crypto and file-level crypto. I use both, as does everyone at Matasano.