Hacker News new | ask | show | jobs
Ask HN: TrueCrypt audit status?
185 points by mukmuk 4145 days ago
After raising over $70,000 from the community in October 2013, progress on the TrueCrypt audit has been fitful at best. The last update on http://istruecryptauditedyet.com was April 14, 2014.

Two key contributors, Matthew Green (https://twitter.com/matthew_d_green) and Kenn White (https://twitter.com/kennwhite) remain active on Twitter.

I am aware of VeraCrypt and CipherShed but these appear orthogonal to the original audit.

Does anyone know what the heck is going on?

5 comments

It's in a weird logistical state. I'll take a healthy chunk of the blame.

The TC audit project commissioned iSEC to do a formal code audit. That audit was completed professionally and efficiently. No smoking gun problems were found (several nits were, but nothing that would make it any easier to decide whether to trust the package).

That iSEC audit was the headline achievement for the project, so the fact that it was finished should reassure people worrying about whether the project did anything.

After the code audit, the project was supposed to move on to review the cryptography in TC. Which is where I come in.

Because the project was considering commissioning services from professional appsec firms, I recused myself from the project (at the time, I worked for a very large appsec firm). My feeling is that a better use of the TC project resources would be to set up some kind of crowdsourced audit slash bug bounty. When the code audit was completed, and after I had left Matasano, I volunteered to coordinate a crowdsourced crypto audit.

Unfortunately, I was also in the midst of starting a new company and recruiting cofounders and then the holidays hit and long story short things went off the rails.

There are two big paths forward for the TC project that I am aware of:

1. They can rekindle the crowdsourced crypto audit (I'd be happy to remain involved, or to talk to any other subject matter expert that wanted to do that job --- n.b., I was going to do the work gratis). If any kind of formal review of TC's cryptography is to be done, this is the way to do it; the project can't afford what it costs to retain professional cryptography engineers to review the code (real crypto security consulting costs a multiple of what appsec consulting does).

2. They can devote all the remaining funds to a public bug bounty for Truecrypt.

There may be options 3 or 4 that I'm not aware of. I have a decent relationship with Kenn and Matthew, but I have not been trying to keep myself in the loop on the project.

There you go: more than you wanted to know about the TC audit project!

None of it has much of anything to do with that weird announcement from last year.

Thanks Thomas.

This is Matt Green, one of the two people running the audit. As tptacek explained, we went down a few blind alleys following the public collapse of the Truecrypt (development) project.

In the last few weeks we've signed a contract to begin a commercial evaluation of the cryptography in Truecrypt. We've also been doing some internal evaluation of portions of the source code. For reasons related to getting the best price, the start date of the audit was allowed to drift forward a bit. This was necessary to make sure that the donated money stretches as far as possible.

Rather than giving all the details in an HN post, I'm going to write an update on my blog (blog.cryptographyengineering.com) but it won't be up until we've notified everyone involved that we're making the details public, probably around 4:30-5pm ET today.

Please do go ahead and post a link to HN when you do.
Also: speaking in no "official" capacity whatsoever, I'd advise you to stay away from the forks of Truecrypt.

Unless something new has come to light since last I looked, the licensing situation on the TC code is weird:

http://lists.freedesktop.org/archives/distributions/2008-Oct...

... which means there is a pretty strong disincentive for people with serious crypto and systems expertise to invest their time and energy building on it. You don't want to trust crypto platforms with built-in adverse selection problems.

Wow those are serious concerns, thank you for linking that.

Maybe they have an email list of the original donors and can propose some multiple choice options:

1 - bug bounty

2 - attempt to hire someone at a steeply reduced rate for the audit

3 - use the money to seed a complete replacement or a clean room rewrite if possible (this is a can of worms but given the license issues seems like the only realistic way forward... might need the help of FSF or ASF or the like)

There is pretty much zero chance that the TC audit project is going to sponsor a rewrite of Truecrypt. That's a project that would cost much more than the TC project has to spend.
It just seems futile to spend the money on TC. I get the number of users of it is huge and the money was donated for this specific purpose. Users of TC should already be looking to move away from it whether there's a vulnerability or not. Even if a vulnerability is found, how is it legally patched? Is it almost better not to know?

With the money left, maybe a smart fund-raiser could get some conversations started with bigger donors who could match grants and go in a large round. The money might buy you the time of a Bruce Schneier or Richard Stallman to advise and promote the project in its infancy. And non-profit software orgs are underpaid and work on shoestring budgets already that this is real money to them.

The money was contributed for a specific purpose, and Matthew and Kenn are scrupulous about ensuring that it gets used for that purpose. They actually can't take the money and use it as a seed for a different project. It isn't a slush fund.
If only the design/architecture would be contracted to experts and the actual implementation be written by the community how expensive would that be?

The experts shouldn't write any line of code, use the community as code monkeys, only accepting pull requests and merge them in the project(basically what Linus does this days). Would that not be feasible?

I don't think this would work. The details of how block-level crypto work are intimately connected to a bunch of fiddley systems programming details like bootup, power saving, and memory management. It's not nearly enough just to propose a workable design for how to make a virtual hardware-encrypted disk with XTS; you need to evaluate a lot of raw code, too.
@ghostly_s

I don't see this as the roadblock. They (the experts) could bill by the hour. The most intensive period is the initial specification/design/architecture. After the burst period they just have to review the commits for security pitfalls and merge them if OK. The community could have some volunteer reviewers for triage.

I have no idea if this actually works and I also didn't heard anything like this done before, so take it with a grain of salt. That's why I asked more knowledgeable people how feasible this could be.

So you're proposing keeping elite crypto expert(s) on the payroll for--what, years?--as they patiently wait for the community to build something that meets their standards? I'm not going to say such a person or people don't exist, but Linus is a rare sort; considering the market value of crypto experts' talents I think chances of finding someone willing to serve in such a role are rather slim.
Can we still safely use TC 7.1a?
The EFF seems to recommend using DiskCryptor for Windows [1]. What are HN's opinions on this?

Also what does HN think about still using TrueCrypt? Any reason not to?

[1]https://ssd.eff.org/en/module/how-encrypt-your-windows-devic...

Been mulling this over myself. Doubt anyone with a reputation would like to stake theirs to another 'solution' that may well turn out to be flawed. Plus the FDE approach seems broken in that machines have to be powered down etc.

I take the view that for my own threat model (i.e. someone nabbing my machine) DC, even TC would be perfectly adequate for that first layer of protection. Advice given by tptacek on using PGP individually for sensitive information (if I have understood correctly) could then be coupled to that FDE where required.

For my own purposes this would protect what needs protecting in terms of at-rest data. A vast improvement over the no-encryption situation.

SSDs with hardware encryption seem to be the new frontline defense for mainstream users such as myself. Same issues as with any FDE, I suppose, but coupled with filesystem PGP encryption ought to again offer adequate protection from opportunistic thieves.

So we all know Truecrypt is dead. What should we use instead?

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.

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/

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

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.

The ZFS crypto implementation (which isn't really available outside Oracle's Solaris) uses AES-GCM, which solves the authentication problem.
If you have filesystem encryption, block-level encryption is probably unnecessary. Filesystem encryption is in most ways superior to block-level crypto.
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.
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?
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?

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.

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.

I spent all last night searching for an answer to this question. I couldn't find one.
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?

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.

GP didn't ask for full disk encryption, only "mountable disk images" which are far more flexible to deal with in heterogeneous environments.
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.
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.
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.

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?
No you don't. The scenario you have concocted is ridiculous.
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.
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.
For me, the much-increased convenience of mountable encrypted disks vastly outweighs the slightly-increased security of application-level encryption.
Who said anything about full disk encryption? Certainly not the comment you replied to.
Truecrypt is full disk encryption.
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.
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.

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

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?

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.

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.

On which OS? Unless your adversaries are state actors BitLocker on Windows works just fine for both the internal and any removable drives.

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

There is TrueCrypt,the binary application and TrueCrypt,the on-disk format.

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.

[1] https://github.com/bwalex/tc-play

VeraCrypt seems a successful fork, cross platform and supporting truecrypt containers.
Didn't TrueCrypt throw in the towel?
As far as I know the audit project was abandoned when the TrueCrypt developer did his dramatic exit. Cannot remember a source for that though.
No, the project was not "abandoned" like that. What source told you that?
The wording on the top of http://truecrypt.sourceforge.net/ leads me to believe that TrueCrypt is no longer being developed, and bugs (including vulnerabilities) are not being fixed.

If that's the case, what's the purpose of of the audit?

Thank you, tptacek, for the huge amount of time you're spending answering questions in these threads.

Lots of people still depend on Truecrypt, and have depended on it the past, and those people need to know whether it was ever safe to do that, and how urgent it is for them to migrate to something better.
That makes a lot of sense. Thanks!
Apparently none! Apparently that idea made it into my head somehow, I must've just jumped to conclusions and assumed I read it somewhere. Oops!