in Truecrypt 1,215 Words

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.

71 thoughts on “Let’s audit Truecrypt!”

  1. Easiest first step might be to get some open source and commercial code analyzers to sift through the source. Any flaws or warnings could be potential security flaws.

    Most commercial code analyzers will provide a free license for individuals/groups that work on open source code.

  3. Will the results of the audit be made public, and what level of transparency can we expect from the overall project? I'm interested in helping sponsor, but these things matter a great deal as well.

    Regardless of the above, good luck – and I certainly do hope the plan succeeds beyond anyone's wildest dreams such that this becomes something very, very common for other important projects.

  5. I would rather see the cryptographic community shift focus on validating/auditing security platforms to proving security platforms are secure against an adversarial model. All the validation in the world (e.g. KATS, FIPS validation) won't necessarily prove security against certain attacks.

    The way forward is to have a conference which roadmaps an adversary model (e.g. cold boot attack, cache timing attacks, side channel attacks, etc.) that improve annually in which software platforms need to prove themselves resistant against.

    Provable validation is a must if the public wants genuine security, privacy, and cryptography.

  6. Hmm. Once you click “Next” on that link, things do start to become… concerning, don't they. 😦 At least at the time that stuff was written it sounds like the license was written the way it was on purpose, which is even worse.

  7. Why not both? I'd like an audit to assure us that there's no backdoor, AND secure encryption in general.

  8. Google currently issued a plan to harden some critical open software, why not ask google to pay for this project?

  10. This will never work. If the NSA want's into your cell phone or PC, there's nothing you can do about it. Google won't fund this, the NSA has people at Google writing back doors into their software. Internet encryption isn't about being secure, it's about being secure enough so the NSA doesn't want to waste their efforts on you.

  12. Audits are nice and we've been doing those for years. They're not sufficient and they haven't been. More audits on software isn't going to this new level of intrinsic value (e.g. RSA BSAFE has FIPS 140-2 validation assurance, but guess what? that doesn't imply that their default RNG wasn't distinguishable from a psuedorandom function) .

    By probing security I'm not talking about just encryption, but implementations networking standards as well. The new tool needed is using SMT based verification tools that can be used to prove security of softwares and the compilers that build the softwares.

  13. I am confused. Why is TrueCrypt not 'actual' open source? You go to the website, you can download the C++ source code. What makes it not true OSS?

  14. TrueCrypt is a program with available source code, but a lot of people argue that it doesn't count as real “open source” because it has a somewhat unusual license instead of a standard one (e.g. GPL or BSD).

    This isn't really a problem from an auditing perspective. Auditing a more regularly licenses open source program might be better in the general sense, but TrueCrypt is by far the most popular program in this segment despite the license, so auditing it makes the most sense. The goal here seems to be security, not fighting some open source ideological battle.

  18. In your opinion, Matthew, are the encrypted file systems in open-source linux distros more “trustworthy” and still as strong as TrueCrypt? I think, for example, in Ubuntu you can select EXT encrypted as an option when you install…

  19. What about compiling the sources and using a PE-file diff tool. I have heard that such things exist. They are being used by crackers to find vulnerabilities after software was patched by the vendor. Usually, only a few functions changed. here, we'd expect zero changes.

  21. Oh yeah, ask company bound by us law to audit and trust their analysis, maybe ms and apple can OK it too

  22. I want to volunteer and collaborate with others on code audit, but there's only info about donating money. Where do I go to coordinate with other participants about the audit?

  23. That is step 1. step 0 (if you care about Windows — I don't!) is to run that Windows Truecrypt through a debugger, to verify just where those bytes are coming from, since it sounds like the binary deviates from the behavior specified by the source code.

  24. See Anonymous post at October 14, 2013 at 3:00 PM.
    I don't think there's a denial that the software is open source actually, the source is indeed there. But it may not be *free* open source software, there apparently are a few clauses that Redhat had enough concern about in 2008 to ban the software from Redhat, some of which are still there. In short they nitpicked over a few ambiguous clauses about redistribution, but the one that really made them flip was: “NOTHING IN THIS LICENSE SHALL IMPLY OR BE CONSTRUED AS A PROMISE, OBLIGATION, OR COVENANT NOT TO SUE FOR COPYRIGHT OR TRADEMARK INFRINGEMENT.”

    They requested “COPYRIGHT OR” be taken out back in 2008, saying this sentence basically makes the whole license void.

  27. Gladman is not the author of truecrypt.. He has written some routines for aes but he hasn't written the program. The authors of the program Truecrypt are anonymous.. And at first the registered Truecrypt in Czech Republic under name of David Tesařík which is a name that doesn't really exist…

  30. Specifically for security-related applications, such as TrueCrypt, I believe that a Free Software license is a more appropriated than an Open Source license. A BSD license doesn't guarantee that someone or some company will have to make the source code available when distributing a binary.

  33. you know – as for a larger debate on this *type* of activities – no one in the public cares. We've seen in the past few months that our communications aren't private and that entities are making sure that stays that way. JohnQ doesn't care. Even in the light of worldwide storage of all electronic communication, no one cares.

    From an engineering viewpoint this is interesting, from a global sociological perspective it is fruitless.

    We would be better off smashing the printing presses and starting anew.

  35. Seems like the missing step is for more Windows users to compile this for themselves. Yes, not necessarily easy for most. But maybe we could get a bunch of sources for “trusted versions”. Then the audit task goes back to the source where the procedure is much better understood and transparent (and translates to more OSes).

  37. While such code analyzers might find some violations of bad practice, they most certainly won't find any intentionally placed and reasonably concealed backdoors.

    Also, the article clearly states that the problem doesn't have to be in the source code that is published separately, because there is no easy way to determine if the Windows binary is even the result of a compilation of the unmodified source code.

    There could be very good reasons to fill the empty space with encrypted random data, instead of encrypted zero data; the latter would provide a large block of encrypted known plaintext, which might facilitate some types of cryptanalysis.

    On the other hand, the encrypted random data might leak information from the key and/or the internal state of the random number generator, both of which would help an adversary who has intricate knowledge of the nature of this block.

    Maybe it would have made more sense to just fill the block with either zeros or (pseudo-) random data from some source other than one used to generate the keys from, but that might have ruined the plausible deniability, because it would be a clear signature of a truecrypt volume.

  38. This is great idea. Just recently (and not unrelated to the NSA scandal) I was looking at secure cloud storage for personal data. I have google drive, and could not find any reference to encryption on google's part, other than SSL. However, I did find other fee-based services, which do, such as SpiderOak and Wuala.

    But I didn't want to pay for yet another service, when I have many Gbs in Google drive. It turns out that CryptSync, an open source project, can be used to encrypt your data locally and sync it to google drive, or dropbox.

    The thing though: it uses 7zip as a binary drop-in replacement, which handles compression and encryption.

    So your security is only as good as 7zip, which, AFAIK, is maintained by 1 individual, who rolls his own AES implementation. Doesn't seem all that secure to me.

    So what I did was modify CryptSync to use GnuPG's gpg binary, which also handles AES and compression, and is more open and standardized.

    Anyway, my 2c.

  42. I'm surprised that the people behind this idea haven't decided to start a campaign on the largest crowdfunding site: Kickstarter
    Independently of all the other campaigns, you should definitely also start one in Kickstarter.
    Funding can go from 10-1000 times more.

  43. If you want to review the license of TrueCrypt, you may wish to contact Norman S. Kinsella ( http://www.kinsellalaw.com/about/ ). Mr Kinsella is a patent attorney with an extensive amount of legal knowledge relating to intellectual property, computers, electronics, and software. In addition to this, he specializes in contract law.
    I'm sure he could assist you with a legal review of the license.

  44. “I have not looked at the TrueCrypt license (in depth) in quite some
    time, but when Fedora and Red Hat reviewed it in 2008,”
    http://projects.opensource.org/pipermail/license-discuss/2013-October/001294.html

    I LOVE that ..
    He STARTS with admitting that he doesn't know what he is babbling about. ! And that he hasn't bothered to keep up to date since 2008 .
    The TC-license IS Open-Source, anybody can download the source-code, make the changes they want and redistribute their changes, as compiled binaries, as source-code or both .

    What you can NOT do is :
    1 . Call it True Crypt .
    2. Use the TrueCrypt Icon

    It is well-known that certain 'dark areas' of the FOSS-community are fundamentalists, it is also well-known that Open Source IS a business-model . These guys just want to force everybody to use THEIR software – And until Linus removes that NSA-backdoored PRNG from the Linux-kernel, the fundamentalists should just STFU !

  45. TrueCrypt isn't 'Internet encryption' .
    Please don't let your mouth run on subjects you have no knowledge about !

  46. No, not as long as Linus wont remove the NSA backdoored PRNG completely from the Linux-kernel !

  47. What is your point, other than spreading defeatism ?
    TrueCrypt has nothing to do with your 'communications' .
    Get it ?
    TrueCrypt IS NOT USED TO SECURE ONLINE COMMUNICATIONS !

  49. Instead of looking at the big mess of code of truecrypt. why don't you extend luks or gbde (from bsd) to a point with opensource, where it could replace truecrypt?

    write something in C or Go or stuff like that with OpenSSL/libsodium (nacl in portable) and put it under bsdl-2clause. and document it with git and CI from the start up.

    … said the insane floss developer-newbie

  50. There's no need for end users to compile themselves. There should be a few experts who compile each version and compare the resulting binaries. There should only be trivial changes to the official version.

  51. Since a lot of people rely on it, sure, auditing TrueCrypt is a good idea.

    Of course, if you really want top-notch security and are a little bit of a geek, OpenBSD is hard to beat. That OS undergoes continuous audit, since its inception, and they're not exactly “fans” of the US Dept. of Defense.

    And as for Linus including that patch from Intel to trust Intel's hardware RdRand chip, well, I don't use Intel chips anyway, so it doesn't sound like this affects me. Besides, the CPU's, ROM BIOSes, North/Southbridges, video chipsets, and NIC's themselves could all be bugged, so we don't have much choice but to trust the hardware. So, I'll stick with Linux's encryption on my non-Intel systems.

    –SYG

  52. The solution I would propose is to ensure that the procedures to compile TC are public, well documented, and repeatable.

    Then one can focus efforts on evaluating the source code for vulnerabilities and thoroughly documenting how the code works. With global peer review I would have a better assurance that the code is clean and this will lead to a better overall product.

    Subsequent to that we can monitor the source code for changes in future versions and ensure the reasons for the changes are explained.

  53. Prof Matthew Green,
    I 100% agree with you on this project “Let's audit TrueCrypt”. We should be very careful after the “September-5”. After reading your article, I hesitate to install TrueCrypt on my computer. Probably it's safer for me to buy a new laptop having the Trusted Platform Module (TPM) chip and use the TPM software to encrypt my files.
    Thank you for your information.

  56. What bothers me is that last step 4, a professional audit. If the major commercial encryption program providers and Microsoft have been pressured to provide backdoors, what is to stop any government entity from subverting the results of a single auditing corporation by pressuring it to come up with a report that just happens to miss one critical piece of information that shows an exploitable weakness. Who will be watching a single source auditor?

  57. Concerning FIPS validations, isnt it strange that certifying an encrypted hardware device require preloaded keys?

  59. This is great. I have had my reservation about TC, but you helped to alleviate most of them. Now, as you say, it is time for source code analysis. Thanks

  60. As a professional Windows XP developer, I tried for a month to compile tc on windows, it is an impossible task. I had to download dozens of compilers as indicated in the source, and I was unsuccessful, nor have I ever been able to find anyone else who has been able to compile it on windows and willing to share the binaries.

  61. Building the TC binaries is not that difficult. Having a MSDN subscription is an advantage. Sharing the binaries is against the license. New is that you should compile TC as soon as possible and archive those binaries for later evaluation due to future OS updates.

  62. Good luck with this, but I am not optimistic. Who is to say the auditors will not be coerced by the NSA's “SIGINT enabling project?” We know NSA has already compromised at least one popular “encryption chip” (the name of the specific chip was blacked out by the Guardian for some weird reason).

    The truth is, if NSA is your adversary, you have already lost. They have far more PhD's and far more money than what any public group could ever hope to muster. Not to mention they have decades of classified research under their belts — and we know they were at least 20 years ahead of the academic community at one point (differential cryptanalysis for instance). NSA insiders have said that NSA is still “a number of years ahead” in regard to cryptanalysis.

    Even if this project gives Truecrypt a clean bill of health, it doesn't make much of a difference because no one really knows what NSA's capabilities are. Perhaps the whole foundation of modern crypto theory is flawed in a way only NSA understands (ciphers, protocols, PRNG's, etc). After all, we now know they influence standards wherever they can.

    The point is such audits will never satisfy the (rightfully) paranoid and you can never prove a negative. And the Truecrypt authors are notoriously secretive and do not take kindly to bug reports. They also do not publish detailed changelogs and do not give credit to people who report bugs. So even if this audit finds serious flaws, there is no guarantee they will be fixed and no one knows if it is legal to fork the TC project and GPL it.

    I have resigned myself to the reality that encryption is mostly useless (at least against foes like NSA). If they want your data, they will get it. Sure it is probably good enough to protect you from Joe Hacker or your kid sister, but it's probably good enough to do that without expensive code audits.

  63. FUD is the most powerful weapon of the UN's surveillance bureaucrats. A pessimist gives in, but an optimist looks what can be done about it. I doubt that they can compromize a professional and reproducable audit procedure without smashing society.

  64. That was what I thought at first, but then I remembered that Kickstarter is for 'creative' projects. I personally don't class auditing encryption software code as a 'creative' project.

  65. Sorry if this question is stupid, but how can the author of TC be anonimous AND force his copyright at the same time?. At least in Europe, afaik, that's not possible.

  66. Someone has indeed verified that the TC binaries for Windows match the output of a “build from scratch” using the required compilers and the open source.

    I don't have the link handy, but it was an extensive piece of work and you can find references in the TC forums.

    In the US, I don't think TC will work in the enterprise unless the product gets FIPS certified. Private audits won't help.

    This is especially true now that BitLocker (which *is* certified) is going to be included on all Windows versions without additional cost. And if BitLocker has a backdoor, few companies care: they aren't worried that the NSA could decrypt their computers. They're worried about HIPAA, Sarbanes-Oxley, etc.

  67. Even if the source code checks out OK, I would be worried about:

    – The compiler injecting stuff into the binary (haven't heard of that happening, but how can we be sure there's no way a compiler can mess with the binary, enter a block of code prior to compiling, say?).
    – DNS hacks that redirect users to a fake TC download site or link. You think you're downloading the real thing, but you're downloading a compromised version.

  68. 1. Hard to fight against this idea, anything is POSSIBLE!
    2. Check PGP signature of the downloaded binary against the trusted PGP key for the TC foundation.

    Pathological paranoia can't be remedied. You have to trust SOMETHING, just pick the right things to trust.

  69. And is there anything to lose? I am sure one could describe and define the project in a 'creative' framework. 🙂

  70. Well, that\s rather scary that you say you are now not worried as that link just showed further suspicions than other way round. A. I quote from that site, amongst other things: ” We can safely ignore the presence of the certificate in the official binaries, because a signature and certificate are normally harmless. Also, Microsoft's documentation indicates that “These certificates are not loaded into memory as part of the image.” This means that if this section contains malicious code, it has to be loaded by the program first, which would be seen in the source code. However, auditing the source code is not in our scope (IsTrueCryptAuditedYet? project aims at it)”. We can “safely ignore” due to “normally” these are harmless. DOH.

    Also, with that in mind then, one can simply exchange that last portion of 0s with the 'signature/potentially malicious code?' with a simple binary concatenation. This is just one trivial example of the issues in that link. Be it well meant or not.

Comments are closed.