in Truecrypt 505 Words

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.

39 thoughts on “Truecrypt report”

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

  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”

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. CipherShed’s team consists of 2 members who are now with Google. We’re supposed to believe that the company that played along with a dragnet has our backs with CipherShed?

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

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

  26. Having just visited their site they don't have a stable version of their project to download, only a pre-alpha version. So maybe your time machine took you forward in time. In any event I'm glad to see multiple project picking up the source code base and maintaining it.

    https://ciphershed.org/download/

  27. THERE IS NO REASON NOT TO USE OLD TRUE-CRYPT.

    Software is upgraded because of bug fixes and new features. You'd be insecure if you were using a 3-year old version of firefox or chrome, for example.

    However, unless you need some new feature then the best thing to do is continue to use the old version of TrueCrypt. According to this blog post, there were no really serious flaws, so there's no reason to use anything other then the most recent version of TrueCrypt to encrypt your data.

  29. Problem with the audit: According to the disclaimer right upfront: The audit is limited to what could be covered given the time and money that was available. I am pretty sure NO code has only 4 issues. Either that or the programmers are really better than the best we have seen.

  30. I have to confess I am somewhat suspicious of any discussion where most people prefer to stay anonymous or use vaguely ridiculous monikers like “the shadow”

  31. Given the sensitivity of this entire field, there are a number of reasons why people might want to be anonymous here. Feel free to give their opinions less weight if you wish 😀

  32. Indeed so – the original plan was for this to be more or less crowdsourced, but the abandonment forced a change in gameplan. Still, we can reasonably take this as a starting point, and start some sort of site to have people inspect portions of the source and put their names to the part they have audited (of course, finding competent coders who are also sufficiently skilled at forensic analysis and cryptography, and willing to give their time and effort for free, could be problematic)

  34. This report is not sound. I see no description of how the AES key is derived from the password. We have heard that fixed 2000 number of iteration count is used, which is too low to resist password brute force attacks.
    What is AES encryption worth if the AES key is derived from the password in insecure way?

  35. Apparently you didn't actually bother to read the article. They said TrueCrypt was largely a very well-designed piece of software, but they noted, rightfully, that it *was not perfect*. There are rare circumstances where the encryption mechanism will use a slightly-less-than-random key to what it could normally generate. This alone doesn't make the encryption easy to break, but it does make it a bit weaker than it could be and it's a legitimate criticism of an otherwise excellent application.

    If you're going to put on a tin-foil hat, next time make sure it doesn't cover your eyes.

  36. “Anyone who would have simply followed the instructions would be 100% safe”

    You must not do much user support as there's always someone in any user base that can never be bothered to follow instructions and expect software to do everything for them ;-).

    It is sloppy programming practice to fail silently like that on an error like that. At the least, a warning should be generated that that particular source of entropy was not responding and that, while a fairly random key could be created, that it would not be as “random” as it could be due to the failure of that module. This criticism of the code is legitimate but it's also not a showstopper issue either.

  37. Definitely I migrated to VeraCrypt that has the bug fixes! It is an improved TrueCrypt! Updated!

Comments are closed.