TrueCrypt, widely used by many people to secure their sensitive data shocked its users when it posted a notification on its official website that “TrueCrypt is not secure” and recommended BitLocker instead. We covered this in a previous post but decided to dig a little deeper.
TrueCrypt’s developers are still a mystery and used to go under the handles of “ennead” and “syncon” which was later replaced by “The TrueCrypt Foundation”. It is noted that the TrueCrypt trademark was registered in the Czech Republic under name of “David Tesařík” and it appears that David. T has written as one of the devs of TrueCrypt before with a Czech e-mail address which would also perhaps explain the less than perfect English and the strange manner of the notice.
“David” was contacted by Steven Barnhart @stevebarnhart through one of the e-mails he found available and purportedly received several replies from him. A summary is as follows of a Twitter conversation between Professor Matthew Green (who heads the audit of TrueCrypt) and Steven.
TrueCrypt Developer “David”: “I were happy with the audit, it didn’t spark anything. We worked hard on this for 10 years, nothing lasts forever.”
Steven Barnhart: (Paraphrasing) Developer “personally” feels that fork is harmful: “The source is still available as a reference though.”
Steven Barnhart: “I asked and it was clear from the reply that “he” believes forking’s harmful because only they are really familiar w/code.”
Steven Barnhart: “Also said no government contact except one time inquiring about a ‘support contract.’ ”
TrueCrypt Developer “David”: Said “Bitlocker is ‘good enough’ and Windows was original ‘goal of the project.’ ”
Quoting TrueCrypt Developer David: “There is no longer interest.”
In light of this it is possible that the notice that “TrueCrypt is insecure” merely meant that
All is not lost as the Open Crypto Audit project is still proceeding to audit TrueCrypt’s security and potentially build from it.
The latest working copy of TrueCrypt with full capabilities is still TrueCrypt 7.1a which you can download here (at entirely your own risk). You can use a site like OnlineMD5 to verify its hash. It is to be noted that Bruce Schneier on the audit project is moving back to PGPDisk to encrypt his data.
There is also an interesting viewpoint (if speculative) posted by Bill Cole on Krebson Security:
The iSec initial audit report was very critical of the TC code quality, and implied that it looks like the work of a single coder. There was no update for 2 years. The build process requires a 20 year old MS compiler, manually extracted from an exe installer.
Imagine yourself as the lead/solo developer working on TC. No one pays you for this, governments hate you, much of the crypto community is throwing rocks at you while your user community spends half of its time joining in with clueless paranoia and the other half whining about feature gaps (e.g. GPT boot disks.) You have to eat, so you have a real paying job. You’re not so young any more (doing the TC crap for a decade) and maybe the real job now includes responsibilities that crowd out side work. Or maybe you’ve got a family you love more than the whiny paranoids you encounter via TC. And now iSec is telling you your code is sloppy and unreadable, and that you should take on a buttload of mind-numbing work to pretty it up so they will have an easier time figuring out where some scotch-fueled coding session in 2005 ( or maybe something you inherited from a past developer) resulted in a gaping exploitable hole that everyone will end up calling a NSA backdoor.
Maybe you just toss it in. Why not? Anyone with a maintained OS has an integrated alternative and as imperfect as they may be, they are better than TC for most users. Maintaining TC isn’t really doing much good for many people and the audit just pushed a giant steaming pile of the least interesting sort of maintenance into top priority. Seems like a fine time to drop it and be your kids’ soccer coach.
If you’re into getting more confused, you can read a good summary and possible theories here.