[tptacek]

The idea that you'd want cross-platform full disk encryption suggests you may be investing too much faith in the powers of full disk encryption. FDE does basically one thing for you: it reassures you if your laptop is stolen from the back seat of your car or left in a cab.

Cross platform encryption is very important, and you should look for good solutions (most of us who rely on encryption for real operational reasons just hold our noses are use PGP). But full disk encryption has very limited utility. The idea of a USB drive you can plug into any computer that is locked by default is attractive, but you can get better security out of a USB drive that holds nothing but files encrypted at the application layer.

More:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

[Perseids]

> You can’t authenticate the data. Authenticating every sector is too expensive. Try to (painfully) authenticate the whole disk and any disk error trashes the disk. Maybe your users enjoy exciting games of chance? Authenticate arbitrary groups of sectors and you can play Russian Roulette with your files. (http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/)

Out of interest: Doesn't the use of error detecting filesystems like ZFS and Btrfs solve the authentication problem? I don't have anything resembling a formal argument, but intuitively having each block checked in a Merkle tree like fashion should inhibit attacks where attackers can only change blocks in a random manner or restore old backups of the blocks. Of course time traveling - i.e. replaying - the file system as whole is still possible, but selectively manipulating the data should not.

[tptacek]

It would probably make the exploit harder (unless the exploit targets the filesystem code itself), but there are almost always subtle gaps between "breaking the exploit" and "fixing the vulnerability". This is a fun question to dig into, though.

This is also very similar to the tactic of using an encrypted message digest in place of a MAC. The whole point of a MAC is that it can't be calculated without the secret that provides its security, and so schemes that use digests instead are (a) harder to attack than systems that do nothing and (b) still broken.

[alcari]

The ZFS crypto implementation (which isn't really available outside Oracle's Solaris) uses AES-GCM, which solves the authentication problem.

[tptacek]

If you have filesystem encryption, block-level encryption is probably unnecessary. Filesystem encryption is in most ways superior to block-level crypto.

[undefined0]

Do you know of any software (maybe it's possible with Truecrypt?) to have full disk encryption with a hidden volume for Linux? I remember Truecrypt only worked on Windows with this feature. As Windows can auto-update your computer even when you disable it in the settings, I wouldn't want to use it.

[YAYERKA]

The comparisons between filesystem-level vs. block-level encryption that I've encountered usually make a common distinction; namely that file metadata is still present when only applying fs-level encryption. What are some attributes of fs-level encryption that would make it a superior choice over block-level?

[tptacek]

There are three huge advantages filesystems have over block devices when it comes to encryption:

1. They have storage flexibility, so they can allocate metadata to authenticators and nonces. The fact that sector-level crypto can't do this means that the "state of the art" in efficient sector crypto is essentially unauthenticated ECB mode.

2. They're message-aware, so they can apply authentication at meaningful boundaries; a block crypto device is essentially a simulated hard disk, and so it doesn't know where files begin and end.

3. Being message-aware, they can protect files at a better level of granularity than "all or nothing", which for instance is the security failure that made it so easy for the FBI to convict Ross Ulbricht for Silk Road.

A lot of concerns about filesystem crypto stem from the fact that filesystem crypto precedes sector-level crypto, and most of it was designed (or has designs tracing to) the 1990s. What people who don't spend a lot of time studying crypto should remember is that nobody knew how to encrypt anything in the 1990s. It was a unique and weird time, where there was a lot of demand and interest in crypto, but not enough knowledge to supply crypto effectively.

So we should be careful about judging filesystem crypto by the standards of the 1990s.

[JoshTriplett]

I've read that page before. It does a good job of explaining why you don't (just) want full-disk encryption, and explaining why developers might want to use application-level crypto in their own application. However, what it doesn't explain is "what should users (developer or otherwise) do to encrypt all the random files on their system?".

Full disk encryption has the advantage of being transparent and not application-specific, so you don't have to teach every random application to do application-level crypto.

Sure, if you have a few specific files you want to encrypt, you could run gpg. You could even teach specific tools to understand gpg, such as text editors that can decrypt to memory, edit, and re-encrypt before writing to disk. But what about a source tree, stored in a git repository, regularly manipulated with git and various command-line utilities, and edited with a variety of editors? How would you store that, securely, other than on a block device encrypted with full-disk encryption?

Would you suggest a file-level encrypting filesystem instead, similar to eCryptFS? Would you suggest integrating encryption into ext4 (currently being worked on) and other filesystems?

[belorn]

Application-level crypto work great when the target surface is small and known, but fails badly otherwise.

Take a email you have received on a unix mail server, and lets assume it was sent encrypted. Is the search term database encrypted, the one that was created while the mail was decrypted? Is the reply you sent encrypted while resting in the sent directory? Are there logs, metadata, offline caches and similar leakage of data?

One should start with full-disk encryption, then add application-level encryption for defense in depth.

[lurkinggrue]

I can imagine all the ways an os can leak information if it isn't fully encrypted at a sector level.

Just having the filnames is an serious risk.

[kngspook]

I spent all last night searching for an answer to this question. I couldn't find one.

[michaelt]

A few times in the past I've taken a hard drive out of a failed computer and retrieved data from it on another computer. Sometimes this was cross-platform, reading Windows data on a Linux machine.

I haven't had to do this often, but the times I have had to do it, it's been a lifesaver.

Any advice, apart from keeping better backups so I don't have to do any cross-platform data recovery?

[kogepathic]

Pass the disk through to a VMWare/KVM/Xen container (if you can find another machine of the same processor architecture) and then boot the OS in the VM.

Usually it will piss Windows right off to be booted on completely different hardware, but usually it works enough to grab any files you may want from within the FDE.

It's utterly useless if the FDE was using any TPM hardware though, in that case then I'm afraid you're stuck using the original hardware.

[kevin_thibedeau]

GP didn't ask for full disk encryption, only "mountable disk images" which are far more flexible to deal with in heterogeneous environments.

[tptacek]

Yes, and I'm saying that "flexibility" isn't worth its cost in security. Use app-layer crypto. Among other things, app-layer crypto gives you fine-grained data integrity, foreclosing on a vector for remote code execution attacks.

[tokenizerrr]

Do you have any specific examples of implementations on what you mean? I'd love to store word documents, pdfs, etc. gpg encrypted on an USB stick, without having the decrypted bytes be written to the device (Which I've previously done with TrueCrypt volumes). The concern being that I've decrypted a file, am working on it and someone pulls out the USB and leaves with it.

[tptacek]

If you're serious about protecting PDFs and stuff, encrypt them with PGP. It's much more annoying than using FDE systems like Truecrypt, but much more secure.

If you're not so serious that you're willing to manually encrypt and decrypt files (or ZIP archives of files), just use your OS's full disk encryption scheme. On a Mac, for instance, you can create virtual disks with AES-XTS and keys derived from passwords; that's built into the OS.

What people really want is some kind of transparent encrypted filesystem. That's a reasonable thing to want, and it would be more secure than Truecrypt. I don't know of a good one.

[chiph]

Exactly. While I could use PGP to encrypt individual files, that's really inconvenient for more than a handful. Putting them into ZIP-style archives introduces potential problems with data being written to temp files, etc. A container-based file system solution would be preferred.

It'd also be nice if it were cross-platform, since lots of people do use different operating systems during their day. I know I do. :)

Over the weekend I was looking at some of the commercial products that are positioning themselves as TC replacements. And most of them are a little too close to the military/govt for my comfort. I'd rather have something open source just for the ability to inspect the code, if nothing else.

[snowwrestler]

> What people really want is some kind of transparent encrypted filesystem.

Isn't that the promise of FileVault on a Mac? Is that not under discussion here because it's not good, or because it's not cross-platform? (In other words, should I not trust FileVault?)

[tP5n]

Asking if you should trust software X is like asking the internet if it'd be healthy for you to start running a marathon.

For starters, how would we know? The software in question is closed-source and has spotty docs as best - and more importantly: your trust in a software is something that only you can establish for yourself, irregardless if whatever number of people on the internet claim the product trustworthy.

Appelbaum on FileVault(1) in 2006: http://events.ccc.de/congress/2006/Fahrplan/attachments/1244...

[tptacek]

Filevault is AES-XTS sector-level crypto. It's what I use, and I like it fine, but I encrypt important stuff with PGP.

[tokenizerrr]

Truecrypt also offers a container filesystem, which is what I used to use. It's cross platform and it always served me well. It would create a virtual disk drive with the contents being stored in the encrypted container file.

[static_noise]

You want a full disc encryption which adds plausible deniability in the case the KGB sees you have an encrypted file named "Nuclear Launchcodes_2016_final2.docx" on your USB drive. Truecrypt has that - who else has it?

[LLWM]

No you don't. The scenario you have concocted is ridiculous.

[emiliobumachar]

The specific scenario is unlikely, but hiding file and folder names is definitely a great feature. A lot can be inferred from file and folder names in industrial espionage scenarios.

[LLWM]

If you're worried about someone inferring data from seeing files with leading names like "potential microsoft buyout.ppt", perhaps you should give your files less conspicuous names? Pretty much every organization concerned with security has figured this out long ago.

[Dylan16807]

Frankly I find the suggestion that I manually give every single file on my computer an inconspicuous name even more ridiculous than a document of nuclear launch codes.

Metadata is data too. It should be protected.

[tptacek]

Filename metadata absolutely does deserve protection! I'm not sure why it's become a ground truth that filesystem-level crypto must leak filenames.

[wyager]

For me, the much-increased convenience of mountable encrypted disks vastly outweighs the slightly-increased security of application-level encryption.

[diminoten]

Who said anything about full disk encryption? Certainly not the comment you replied to.

[tptacek]

Truecrypt is full disk encryption.

[skeeterbug]

It is not only full disk encryption. I have used a file container encrypted with financial information on linux and windows over the years. I can mount that file on either OS.

[tptacek]

Like Charles Dimino, you're not following the point. The security limitations of FDE come from doing crypto at the block layer. If your cryptosystem is giving something that (a) transparently encrypts and (b) mounts as a filesystem, it's block crypto, and shares the same problems as whatever cryptosystem unlocks your boot drive.

The problem is block-level crypto. It has nothing to do with whether it's layered on top of a hardware disk drive.

[diminoten]

You're obsessing over the crypto, but we're talking about the user experience. It's block-level crypto. We get that. No one cares, in the context of this conversation.

What you're not getting is that TrueCrypt offered a particular interface experience and cross-platform compatibility that doesn't exist elsewhere.

[tptacek]

You write as if the whole thread isn't there for people to see, and as if I had somehow responded to something you said rather than it being the other way around. You literally started this unproductive subthread by responding to the comment where I addressed the need for cross-platform things that work like Truecrypt does, and you've tried to built an argument by stipulating that security doesn't matter. Sorry, security is all that matters here.

[otakucode]

Is it still considered 'full disk' when its only used with a container file? I've never used TCs full-disk mode, but I've used it to quickly and easily create mountable disk images (even without encryption this would be handy). To my ear, 'full disk encryption' is something a hard drives firmware should be involved in.

[diminoten]

It's "block level" encryption.

Some folks call that "full disk encryption", but since there's a separate feature in TrueCrypt that calls itself "full disk encryption" and is actually encrypting the entire disk, to the point where TrueCrypt has to supply a boot loader to decrypt, it's probably reasonable to want to differentiate the two.

Thomas doesn't see the difference because it's all "block level" encryption, and apparently the only thing in the world that matters is crypto (rather than the presentation and adoption of crypto), but the difference is mainly in the boot loader aspect.

[Dylan16807]

What are you talking about? It needs a boot loader if it encrypts the OS partition, which is orthogonal to whether it encrypts entire physical discs or not. That feature is not called "full disk" anywhere I can see. "System Encryption" or something.

[diminoten]

> That feature is not called "full disk" anywhere I can see. "System Encryption" or something.

See above citation.

[diminoten]

No it's not, I use TrueCrypt all the time but not to encrypt my disk. Are you talking about the volume-level encryption TrueCrypt offers?

Are you really trying to suggest the world shouldn't have a tool like TrueCrypt out there?

[tptacek]

I have no idea why you think it's productive to litigate the difference between "block-level encryption" and "full-disk encryption", but if it makes you feel better we can just pretend we switched the terms, because my point applies equally to them --- they're synonyms.

I also have no idea where the "I'm telling the world there shouldn't be a tool like Truecrypt" came from. I think you've misread me.

[diminoten]

I never said you were telling the world anything.

I'm asking you a question to clarify your stance.

[diminoten]

And yes, there is value in noting the difference between block-level and full-disk encryption, mostly because they're different.

[tptacek]

Interesting. How?

[diminoten]

I changed my comment somewhat, because you're being very squirmy, as per usual.

Do you think something like TrueCrypt shouldn't exist?

[tptacek]

I'm not being "squirmy". You're playing a semantic game with the word "disk". The technical issue with FDE is that it works at the level of blocks, and so lacks information about message boundaries or the storage flexibility needed to (a) randomize the encryption and (b) store authenticators. Encrypt a physical disk, encrypt a file that pretends to be a mountable volume, same issues.

I get that not everyone understands the technical issues in designing storage encryption, but don't take that out on me.

[AngrySkillzz]

Full-disk encryption is block-level encryption. If you're using TrueCrypt to encrypt anything, you're using block-level encryption. There is no functional difference between them. If you are not encrypting your entire disk, then block-level encryption is a bad idea because 1) it doesn't provide authentication, and 2) block-level encryption (using strategies like XTS) is not as strong as regular authenticated encryption using CBC and a MAC or whatever.

If you're not using TrueCrypt for full-disk or full-volume encryption, you'd be better off using basically anything else. There are plenty of cross-platform tools for doing that kind of thing.

[tptacek]

Pedantic, but hopefully in a fun way:

Authentication is the biggest problem with sector-level crypto, but the other technical problem with encrypting sectors is that you don't get a place to store the metadata you'd need to randomize the encryption, and so you lose semantic security as well. If you squint at it the right way, XTS is the ECB mode of sector-level (wide-block) crypto schemes.

[diminoten]

Can you name some of those cross-platform tools?