Category: Truecrypt

Truecrypt report

A few weeks back I wrote an update on the Truecrypt audit promising that we’d have some concrete results to show you soon. Thanks to some hard work by the NCC Crypto Services group, soon is now. We’re grateful to Alex, Sean and Tom, and to Kenn White at OCAP for making this all happen.

You can find the full report over at the Open Crypto Audit Project website. Those who want to read it themselves should do so. This post will only give a brief summary.

The TL;DR is that based on this audit, Truecrypt appears to be a relatively well-designed piece of crypto software. The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.

That doesn’t mean Truecrypt is perfect. The auditors did find a few glitches and some incautious programming — leading to a couple of issues that could, in the right circumstances, cause Truecrypt to give less assurance than we’d like it to.

For example: the most significant issue in the Truecrypt report is a finding related to the Windows version of Truecrypt’s random number generator (RNG), which is responsible for generating the keys that encrypt Truecrypt volumes. This is an important piece of code, since a predictable RNG can spell disaster for the security of everything else in the system.

The Truecrypt developers implemented their RNG based on a 1998 design by Peter Guttman that uses an entropy pool to collect ‘unpredictable’ values from various sources in the system, including the Windows Crypto API itself. A problem in Truecrypt is that in some extremely rare circumstances, the Crypto API can fail to properly initialize. When this happens, Truecrypt should barf and catch fire. Instead it silently accepts this failure and continues to generate keys.

This is not the end of the world, since the likelihood of such a failure is extremely low. Moreover, even if the Windows Crypto API does fail on your system, Truecrypt still collects entropy from sources such as system pointers and mouse movements. These alternatives are probably good enough to protect you. But it’s a bad design and should certainly be fixed in any Truecrypt forks.

In addition to the RNG issues, the NCC auditors also noted some concerns about the resilience of Truecrypt’s AES code to cache timing attacks. This is probably not a concern unless you’re perform encryption and decryption on a shared machine, or in an environment where the attacker can run code on your system (e.g., in a sandbox, or potentially in the browser). Still, this points the way to future hardening of any projects that use Truecrypt as a base.

Truecrypt is a really unique piece of software. The loss of Truecrypt’s developers is keenly felt by a number of people who rely on full disk encryption to protect their data. With luck, the code will be carried on by others. We’re hopeful that this review will provide some additional confidence in the code they’re starting with.

Another update on the Truecrypt audit

There’s a story on Hacker News asking what the hell is going on with the Truecrypt audit. I think that’s a fair question, since we have been awfully quiet lately. To everyone who donated to the project, first accept my apologies for the slow pace. I want to promise you that we’re not spending your money on tropical vacations (as appealing as that would be). In this post I’d like to offer you some news, including an explanation of why this has moved slowly.

For those of you who don’t know what the Truecrypt audit is: in late 2013 Kenn White, myself, and a group of advisors started a project to undertake a crowdfunded audit of the Truecrypt disk encryption program. To the best of my knowledge, this is the first time anyone’s tried this. The motivation for the audit is that lots of people use Truecrypt and depend on it for their security and safety — yet the authors of the program are anonymous and somewhat mysterious to boot. Being anonymous and mysterious is not a crime, but it still seemed like a nice idea to take a look at their code.

We had an amazing response, collecting upwards of $70,000 in donations from a huge and diverse group of donors. We then went ahead and retained iSEC Partners to evaluate the bootloader and other vulnerability-prone areas of Truecrypt. The initial report was published here.

That initial effort was Part 1 of a two-part project. The second — and much more challenging part — involves a detailed look at the cryptography of Truecrypt, ranging from the symmetric encryption to the random number generator. We had some nice plans for this, and were well on our way to implementing them. (More on those in a second.)

Then in late Spring of 2014, something bizarre happened. The Truecrypt developers pulled the plug on the entire product — in their typical, mysterious way.

This threw our plans for a loop. We had been planning a crowdsourced audit to be run by Thomas Ptacek and some others. However in the wake of TC pulling the plug, there were questions. Was this a good use of folks’ time and resources? What about applying those resources to the new ‘Truecrypt forks’ that have sprung up (or are being developed?) There were a few other wrinkles as well, which Thomas talks about here — although he takes on too much of the blame.

It took us a while to recover from this and come up with a plan B that works within our budget and makes sense. We’re now implementing this. A few weeks ago we signed a contract with the newly formed NCC Group’s Cryptography Services practice (which grew out of iSEC, Matasano and Intrepidus Group). The project will evaluate the original Truecrypt 7.1a which serves as a baseline for the newer forks, and it will begin shortly. However to minimize price — and make your donations stretch farther — we allowed the start date to be a bit flexible, which is why we don’t have results yet.

In our copious spare time we’ve also been looking manually at some portions of the code, including the Truecrypt RNG and other parts of the cryptographic implementation. This will hopefully complement the NCC/iSEC work and offer a bit more confidence in the implementation.

I don’t really have much more to say — except to thank all of the donors for their contributions and their patience. This project has been a bit slower than any of us would like, but results are coming. Personally, my hope is that they’ll be completely boring.

An update on Truecrypt

Several people have been asking for an update on our public audit of the Truecrypt disk encryption software. I’m happy to say that the project is on track and proceeding apace. Here I wanted to give a few quick updates:

  1. Thanks to the amazingly generous donations of 1,434 individual donors from over 90 countries, as of today, we’ve collected $62,104 USD and 32.6 BTC* towards this effort. This is an unbelievable response and I can’t thank our donors enough. I’m blown away that this is happening.
  2. We’ve assembled a stellar technical advisory board to make sure we spend this money properly and generally to keep us honest. More details shortly.
  3. In order to make best use of the donated funds and manage on-going governance of the project, we’ve incorporated as a non-profit corporation in North Carolina—the Open Crypto Audit Project (OCAP)—and are currently seeking 501c(3) tax-exempt designation. Board members include myself, Kenn White (who has been doing most of the heavy organizational lifting) and the amazing Marcia Hoffman. We have high hopes that OCAP will find a purpose beyond this Truecrypt audit.
  4. The Open Technology Fund has generously agreed to donate a substantial amount of contracted evaluation time to our effort
  5. And finally, the most exciting news: we’ve signed a first contract with iSEC partners to evaluate large portions of the Windows software and bootloader code. This review will begin in January.
Despite the progress above, there’s still a lot of work to do. The iSEC review will cover a lot of the thorniest bits of the code, but we are still working to audit the core cryptographic routines of Truecrypt and move the project onto a secure (deterministic) build footing. We hope to have further announcements in the next few weeks.

Let me add one more personal note.

I usually take a pretty skeptical attitude on this blog when it comes to Internet security. For the most part we do things wrong, and I used to think most people didn’t care. The fact is that I was wrong. If the response to our audit call is any evidence, you do care. You care a lot.

Donations (click to enlarge)

I can’t tell you how amazed I am that any of this is happening. As far as I know, this is the first time that the Internet has come together in this way for the purposes of making us all a bit safer. I hope it’s the beginning of a trend.

More updates to come.

* Incidentally, determining the dollar value of BTC is fun, fun fun. We’ve been trying to responsibly sell these at the ‘best’ price. But, ugh.

Let’s audit Truecrypt!

A few weeks ago, after learning about the NSA’s efforts to undermine encryptionsoftware, I wrote a long post urging developers to re-examine our open source encryption software. Then I went off and got distracted by other things.

Well, I’m still distracted by other things, but people like Kenn White have been getting organized. Today I’m proud to announce the result. It is my great pleasure to publicize (and belatedly kick off) an open project to audit the Truecrypt disk encryption tool.

If you already know why this is important, by all means stop reading this post now. Go to the site and donate! It doesn’t have to be money, although that would be best. If you’re an information security professional/expert/hobbyist please consider giving us some of your time to help identify bugs in the software.

In case you don’t see the reason for a Truecrypt audit, I’m going to devote the remainder of this post to convincing you how important it is. And who knows, maybe I’ll even convince you we can do more.

Why audit Truecrypt?

In case you haven’t noticed, there’s a shortage of high-quality and usable encryption software out there. Truecrypt is an enormous deviation from this trend. It’s nice, it’s pretty, it’s remarkably usable. My non-technical lawyer friends have been known to use it from time to time, and that’s the best ‘usable security’ complement you can give a piece of software.

But the better answer is: because Truecrypt is important! Lots of people use it to store very sensitive information. That includes corporate secrets and private personal information. Bruce Schneier is even using it to store information on his personal air-gapped super-laptop, after he reviews leaked NSA documents. We should be sweating bullets about the security of a piece of software like this.

So what’s wrong with Truecrypt?

Maybe nothing at all. Rest assured if I knew of a specific problem with Truecrypt, this post would have a very different title — something with exclamation points and curse words and much wry humor. Let me be clear: I am not implying anything like this. Not even a little.

The ‘problem’ with Truecrypt is the same problem we have with any popular security software in the post-September-5 era: we don’t know what to trust anymore. We have hard evidence that the NSA is tampering with encryption software and hardware, and common sense tells us that NSA is probably not alone. Truecrypt, as popular and widely trusted as it is, makes a fantastic target for subversion.

But quite frankly there are other things that worry me about Truecrypt. The biggest one is that nobody knows who wrote it. This skeeves me out. As Dan Kaminsky puts it, ‘authorship is a better predictor of quality than openness‘. I would feel better if I knew who the TrueCrypt authors were.

Now please don’t take this the wrong way: anonymity is not a crime. It’s possible the Truecrypt developers are magical security elves who are simply trying to protect their vital essence. More prosaically, perhaps they live in a country where privacy advocates aren’t as revered as they are in the US. (I kid.)

But anonymity isn’t the only thing that concerns me about Truecrypt. For one thing, the software does some damned funny things that should make any (correctly) paranoid person think twice. Here I will quote from the Ubuntu Privacy Group’s review of Truecrypt 7.0:

[T]he Windows version of TrueCrypt 7.0a deviates from the Linux version in that it fills the last 65,024 bytes of the header with random values whereas the Linux version fills this with encrypted zero bytes. From the point of view of a security analysis the behavior of the Windows version is problematic. By an analysis of the decrypted header data it can’t be distinguished whether these are indeed random values or a second encryption of the master and XTR key with a back door password. From the analysis of the source we could preclude that this is a back door… As it can’t be ruled out that the published Windows executable of Truecrypt 7.0a is compiled from a different source code than the code published in “TrueCrypt_7.0a_Source.zip” we however can’t preclude that the binary Windows package uses the header bytes after the key for a back door.

Which of course tees up the most important concern: even if the Truecrypt source code is trustworthy, there’s no reason to believe that the binaries are. And many, many people only encounter Truecrypt as a Windows binary. In my very humble opinion that should worry you.

In short: there are numerous reasons we need to audit this software — and move its build process onto safe, deterministic footing.

What’s your plan?

The exact terms are still a work in progress, but our proposal breaks down into roughly four components:

  1. License review. Truecrypt uses an odd, potentially non-FOSS license. We’d like to have it reviewed by a competent attorney to see how compatible it is with GPL and other OSS software.
  2. Implement deterministic/reproducible builds. Many of our concerns with Truecrypt could go away if we knew the binaries were compiled from source. Unfortunately it’s not realistic to ask every Windows user to compile Truecrypt themselves. Our proposal is to adapt the deterministic build process that Tor is now using, so we can know the binaries are safe and untampered. This is really a precondition to everything else. And it’s not an easy process.
  3. Pay out bug bounties. Not every developer has time or money to audit the entire source. But some have a little time. If we collect enough, we’d like to compensate bug hunters a little bit for anything security critical they find in the code.
  4. Conduct a professional audit. The real dream of this project is to see the entire codebase receive a professional audit from one of the few security evaluation companies who are qualified to review crypto software. We’re hoping to convince one of the stronger companies to donate some time and/or reduced rates. But good work doesn’t come free, and that’s why we’re asking for help.

We don’t expect any single person to do all of this. The exact balance of payouts from our collected fund is still TBD, but we will be formalizing it soon. We also want specialists and experts, and we also want people to donate their time wherever possible.

We deserve better tools than what we have now. Done correctly, this project makes us all stronger.

Aren’t you worried you’ll insult the Truecrypt developers?

I sure hope not, since we’re all after the same thing. Remember, our goal isn’t to find some mythical back door in Truecrypt, but rather, to wipe away any doubt people have about the security of this tool.

But perhaps this will tick people off. And if you’re one of the developers and you find that you’re ticked, I’ll tell you exactly how to get back at us. Up your game. Beat us to the punch and make us all look like fools. We’ll thank you for it.

Wait, if we can do this for Truecrypt, couldn’t we do it for other software?

And now you’ve seen the true promise of this plan. Help us make it work for Truecrypt. Then let’s talk.