I don't know of any other software that provides cross-platform, encrypted, and mountable disk images. We have Bitlocker, Filevault, and Luks, but none of these work (easily, at least) on different platforms.
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:
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?
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.
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.
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.
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?)
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...
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.
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.
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.
Metadata is data too. It should be protected.
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?
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.
Just having the filnames is an serious risk.
Are you really trying to suggest the world shouldn't have a tool like TrueCrypt out there?
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.
Do you think something like TrueCrypt shouldn't exist?
I get that not everyone understands the technical issues in designing storage encryption, but don't take that out on me.
I'm asking you a question to clarify your stance.
So yes, it's not just about the crypto...when the crypto works. But when the crypto is insecure, which is what tptacek is saying, then yes, it is ONLY about the crypto.
NB: I'm plenty qualified on UX and general technical matters, but on whether crypto is secure, I defer to the experts.
http://blog.cryptographyengineering.com/2015/02/another-upda...
My only point has been that Thomas, et. al. have been telling us we don't want something like TrueCrypt, despite the fact that we very clearly do. His suggestion of "just use PGP and FS level encryption" is absurd, but NOT from a crypto standpoint (I, like you, defer to Thomas and the other experts on the integrity of the crypto itself). It is, however, absurd from a UX/workflow standpoint.
They did not "only get their act together today". They've thought about Truecrypt far more rigorously than you have, and for far, far longer.
You've been almost completely unable to explain in technical terms what "UX" you want from sector-level crypto that you couldn't get from filesystem crypto. When pressed, you in effect say "yeah, well, name a tool that does that".
The fact that your only options today are [insecure, easy] and [secure, difficult] does not mean that there is no [secure, easy] option possible. But militating in favor of insecure crypto goes a long way towards hiding that possibility from everyone.
This isn't a pedantic point. Ross Ulbricht just got reamed in federal court because a simple physical arrest compromised virtually every secret he had. Why? Because he was relying on sector-level all-or-nothing crypto. By encouraging people to rely on tools like Truecrypt, you are, in a very small but real way, endangering them.
I was just reading it, and that's exclusively I was referring to. I look forward to the results and am grateful of the time they're spending. I hope they find nothing.
Not sure why you made this about me personally.
https://www.dropbox.com/s/hy5wj0t1t84hlk4/Screenshot%202015-...
I stand by what I just wrote.
Your comments in this thread come off as ridiculously aggressive. I'm not sure if you're aware of that.
I thought I did a better job of dealing with that for the most part, however. Maybe not.
TrueCrypt lets you create fixed sized encrypted volumes, and allows you to decrypt those volumes on any of the three major OS platforms.
There's nothing special about TrueCrypt in how it performs the encryption/decryption (or so we're told), but no tool besides TrueCrypt allows such a flexible approach.
And it's you who refuses to accept that [secure,easy] can exist, because it'd make you irrelevant. It's a completely silly stance to take, but it's yours.
But hey, at least I've wrung your opinion on TrueCrypt out of you:
> By encouraging people to rely on tools like Truecrypt, you are, in a very small but real way, endangering them.
For posterity, in case you edit it away.
Which leads me to the question: Why are you even involved in the TrueCrypt audit, if you think it's a bad idea to use such tools?
P.S. Ulbricht was caught because the FBI owned TOR, and that's about it. Maybe your indignation towards TrueCrypt should consider Snowden's use of TrueCrypt to evade the combined allied world's intelligence community.
It's amusing that you feel you've "wrung out" of me something one of the few things I've recently blogged at length about.
You've blogged, "Don't use TrueCrypt"?
And no, I blogged "don't use sector-level crypto". In a post literally titled "You Don't Want XTS". Under the subhed "Disks Are The Last Thing You Want To Encrypt". As in, "the last thing in the world".
Edit:
Having re-read the thread, you haven't explained why you're involved in the TrueCrypt audit, or why you recommend folks use TrueCrypt if you think XTS is bad.
If you'd care to elaborate beyond, "nuh uh", I'm sure we'd all be glad to hear it.
> This piece is written for software designers, not end-users. If you’re an end-user looking for crypto advice: use Truecrypt, use Filevault, use dm-crypt
I really just don't get why you'd, in one breath, decry XTS, and then in that same breath, recommend people use TrueCrypt, which is, as you call it, "the best-known implementation of XTS".
Maybe just lead me to the water on this one. It's really the only thing left unresolved in our conversation.
What's weird to me is why we have a gigantic thread dedicated to the precise nuances of what I think about Truecrypt. Isn't this incredibly boring?
That is not accurate.
More importantly, his physical security was lacking, as he hadn't properly considered the threat model. If he'd been working in a secured area (like a locked room) where open laptop snatching was infeasible, that would have given him enough warning to close the lid, and maybe pop the battery out. Albeit still vulnerable to a cold boot attack, if law enforcement have such capacity.
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.
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.
The problem is block-level crypto. It has nothing to do with whether it's layered on top of a hardware disk drive.
What you're not getting is that TrueCrypt offered a particular interface experience and cross-platform compatibility that doesn't exist elsewhere.
"The term "full-disk/on-disk encryption" is often used to signify that everything on a disk is encrypted, including the programs that can encrypt bootable operating system partitions."
Are you going to tell Markus Gattol he's wrong? No? Good, let's move on.
What matters here is the security, and the adoption rate of TrueCrypt is/was through the roof, because of how it allowed folks to move encrypted volumes across various platforms without much hassle.
What you wrote seems to intimate there's no actual need or value in moving encrypted volumes across platforms, and that if folks actually want to do that they should just encrypt individually and at a FS level and do so using PGP, which has existed for years, and whose adoption rate and ease-of-use are both, compared to TrueCrypt, through the floor.
The fact is, people want to move encrypted volumes across platforms. It's not more secure than anything else, but it presents a workflow that might actually be more secure, due simply to it's ease of implementation.
You're right, security is all that matters here, and folks aren't going to be secure if it remains impossibly difficult to be secure.
Block-layer encryption, also known as "whole disk encryption", "on-disk encryption" or "full-disk encryption"
I think you're just trolling. Sorry, I didn't even finish reading your comment.
Amusingly (edit: given how you cited it), there is in fact cryptographic stuff wrong in that article.
The rest of my comment frankly wasn't for you, it's for the folks reading what you write and blindly accepting it. At least now they can see how petulant you can be when facing differing points of view.
I shouldn't have tilted. :(
Oh yeah? That it wasn't personally endorsed by you?
http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf
You'll know the part I'm referring to because it reads practically as a response to a chunk of Gattol's page; it's a problem shared by the Wikipedia coverage on full-disk encryption.
Being cagey about it (i) motivates you to actually read the paper and (ii) avoids what would inevitably be an extremely unproductive debate.
(This is a fantastic survey, by the way; if you're interested in crypto, bookmark it forever.)
My amusement about Gattol's page has nothing to do with Gattol; it's just the way his page got used in this thread by someone else, as a sort of rhetorical "fatality" move. I'm confident Gattol is much smarter than I am. I say that because Dimino also tried to take this thread to Gattol on Twitter, too. :)
Furthermore, this is devolving into a schoolyard, "I know but I'm not telling" situation. To put it another way, I don't think there is any significant error in the Gattol's page, nor is there any significant error on the wikipedia page on full-disk encryption.
I'm very glad to be shown to be incorrect on this point, but I doubt I would be, at least by you.
I'm interested in this area, both professionally and as a genuine curiosity, but every time I run into you it's a negative experience. I'd like that to stop happening.
But hey, I'm not ultimately the guy who wrote the article. I've poked both the author and Thomas on twitter -- maybe Thomas can help the author correct any inaccuracies. You, too, could help I'd imagine, if you would be more specific about the issues. I'm guessing the author wouldn't want his article to remain inaccurate if folks could point out the specific issues.
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.
See above citation.
Yes it's not perfect and if you use it and let your devices to go to sleep rather than power off you are vulnerable to various memory access and coldboot attacks.
However with TPM/USB Storage for the keys, with secure boot enabled Bitlocker offers one of the better data encryption capabilities out there.
Yes MSFT might have backdoored it, TPM is an oxymoron and all that might be true. However if the only thing you are worried about is what happens to your data if your device gets lost or stolen you are probably more than fine with using this setup.
If you are worried about the NSA having your files well then probably there isn't much you can do about it if they want them they'll get them. Whether its by backdooring your OS, internet connection, or by sending intelligence support activity assets to your home to tap into it while you sleep :)
TrueCrypt,the binary application is the one that is dead but its on-disk format will probably live on as a cross platform on-disk format as there are other projects out there that are supporting it and more projects will probably follow.
tcplay[1] is one of the projects that have full support for TrueCrypt,the on-disk format.
If you already have a TrueCrypt volume and you dont want to use TrueCrypt,the binary application,then you can search for these alternatives and start using them.