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.
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.
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."
Cant remember who or when, but it was observed that it's the pizza delivery guy.
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.
And how do you propose to know if any particular compiler or library is or isn't compromised?
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."
At this point it means that if you go through the source code and understand it, you know what the truecrypt binaries are doing, because you can be pretty sure (modulo built-in compiler exploits affecting both your and their compiler the same way) their binaries match the source code.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
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
He made very clear that he didn't audit the source code. Only that the binaries match the source code.
And how do you propose to know if any particular compiler or library is or isn't compromised?
Obviously you'd just write the compiler and libraries from scratch.
Never trust an atom. They make up everything.
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
You mean Ken Thompson not Brian Kernighan.
Er. No. It doesn't.
Thank you for volunteering to audit the source code. Please let us know of the results after you are finished.
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.
Well, you can't trust any software you do not have the source code of. So of course you can not trust the MS compiler.
I'm a little suspect of this ./configure --enable-backdoor option.
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.
By using open-source ones, obviously. If you're running Windows, you're telling the world you don't really care whether your operating system is openly auditable.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto 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
TrueCrypt doesn't actually use public key encryption for the main de/encryption process (as it would apparently be hellaciously slow or something). It just uses PKE to encrypt the symmetric key, which I would guess is what must then be stored in the partition.
And you can't sign anything with either the public or private key and still be able to decrypt it unless you have the other half of the key pair.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
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?
Why everybody in this area keep on using the modulo notation? It makes no sense.
How is breaking a 2048-bit key encrypted by your password any less difficult than breaking a less-than-2048-bit password? (Hint: It's not. Quite the opposite).
The key is there to make it so that just the password, on its own, does not allow you to decrypt part of the data without also having the partition header (so getting a random sector off a storage device - say by doing magnetic history recovery if such a thing has ever existed - and having the password leaves you with NOTHING, you'd need the key sector as well).
Also, because your password is ALWAYS going to be less than 2048-bit, that's a way to ensure a decent level of security even if you use the same password on two machine (there is a nonce/salt value that does mean your password will not result in two identical keys on two otherwise-identical computers, so they can't use your laptop header to decrypt your PC even if they used the same password - this is a security feature by people who know what they are doing, if you haven't noticed).
This is not "the key". It's an encrypted (or salted+hashed) version of your key that is just as strong as every other sector on your hard drive but provides security features for non-2048-bit passwords that you wouldn't otherwise have. It does not weaken the encryption in any way, shape or form. If you could decrypt the key sector by brute-force, you could decrypt the rest of the hard drive with similar effort (so you lose NOTHING by having it).
So, please, stop talking nonsense.
Also, there is no correlation between this and the subject of the article, Truecrypt. Even if it did the same thing (I suspect it may, but it's not guaranteed), it's not "storing your key" at all. It's a misnomer to pretend it is or that it's in any way weakening security. If you can see the "key" inside that sector, you could see *any* decrypted data you wanted to anyway.
Rainbow tables, etc. apply to hash functions (and though it's possible salted hashes could be used in the same way to verify you have the correct key - which some encryption software does in certain places - your confusion between the two is most telling). And RT are defeated (pretty much) by large salted hashes and complex hash functions. They have no relevance here and - again - if the rainbow table helps you decrypt that initial key sector, it would help decrypt the drive WITHOUT that initial key sector anyway.
If you really think that something that obvious is as simple as "the key is in the first sector, let's just crack that sector", then you've not understood it at all. YOU STILL NEED TO KNOW THE PASSWORD or spend the same extraordinary effort breaking it to get anything at all. And with the initial sector being a random key - guess what? There's no predictable first boot sector, unlike if you just encrypted with a key (99% of Windows machines will have the same bootloader as everyone else so you KNOW when you've got the right key in one just sector of data - with an encrypted key in the first sector, you will *NOT* know if you have the right key without first then decrypting huge portions of the disk with that key and looking for plain-texts! That's a LOT of extra work added on - see.... security feature...).
And quite what you think putting it on different media will do, I don't know. That would be identical to just storing your "real key" on a USB thumb drive in an encrypted file protected by your password (because that's all it's doing).
This makes things better. It does not store "your key" but an encrypted copy of the key. That "encrypted" means it's just as hard to find that key as it would be ANY OTHER SECTOR on the disk. Except, as listed above, it provides a lot of advantages too.
Please get a clue before making blanket assertions like "It stores your key, so it's weakened". It's not. And this is why cryptography should NEVER be attempted by the amateur. What you think weakens the scheme actually makes it MUCH stronger.
The extra b is a parenty check.
You CLEARLY missed the whole point of a Ken Thompson attack. It's a very interesting read, highly reccomended.
http://cm.bell-labs.com/who/ken/trust.html
Why do you need to trust him? The source code and instructions are available for the world to see, no trust of the author is required.
It was a joke. Apparently not a successful one.
---- Booth was a patriot ----
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.
It might have been if it already hadn't been said 127 times.
The Kruger Dunning explains most post on
Then he puts it on Windows?
Today's captcha is horsefly
If Truecrypt calls ANY windows APIs, especially the crypto APIs, putting it on is exactly the wrong thing to do.
If on the other hand it has its own built in crypto functions in the source code you might feel a little better about it.
(I haven't looked, so I actually don't know if it uses MS APIs or not.)
Sig Battery depleted. Reverting to safe mode.
But did this guy check why the Windows version writes mysterious random bytes in the header but not in the Linux version?
Try reading the source perhaps? Some code is amazingly readable, even when you don't understand the language.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
Trust me, I'll audit it before I state that I know it isn't backdoored.
I wouldn't hold your breath for either to happen.
http://lkml.org/lkml/2005/8/20/95
Agreed there, but if he didn't audit the source code why did he make the statement it is not backdoored? He can't know if he didn't even look.
http://lkml.org/lkml/2005/8/20/95
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.
I meant, v7.1a is not backdoored *by the TrueCrypt developers between the sources and the binaries*, nothing more. I'll edit the sentence to make it clear.
surely it responds at least to the filesystem api's.. dunno why it would use windows's crypto api.. being multiplatform and all.
at least you have the source for it, unlike other windows crypto solutions. sure, I got bitlocker but how worthwhile is it?
world was created 5 seconds before this post as it is.
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.
> And you can't sign anything with either the public or private key and still be able to decrypt it unless you have the other half of the key pair.
You don't "decrypt" signed things, you simply verify them.
And you can sign something with the private key and still be able to decrypt it, as (a) at least as defined by all the standards I'm familiar with, the private key contains enough information to generate the public key; (b) the public key can be assumed to be known by everyone; and in some cases (c) there isn't even a public key, per se, merely the curve parameters.
Also FatPhil on SoylentNews, id 863
The disassembler he used is not. So it is (at least theoretically) possible to see if there is a back door.
You can also try disassembling the code by hand. (It's hard work, but you can do it.) Then you've only got to worry about whether the file has some trickery done to it so it looks like one binary sequence when opened normally, but uses something else when executed. Which I suppose is possible, but it's getting really hard to make such things reliable; it's easier to just put a rootkit on the OS and lie to users that way...
"Little does he know, but there is no 'I' in 'Idiot'!"
Which is fairly trivial to implement, as long as you can dictate what the secret sign should be.
So, next step: Run the TC source code through an obfuscator that messes with it in all kinds of horrible way _without_ changing what the meaning of the source code to a compiler would be. Then recompile and see if it matches the original binary.
sure it does. (x + 10) mod 10 = x, (binary + trojan) mod trojan = binary
If I have been able to see further than others, it is because I bought a pair of binoculars.
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
TOR development was partially funded by the US Navy, not the NSA (at least officially.)
Okay, you caught me: I may have gotten my terminology a bit mixed up. But if you sign/encrypt/whatever data with the public key, people can't read the data unless they have the private key.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Yup, public keys can used for encrypting messages *to* the key-owner, as only he has the capability to decrypt. Alas, that in itself provides no proof of the identity of the sender.
Also FatPhil on SoylentNews, id 863
("binaries match the source code" + "compiler exploits") modulo "compiler exploits" = "binaries match the source code". Thank you.