Slashdot Mirror
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."
But can you trust xavier2dc? It's turtles all the way down.
I was kinda hoping he'd built some elaborate timing setup to somehow match the exact timestamps and compile speed as the official binaries were built with.
This is still a great analysis though, and the detail provided is a fun read and useful insight into the general mindset and method of how this kind of analysis is done.
He provides pretty clear instructions on how to duplicate the process he used. He's not just saying "I did it and it's safe, trust me."
You don't have to trust this person, they've given you the exact steps to do it yourself.
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."
TFA painstakingly explained how you can check it yourself. I'm sure several people will, including enough people that I trust enough. Especially given that there is zero evidence of a backdoor. Nobody is claiming there is a backdoor, so it's a question if yyou trust the testers more than you trust - nobody.
If you're that worried about a ken thompson attack (which this topic always devolves in to) then why even use a computer at all?
500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
You're not quite 40 YEARS behind the times....
I think this whole NSA brouhaha will make some people start taking auditability a little more seriously.
Which means documenting the whole tool chain used and all options used. Of course, that only helps if you have access to the source. SUX to be you, Microsoft.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Define the universe. ;-)
Give two examples.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I don't. I build all of code in hardware. That is rendered in MineCraft.
Why is it so hard to only have politicians for a few years, then have them go away?
The compiler (and support stack) is a MS compiler, and MS is already owned by "the man", so as Kernighan demonstrated you still can't trust it.
The disassembler he used is not. So it is (at least theoretically) possible to see if there is a back door. The compiler has a very low-level view of what it is doing. In order to add a back door, it would need to recognize when it is compiling TC. This could be a much more difficult technical problem than what Kernighan did to login, and, if discovered, would be devastating to MS from a PR standpoint.
Do you have the attention span of a gnat? What you ask about is covered In the second sentence of the summary.
I did the exact same thing as in TFA a few days earlier and ended up finding the exact same variations and causes for those variations.
My conclusion was also identical, binaries are indeed coming from the provided sources and can be trusted if no further backdoor is found in the sources themselves.
A cryptographic and coding oriented audit is still much required.
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.
But did this guy check why the Windows version writes mysterious random bytes in the header but not in the Linux version?
There is one problem with his findings. In order to compile TrueCrypt you have to use Microsoft Visual C++ compiler, which is made by Microsoft from a closed source. If I was the NSA I would but the backdoor in the compiler and it would get injected into the binary whenever TrueCrypt was compiled.