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.
And why should we trust you, Mr. NSA Plant? ;)
load "linux",8,1
...been audited yet?
As they say in Latin: Quis custodiet ipsos custodes?
Now, for extra credit, try and determine if the compiler you used is compromised. Do this by compile it with a compiler that isn't, and prove you get the same compiler you used to make the initial verification.
Says you. 0_o
Of course xavier2dc is an NSA stooge trying to convince us that TrueCrypt isn't an NSA trap.
Nice try.
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.
Sure, the binaries match up after rebuilding from the sources. But perhaps the compiler injects exploits into all versions of binaries. Or maybe there are exploits in the MSVC CRT.
And let's not forget that the Windows operating systems are all essentially just NSA backdoors.
You don't have to trust this person, they've given you the exact steps to do it yourself.
"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."
What they mean is:
It is getting even more attention lately[,] following the revelations of the NSA[,] as the authors remain anonymous and no thorough security audit [has] yet been conducted to prove it is not backdoored in any way.
Oh, you know, so it doesn't say: "revelations of the NSA as the authors," implying that the NSA wrote the software.
Direct access to your physical body negates all security.
They can, and will, compel you.
Game over.
How does this exactly help prove or dispell any potential existence of a backdoor? Especially, if the binaries already contained one?
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.
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."
'Now we know version v7.1a is not backdoored, what about previous versions? Were they backdoored?'
This written by a guy who indicates he didn't audit the source code.
http://lkml.org/lkml/2005/8/20/95
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.
Luks stores the password/key in the beginning of the partition, trucrypt does simular I believe. Why would you ever want to include the encrypted key with the file/disk? Its just the password encrypted and is open to very fast bruteforcing when included. The whole thinking process is broken.
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
The compiler is not an issue. What is an issue, however, is that "the man" doesn't need a backdoored compiler, or for TrueCrypt itself to have a backdoor for that matter. Nope, the big issue is that "the man" has developed numerical algorithmic methods for cracking most encryption protocols, plus they have the supercomputers at their disposal necessary for getting the job done rather quickly.
Him? What about you?
He just compiled it.... but what if the backdoor is already in the source? has anyone actually checked, or does everyone just presume it's safe... " if you can see the code, i'm sure someone would of spotted a back door by now" ... thou this could apply to many open source software
I like turtles.
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.
You wouldn't download a babby, would you?
I diagrammed this Sentence in Sophomore English in HS, following up, "Jesus wept." :)
Mr. Countiss really liked that, IIRC.
Truth isn't Truth - Guliani
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.
This thing about TrueCrypt has turned into a test-case for software security practices.
Loosely, the security audit has three sections: 1) Look at the sources, 2) Look at the license agreement, 3) Verify that the binaries match the sources.
Item #3 above seems to be a generic problem: assuming that the source is correct, how can people verify that binaries were compiled from the source? Any minor change to the compiler can generate different instructions for the same code, and many compilers insert time-stamps and signatures (login of user running the compiler) into the final executable. This makes comparing binaries a problem.
Is there a better way to solve this? For example, could the GNU compiler digitally sign an executable, so that the executable could be verified by a web app on the GNU foundation page? (Generate a signature from source+binary and include it in the executable, for example.)
Can someone come up with a good solution for executable integrity?
Is his mothers name Sarah Conner?
I was promised a flying car. Where is my flying car?
Yay for open source. Certainly there is an advantage to being able to see the source and (re)build the softwares How do you validate closed source softwares? Reverse engineering won't always reveal the secrets and it is slow and painful to do. Any other methods?
And why should i trust you?
---- Booth was a patriot ----
http://cm.bell-labs.com/who/ken/trust.html
The NSA wages a massive psychological warfare campaign in yearly psy-ops that are budgeted at multiple billions of dollars. Telling people that good, cheap, easy solutions are 'bad' is very very effective. Most people are very easily manipulated, when messages are regularly inserted into their media of choice.
Take one real-life NSA project:
- years ago, the US government passed laws insisting that ALL mobile phones in the USA could be location tracked using ANY viable technology solution. In reality, this means cell tower 'triangulation' methods, where the mobile network providers ensure that ANY phone visible to more than one tower has its precise position noted multiple times per minute. This process does NOT require any form of GPS chip, or for the phone to be 'in use'.
- the law, created for the benefit of the full surveillance activities of the NSA, was described to the sheeple at the time as 'assisting' the authorities in locating 911 callers who, for some reason, couldn't give their current location.
- for several years afterwards, TV dramas and Hollywood films built the location tracking nature of ALL mobile phones into their plots.
- then, the NSA decided that it wanted the American sheeple to FORGET this functionality, and contacted all the major media companies, requesting they no longer reminded viewers that their phones are effectively location tracking bugs. The excuse was that criminals would use their phones without regard for self-incrimination, if TV and films stopped reminded them of the risks represented by mobile phone use.
- now, for almost FIVE YEARS, most TV shows and films, if having characters with mobile phones, specifically state to the audience that phone location tracking is HARD, unlikely, and can only be done under very restricted circumstances. The TV show 'Shameless' (US remake) has a supposedly expert hacker kid STATE that mobile phones cannot be location tracked. The recent movie "The Call" states that only phones with GPS chips can be location tracked.
The NSA is in the game of perceived truths. The NSA has the money and influence to contact ANY mainstream media organisation, and have them carry an NSA designed form of propaganda.
Commercial encryption solutions don't just ALL contain NSA back-doors, they also prohibit the concept of 'plausible deniability'. Truecrypt doesn't tie the concept of password entry to the package that is to be decrypted. You cannot accurately say "this is a truecrypt data block". Commercial encryption products, on the other hand, bind the password process with the encrypted data, denying a user the ability to deny the use of encryption. NSA FUD shills suggest the government do NOT need proof of encryption when demanding passwords, but this is laughable. Legally, you CANNOT demand something you have no proof exists. With the use of Truecrypt, the government needs to collect pre-existing data about its use (say, like the fact the suspect has been witnessed STATING he/she keeps certain encrypted data on the suspect computer). A commercial encryption package, on the other hand, even without back-doors, still works to alert any third party where exactly encryption is active on the computer.
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.
Russ1642's mention of "the source for the chips themselves" implied the (remote) possibility of a compiler backdoor implemented as part of a CPU's microcode, something Applekid stated more explicitly. Sure, the WDC 65816 in the Apple IIGS is connected to 1 to 8 MB of RAM into which a compromised compiler may be loaded. But that doesn't mean the CPU's microcode itself is compromised. There are detailed photomicrographs of the 65816, and the microcode part is not that big. I only mentioned it in the first place because something like ORCA/C is highly unlikely to have the same backdoors as popular compilers.
Even TOR is made by NSA and they even confess to provide the servers for it, so that's why we know about Edward Snowden, he though he was safe using NSA TOR servers.
The authors of TrueCrypt have decided to remain anonymous. However, the timezone (GMT+1) of a TrueCrypt developer machine identified in the article matches the timezone of Czech Republic, mentioned in http://en.wikipedia.org/wiki/TrueCrypt: "The TrueCrypt trademark was registered in the Czech Republic under name of "David Tesarik"". Does not conclude anything, but it is a bit reassuring to know it might be developed a bit away from NSA and other large 3-letter organizations.
This is one of those few times where an AC is absolutely uninteresting :)
Of course I have to trust them. Or do you think I'm actually going to go through the trouble of actually doing the steps myself?
who prays for Satan? Who in 18 centuries has had the humanity to pray for the 1 sinner that needed it most? ~Mark Twain
So as a rule of thumb a software which wants to be seen as secure should publish not only it's source and binaries but also virtual machine images which can be used to build sources and end up with the same results.
A bit harder for commercial dev environments though and this really is a non-issue for linux distributions which use source packages...
The plural of datum is data.
The singular of data is datum.
Sorry, he should have specified: In modern English, data is non-countable and does not have a plural form.
You are correct about the Latin datum. You may now return to ancient Rome, or to whatever ivory tower you reside in.