How I Compiled TrueCrypt For Windows and Matched the Official Binaries
First time accepted submitter xavier2dc writes "TrueCrypt is a popular software enabling data protection by means of encryption for all categories of users. It is getting even more attention lately following the revelations of the NSA as the authors remain anonymous and no thorough security audit have yet been conducted to prove it is not backdoored in any way. This has led several concerns raised in different places, such as this blog post, this one, this security analysis [PDF], also related on that blog post from which IsTrueCryptAuditedYet? was born. One of the recurring questions is: What if the binaries provided on the website were different than the source code and they included hidden features? To address this issue, I built the software from the official sources in a careful way and was able to match the official binaries. According to my findings, all three recent major versions (v7.1a, v7.0a, v6.3a) exactly match the sources."
No, TrueCrypt is a popular piece of software. You don't have "a hardware" or "a clothing" or "an information" — and likewise you cannot have "a software."
I would say that TC is above almost all security software in that the source is available at all. There are a lot of utilities out there that there is no source available for unless one is a large government.
TC at least has a level playing field. China might have the source code, but at least you do too.
And how can I trust the cpu to actually execute the code as compiled and not insert it's own microcode into the process?
By using free compilers and ensuring clean binaries using diverse double compiling. (Thud457 mentioned it, and we discussed it a week ago.) Essentially what you do is bootstrap the compiler (compile the compiler's source code with your existing compiler binary, then recompile it with itself) on several different brands of compiler. If the binaries resulting from all bootstraps match, then either none of them have a backdoor or they all have the same backdoor. The more compilation processes you use, the less likely it will be that they all have the same backdoor. To exclude CPU microcode bugs that target a particular compiler, you could try running some of the bootstraps in an emulator such as DOSBox or bootstrap them as cross-compilers on another CPU architecture.
He did as much as was necessary to establish trust and no more.
I just want to say to Xavier - thanks. Great work.
http://cm.bell-labs.com/who/ken/trust.html
Visual C++ 1.52c is the last version that could generate 16-bit code, which is needed to compile part of the boot loader for full disk/system encryption. The other solution would have been to write all the thing in assembly (or replaced the portion with the pre-compiled code instead), but that wouldn't have made more people happy to reverse-engineer more assembly, would it?