Slashdot Mirror
First Phase of TrueCrypt Audit Turns Up No Backdoors
msm1267 (2804139) writes "A initial audit of the popular open source encryption software TrueCrypt turned up fewer than a dozen vulnerabilities, none of which so far point toward a backdoor surreptitiously inserted into the codebase. A report on the first phase of the audit was released today (PDF) by iSEC Partners, which was contracted by the Open Crypto Audit Project (OCAP), a grassroots effort that not only conducted a successful fundraising effort to initiate the audit, but raised important questions about the integrity of the software.
The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."
The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."
The same OpenBSD that shipped an OpenSSL version with the heartbleed bug? Hmmm...
The code is being audited in America. That's pretty funny.
How about an audit in a country where the NSA cannot tell the auditors to shutup?
CM www.cometenergysystems.com Blog: http://caribbeanrenewable.blogspot.com/
Didn't say or imply that, but they claim to be auditing the code they ship yet seem to have missed the massive bug in one of the major parts of the system when used as a server.
Tell me this: if the NSA did put a backdoor in the package and if this audit found it, how would the NSA know about it in time to prevent it being reported? Sending a security letter to the auditors would just be considered proof that there was a backdoor to be hidden. The auditors may have been forced not to reveal anything about it to the general public, but you can bet that the people over at TrueCrypt would have found out about it and eliminated it as soon as possible, although they'd probably have had to pretend that they found the flaw themselves to protect both themselves and the auditors.
Good, inexpensive web hosting
I've been coding in C a long time and one of the medium security faults makes no sense to me:
"Windows kernel driver uses memset() to clear sensitive data"
The reasoning they give is:
"...However, in a handful of places, memset() is used to clear potentially sensitive data. Calls to memset() run the risk of being optimized out by the compiler."
WTF?!?
I suppose a smart compiler can optimize out a memset() if it's directly preceeded by a calloc() or something, but I have never had any compiler ever just ignore my request to memset().
What am I missing here?
Oh hell, they'll just sneak into your home in the middle of the night and plant a hardware bug or key logger into your computer.
One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer. They got a child pornographer like this, his use of true crypt didn't help because they had video of him entering the password and simply entered the password once they seized the computer.
True Crypt cannot reasonably protect you from law enforcement nor state sponsored spying like the NSA. It might protect you from some non-tech police agency in some shit hole country being able to access it but then they just use the standard non-tech password extraction method.
Obligatory XKCD. http://xkcd.com/538/
Ah, ok. It's just I've seen enough "LOL Theo wrote Heartbleed. I mean, OpenSSH, OpenSSL, what's the difference?"-like posts these few days and jumped to conclusions. Still, I don't see it painting them as liars.
It took half a year for this first phase of audit of one package to complete - imagine how long would a single point release take with comprehensive audit of every package? They do find and fix bugs in 3rd party packages, but of course they can't catch every bug when they're limited by resources and time and stretched over every part of OS.
Oh, you mean they should be auditing everybody else's code too?
Umm, yeah? Since that's what they claim to do:
The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component.
http://www.openbsd.org/securit...
Or are you going to claim that OpenSSL is not a critical software component?
The problem with the NSA is we have no idea what their capabilities are, technologically or legally. They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them. So if they did come to you with a NSL, no matter how ridiculous or unconstitutional it was, what choice would you have? You could go to the media, but how embedded in the media are they? Do they have standing NSLs with all the media organizations out there? You could go outside the country, but those newspapers are government by their own countries version of the NSA who's working in close relationship with ours. This really is a Global totalitarian secret police state. They haven't started herding people into camps or anything, but really... what's to stop them?
One way to detect a backdoored compiler to a fairly high certainty is diverse double-compiling, a method described by David A. Wheeler that bootstraps a compiler's source code through several other compilers. For example, GCC compiled with (GCC compiled with Visual Studio) should be bit for bit identical to GCC compiled with (GCC compiled with Clang) and to GCC compiled with (GCC compiled with Intel's compiler). But this works only if the compiler's source code is available. So to thwart allegations of a backdoor in Visual Studio, perhaps a better choice is to improve MinGW (GCC for Windows) or Clang for Windows to where it can compile a working copy of TrueCrypt.
I don't think you understand whats going on. PBKDF has absolutely nothing to do with 'protecting' your password. Its done because passwords suck ass for encryption keys.
TrueCrypt is taking your password and turning it into something USEFUL as a key for encryption, not 'protecting it'.
Standard passwords are pathetically low on entropy, a full twitter or SMS post is still not 256 bits of useful entropy, and its unlikely your passwords are anywhere near that. I admit I don't know your password, but if you're only using the standard character set, I can safely say its pathetically low on entropy. You need full binary keys generated from good random sources, but you'll never remember that, will you? Imaging trying to type it somewhere.
What the hashing does is takes your password and contorts it into a larger key that is more useful than whatever pathetic string of text you throw at it. It does so in such a way that, like all hashing processes are supposed to, you can't go backwards because bits are discarded along the way.
2000 rounds is pretty low, but thats only a tiny small part of the encryption/decryption process. And your password (as I understand true crypt) really just projects are larger private key, which is what is actually used for encryption. Its been a while since I've looked at or used TrueCrypt, so I may be wrong about that last particular bit.
For a full description: http://en.wikipedia.org/wiki/P...
I do write encryption software for a living. And again, its not about protecting your password or making it harder to guess, its about turning your crappy password into a useful encryption key, nothing more.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager