Security compare

Encryption for the paranoid: Verifying TrueCrypt source code and binaries

TrueCrypt is open source and verifiable, but until someone actually does the verification, recent events have taught us to be skeptical.
TrueCrypt is easily the most popular and highly-regarded encryption program there is. TrueCrypt is capable of encrypting complete drives, partitions, folders, or individual files. Somewhat ironically, TrueCrypt is also well known for its ability to hide data in plain sight.
TrueCrypt Verify 1.png

Along those lines, it is interesting to note that all of the TrueCrypt developers have remained anonymous, with all communications going through the TrueCrypt Foundation. I did find a 2005 interview, supposedly with one of the developers, code-named Ennead.

More from TechRepublic on encryption:

Recommended by experts

Cryptography experts' willingness to recommend TrueCrypt is in part due to TrueCrypt software being open source, meaning it’s reviewable. This is something that’s happening all the time according to the TrueCrypt FAQ web page:

"In fact, the source code is constantly being reviewed by many independent researchers and users. We know this because many bugs and several security issues have been discovered by independent researchers while reviewing the source code."

But most people do not download the source code, and then compile it. They install TrueCrypt using one of the executable files. And that’s when the validity of the software becomes questionable. The FAQ web page mentions one way to verify that the downloaded files are compiled from the advertised source code:

"In addition to reviewing the source code, independent researchers can compile the source code and compare the resulting executable files with the official ones. They may find some differences (for example, time stamps or embedded digital signatures) but they can analyze the differences and verify that they do not form malicious code."

Unfortunately, I’m unable to find any documented evidence of this having been done. After downloading the source code, I can see why. It was almost two MB of data. Reverse engineering a program that complex cannot be simple.

Up until recently, this has not been an overly-pressing issue with encryption experts. But that changed when Mr. Snowden released information about the NSA Bullrun program:

"Documents show that the NSA has been waging a war against encryption using a battery of methods that include working with industry to weaken encryption standards, making design changes to cryptographic software, and pushing international encryption standards it knows it can break."

Bruce Schneier, in this blog, affirms the New York Times claim:

“Defending against these attacks is difficult. We know from subliminal channel and kleptography research that it's pretty much impossible to guarantee that a complex piece of software isn't leaking secret information. We know from Ken Thompson's famous talk on ‘trusting trust’ that you can never be totally sure if there's a security flaw in your software.”

Cryptographers, a nervous bunch to begin with, finally had enough. Matthew Green, cryptographer and research professor at Johns Hopkins University, and Kenneth White, Principal Scientist at Social & Scientific Systems decided to audit the executable files derived from the current version (7.1a) of TrueCrypt source code, and complete the following:

  • Create a verified independent version control history of the TrueCrypt source and executable code.
  • Document the building of executable files from the source code for the various advertised operating systems.
  • Conduct an audit (security and cryptanalysis) of the programs.

On their website, the gentlemen mention, "Many of our concerns with TrueCrypt could go away if we knew the binaries (executable files) were compiled from source." They also want to eliminate any concern that TrueCrypt has been compromised, most notably with a backdoor.

"The real dream of this project is to see the entire code base receive a professional audit from one of the few security evaluation companies who are qualified to review crypto software."

As you can well imagine, this kind of undertaking is not cheap. Green and White came up with a novel idea: use crowd sourcing to finance the project. It seems to be working, having raised 50,000 dollars since October 14. Donations are still being accepted at FundFill and IndieGoGo.

Final thoughts

I’ve read that Green and White have reached their financial goal, so TrueCrypt should get its day in court. The entire story behind TrueCrypt has been a source of fascination for me, and I hope TrueCrypt passes muster. If I were a betting man…


Information is my field...Writing is my passion...Coupling the two is my mission.


I fear that now looking at source code, only, or veriying that compiled code matches what their binary code matches with what their compilation instruction and environment describe, is not enough.

I think that compilers are now at risk of introducing their own backdoors (notably in their libraries), so that it will become absolutely impossible to predict re reproduce what will be the generated binary files, that will change constantly during each compilation.

If you need stonger security, it's time to go with virtualization of code, so that programs will only be compiled to run in a VM (without any native code), and there will be independant virutal machines. I won't trust the .Net VM because all programs for .Net use native code (not just code recompield locally from the .Net intermediate binary code, but really lots of native code shipped inside the same EXE).

For this reason I'll continue to trust 100% Java programs much more

Java is extremely secure compared to .Net. And it's simple to assess that the compiled Java code (in its intermediate bytecode) is safe. The whole security is then depends on the *separate* VM (which you should be able to choose and replace independantly of the program), and in the implementation of the JAva core libraries (they are safe for most of them because they are also in bytecode for most parts, so most standard libraries are also checked for security by the VM).

(OK there are some issues with Java **plugins**, but it's not because of Java, but because of the ActiveX integration for IE, or the old NPAPI for other browsers; ActiveX is definitely broken. But Java is not meant to be used as plugins for browsers; absolutely ALL browser plugins have severe issues, notably Flash and all other Adobe plugins for Acrobat, but as well plugins for common media players, including Windows Media, Real, iTunes... Chrome uses now a new "NaCL" API replacing NPAPI, but I think it is even less secure for native code; Chrome should have better promoted an API based on a VM running NON-NATIVE code, for example plugins written in Javascript, or Lua, or Python, and runninf in a restricted environment).

Note that even code running in a VM API may be insecure if that API offers an unchecked environment to call services in the native system (notably the local filesystem, or process control, or local network). Securing the VM is not enough: you also must secure its core libraries and the exposed APIs (this is true as well for securing the APIs offered by servers on Internet, many webservers are not secured there, suffering from code injection in lots of cases)


I use TrueCrypt in a very data sensitive environment where multiple government military contractors are involved and found no issues with it, except that it does not allow multiple access. The  containers are on a NAS (Network Attached Storage) behind a mesh of undetectable networks from the internet access point down to the actual network. 2 dummy networks were added to encourage would be attackers that they hit the jackpot. I have not had a single breach or unauthorized access attempt on my encrypted containers. Having said that, I informed my client there is no magic bullet against government toys...We live in fairyland if we think we can keep government spec cracking out of our daily lives. I think the TrueCrypt boys are doing a fine job...Keep it up. 

Michael Kassner
Michael Kassner



I am not by any means expert enough to understand what you are suggesting. Could you explain what you mean when you say compilers can introduce their own code. 

Michael Kassner
Michael Kassner


I agree with you. The whole idea is to make sure there is not a quiet backdoor or issue with the code. I always have wondered about the open-source claim, in that it is reviewable. That is all well and good, but how many do?

Michael Kassner
Michael Kassner

@Andrew Jake Borbe Aguda 

The unknown about TrueCrypt applies to Axcrypt, unless you have documented proof of it going through the verification process.

Michael Kassner
Michael Kassner


Thank you for sharing that with us. That is impressive, there is one thing left that I wished the person would have done. That is verify that the source code is malware/backdoor free. I did not see any mention of that. 


@Michael Kassner @wpbapollo  

I would rather take my chances with open-source than stick with a corporation that will sell it's soul & code to the government or organization that pays the most...I deal with open-source developers a lot, it's the mentality & purpose of intent that draws me to open-source...Not the bean-counters in corporate software willing to create a "flaw" or backdoor on purpose...In most cases when open-source software is cracked, it's due to unforeseen coding, not malicious intend.  

Michael Kassner
Michael Kassner

@wpbapollo @Michael Kassner

I understand your concern, but I do not believe that is what the two researchers are looking at. They want to know if anything is out of place in the code, and if not then is the source code the only thing used to create the binaries. TrueCrypt can be completely solid like you have shown, and still phone home without you knowing it. If I understand correctly, that is what the researcher are concerned about. 

If you look at the code, it is a significant amount, and there are very few organizations that can thoroughly test every aspect of it. That is who they are looking for.