Thursday, April 2, 2015

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.

25 comments:

  1. But my understanding is that TrueCrypt has now been discontinued and replaced by the similar (but incompatible) VeraCrypt?

    ReplyDelete
    Replies
    1. TrueCrypt's developers have abandoned the software and left the code open for others to make forks off of. While VeraCrypt is a fork of TrueCrypt, it is by no means the one replacement. Anyone can grab the TrueCrypt code and make their own version.

      The big thing to take away from this audit is that there are a couple things that should be fixed in all future forks, but it is a good base -- by creating a piece of software based on TrueCrypt, you're not giving any parties an open door to your files.

      Delete
    2. No, actually the Truecrypt license was quite restrictive and not open source.

      It does not allow people to make forks. So any forks are breaking the law and thus it is very hard to trust them.

      Delete
    3. @Buge it's a civil violation. For some reason, I don't really see the Truecrypt authors popping up and pursuing legal action against forks. It's essentially abandonware at this point.

      Delete
    4. I suppose my question is really this. As a non-expert who requires encryption and was quite happy using TrueCrypt until the hiatus a few months ago am I better off using VeraCrypt or TrueCrypt.

      I suspect the answer is probably VeraCrypt but I genuinely don't know enough about the subject to make a reasoned decision.

      Delete
    5. TrueCrypt is safe 7.0.1a is unbreakable at this point. End of Story And this is from the Shadow!

      Delete
    6. The anonymous user is correct. It infringes on copyright to fork truecrypt, but court precedent is that copyright owners lose protections if they do not make a good faith effort to protect them. So, unless the truecrypt authors show up and do so relatively quickly, a fork will become "allowed".

      Delete
    7. Pretty sure you're think of trademark, not copyright. Copyright doesn't require active / ongoing protection attempts.... not in the USA, at least.

      Delete
    8. The project is being continued by new developers here: https://truecrypt.ch/

      Delete
    9. >No, actually the Truecrypt license was quite restrictive and not open source.

      I recommend reading the license. It explicitly allows forks. It is just not a standard license, and might have imperfect wording from a lawyer's perspective. But they do not forbid forks at all, they allow it as long as the license is kept.

      Delete
  2. "This is probably not a concern unless you're perform encryption and decryption" ->
    "This is probably not a concern unless you're performing encryption and decryption"

    ReplyDelete
  3. So glad that this audit was finished. I really appreciate the work you guys put into it, especially after the unexpected departure of the developers.

    It's sad that TrueCrypt is no longer being updated, but I'm very happy that they've left us with a foundation on which we can build even better encryption software!

    ReplyDelete
  4. MacFaddo 8tracks great mixes..

    ReplyDelete
  5. MacFaddo 8tracks great mixes..

    ReplyDelete
  6. I feel like myself or the author of this article fell into the Hollwood Hot Tub Time Machine! This is April 2015, Open Audit upon request by Truecrypt Fork CipherShed audited TC 7.1a and found what this article 'audit' found. CipherShed's developers corrected the few coding errors pointed out by 'that' audit' LAST YEAR months ago and optimized the source code which anyone can obtain and compile for themselves. The code is more optimized than the original Truecrypt 7.1a and appears to compile easier also. The resulting CipherShed binary appears to be 100% compatible with the OLDER Truecrypt 7.1a application and at the same time is more secure and optimized.

    Ok, now climb out of the Hollwood Hot Tub Time Machine because CipherShed has undoubtedly improved even further in the many months SINCE that audit was made and the developers have since updated the Truecrypt 7.1a source to optimize and close out the sloppy coding the Open Audit panel found. The Github CipherShed page shows the developers have updated their code in the past month and still has the corrected, optimized TC 7.1a source code available.

    ReplyDelete
  7. This information is FAKE: Truecrypt has a bad security implementation to reduce the strength of the encryption ordered by NSA and FBI, as they have problems to unencrypt suspects data. So, i dont recommend truecrypt. It do not have a visible backdoor, it has a bug in the implementation of the security algorythm. Stay alert and do not read this fake article audit which is FAKE.

    ReplyDelete
    Replies
    1. And your source for the claim that this info is "FAKE" is what exactly?

      Delete
    2. Wait...what? So....

      * Is the audit fake;
      * or is there an audit which is fake of the article;
      * or is the article fake;
      * or is the fake article audit fake which would lead the two fakes to negate each other which would mean the article audit (whatever that turns out to be) is actually true?

      I don't understand....

      Delete
    3. [citation needed]

      Delete
    4. This comment has been removed by the author.

      Delete
    5. It is always healthy to be a bit of a tin foil hatter...

      Delete
  8. Problem is not the buggy AES or the use of an outdated RnG... The MSFT framework - on top of which TC runs, has ways and means to defeat this scheme easily...

    ReplyDelete
  9. Look at the CipherShed audit results and the coding that FORK of TrueCrypt 7.1a underwent. The Audit panel found NO backdoors, NO serious flaws. The Audit panel found several sloppy coding implementations, some in regards to the already sloppy, insecure Windoze OS. If you are foolish enough to use any MicroSoft Windows OS, the old TrueCrypt 7.1 was probably the most secure application on your system system including its backdoored OS.
    .
    The CipherShed Fork of TrueCrypt 7.1a team had TrueCrypt 7.1a source audited and the results along with the source code Line Numbers on the sloppy coding and suggestions are listed. That was nearly 12 MONTHS AGO, the CipherShed team implimented the source optimizations and the cleaned TrueCrypt 7.1a source they have on their website compiles easily and results in a nice tight, optimizes 2MB binary which is 100% compatible with the closed down TrueCrypt 7.1a application.
    Google Last years CipherShed TrueCrypt Audit, check out the source in CipherShed Github.

    ReplyDelete
  10. Ciphershed is involved with government agencies and its audit was very intransparently funded. This is an incredibly cheap smear campaign against TrueCrypt.

    ReplyDelete
  11. I do not see how this passing up on the Crypto-API if it is not available would could even be considered sloppy coding, let alone a security risk. The last time I made a volume using TrueCrypt, it was VERY CLEAR in stating that YOU are responsible for creating entropy (using mouse movements), how to do it, and that doing so is very, very important for the security of the created volume. Anyone who would have simply followed the instructions would be 100% safe even if the Crypto-API RNG was hacked and just returned zeros indiscriminately.

    The same thing holds for the AES timing attack. In order to run the attack, the key must already be present on the system, otherwise it could not decode anything. It is not a vulnerability against what TrueCrypt is supposed to protect: a powered off computer.

    ReplyDelete