Comment by jimrandomh | Hacker News Reader

Comment by jimrandomh | Hacker News Reader

Yes, this is definitely needed. There are two angles to investigate: checking the cryptography itself for mistakes, assuming good faith; and checking the packages for backdoors, if this is questioned. Given that the TrueCrypt developers are anonymous, both are required. I won't get much into the former - but I've thought a bit about the TrueCrypt foundation, and when I looked into it (not in great depth), it looked odd to me, so I gave some thought to where back doors would be located, if there were any.

If TrueCrypt is back-doored, the backdoors are likely only present in the binaries offered for download on truecrypt.org, not in the source code, where they would be more easily found. A cross-check of important routines might be informative. A back door would take one of two forms: either it'd smuggle a copy of the key somewhere, or it'd lower the key's entropy enough to be crackable. The former would be discovered by simple disk-space accounting, so it is probably not the strategy used. Reducing the key entropy would make any volume decryptable if it was first initialized by a backdoored copy of Truecrypt, while retaining compatibility with non-backdoored copies; so likely places are in the key-generation, or in the random number generator that feeds it.

Also noteworthy: the download links all work by POSTing to /dl, then being redirected. The Windows download link for me went to http://www.truecrypt.org/download/transient/e2ec88b9b7dfb3a8..., and it's not clear what that big hash is doing there - other operating systems use a different URL scheme (without the /transient/10bytes component). Their web server might occasionally give different binaries to people it doesn't like. All the downloads are over http, not https (except for signatures); and their site responds to https in a very odd way, responding with a valid certificate but always redirecting to non-https.

> not in the source code, where they would be more easily found.

Why do you say that? Compiling the source with the same compiler and flags, plus diffing the binaries would quickly show where the differences lie, and if they're hostile. Any half-decent reverse engineer could do this.

That would stand out more than if the source itself was backdoored in a non-glaring way. Open source has taught us that nobody ever reads the source.

That would require a deterministic/reproducible build process. Such things tend to need the same host-OS, library versions, dependency versions etc that AFAIK Truecrypt haven't got documented anywhere. See the efforts of Tor Project, Debian et al to start doing reproducible builds - It's not easy. And this is without things inherently producing non-deterministic builds - embedding timestamps is quite common for example.

https://wiki.debian.org/ReproducibleBuilds

Yes, that is correct. I founded SourceDNA.com as a way of automating this kind of analysis. We match components found in binaries in order to identify unlicensed use of third-party code, as well as security patches.

Tools like bindiff have been around for years and take advantage of the fact that compilers don't randomize code generation. Instead, the callgraph and control-flow graphs largely reflect the structure of the original source code. Once you have leverage by exact-matching the parts of the binary that are nearly identical, you can build up and down the tree of nodes to find those that have more changes.

Crypto backdoors can be unbelievably subtle though. A single branch condition, a bit that is flipped, etc. can all lead to catastrophic failures. For example, a compiler optimization for dead code elimination led to some zeroization of key material being skipped. This kind of thing is extremely difficult to find and requires a careful understanding of the underlying code.

I agree with you that most differences can be found, but understanding the ramifications of those differences requires extremely careful analysis. A crypto flaw does not stand out from a mis-optimization.

> a compiler optimization for dead code elimination led to some zeroization of key material being skipped.

That sounds like a pretty broken compiler, do you have a minimal example?

This is likely a reference to the Debian OpenSSL fiasco.

http://www.debian.org/security/2008/dsa-1571

Oh I see. That is a lot of fiasco. I guess I'm mostly curious about a minimal example of useful code that a dead code eliminator will incorrectly optimize.

In the debian fiasco it's mostly a case of "manual code elimination" [1].

However there are plenty of examples of compilers aggressively removing code that causes undefined behaviour. Basically, when the compiler encounters UB, it can do whatever it wants to code that triggers the UB, which means possibly removing it. Compilers exploit this fact a lot because UBs happen a lot in "normal code". See here [2] for examples and explanations; I also can't help but mention John Regehr's blog [3] if you're interested in compilers, security, testing, safety.

[1] http://research.swtch.com/openssl

[2] http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

[3] http://blog.regehr.org/archives/213 is a great article for example.

That doesn't seem like a good fit. It wasn't a compiler problem, it wasn't dead code, and the problem wasn't skipping zeroing, it was too much zeroing!

  void
  encrypt(void *data, size_t len, char *password)
  {
    char key[32];

    turn_password_into_key(password, key, sizeof key);
    aes_make_encrypted(data, len, key);

    memset(key, 0, sizeof key); /* optimized away */
  }

The compiler knows what memset does. It also knows that stack variables have no use after the function returns. Therefore, the compiler knows there is no reason to write zeroes to this memory, because the program will never read those zeroes. Hence, the compiler will delete the call to memset.

Oh I get it. You're saying the key is stored on the stack and then you can find it by inspecting memory if it hasn't been zeroed out. That's really interesting, what a great example of leaning on language implementation. I guess the correct way to write this is to malloc and free the key. Except, couldn't an attacker see the key anyway while it was live in memory, either on the stack or on the heap (or if it's not "heap", whatever you call the thing that malloc takes memory from)?

I'm not a specialist, but wouldn't a call to free simply deference the memory, but not zero it out? you can then probably still find the key by inspecting memory? again, I'm not a good C programmer, I would like to know too :)

Yeah, you'd still need to call memset before free. Compilers have a much harder time convincing themselves of things about pointers, so it should survive dead code elimination.

This is what memset_s is for.

So what we have here is the potential for a backdoor caused by a 2 character difference in code.

Backdoors in source can be as simple as changing a single == to = or removing a minus sign in some seemingly innocuous place.

Not everybody programs against the C11 standard.

Umm, I think the person above is actually correct, though I'm by no means an expert. Otherwise, why would it take such a huge effort to achieve a deterministic build process as tor seems to have recently done?

Given that the TrueCrypt developers are anonymous...

I hadn't realized this was the case. That's pretty interesting.

I'm actually surprised that more pro-crypto, pro-privacy types haven't disappeared behind internet pseudonyms. Certainly if I were running a project that I hoped would be useful for dissidents in an oppressive state, I'd do my best to run it as anonymously as I could manage.

There might be personal risks and project risks in revealing yourself, but very little to gain. Knowing the names of the developers might give people warm fuzzies but it probably wouldn't mean much as far as the true security of the software goes. If the name is "John Doe," that tells you nothing, and if it's "Phil Zimmermann" that still doesn't prove that the NSA hasn't forced him to compromise the stuff.

In the particular case of TrueCrypt, which accepts donations through PayPal and credit cards, the "anonymity" of the project members is likely to be pretty thin. I imagine an American prosecutor could have them found easily enough.

If you compiled the source and obtained exactly the same binary as is offered for download, would that prove the binary was unmolested? I'm guessing there are many reasons why the binary might turn out to be different for non-suspicious reasons (different compiler versions/flags/environment...?), in which case would it be hard to enumerate all those reasons and rule them all out as the cause of a difference?

Yes - they acknowledge this in the Readme.txt for the source:

At the end of each official .exe and .sys file, there are embedded digital signatures and all related certificates (i.e. all certificates in the relevant certification chain, such as the certification authority certificates, CA-MS cross-certificate, and the TrueCrypt Foundation certificate). Keep this in mind if you compile TrueCrypt and compare your binaries with the official binaries. If your binaries are unsigned, the sizes of the official binaries will usually be approximately 10 KB greater than sizes of your binaries (there may be further differences if you use a different version of the compiler, or if you install a different or no service pack for Visual Studio, or different hotfixes for it, or if you use different versions of the required SDKs).

Plus I guess Visual Studio could be backdoored to recognise the TrueCrypt source code and insert malicious code?

Not only technically very difficult, but requires the MS VC++ team to be complicit and silent. I'd put it pretty far down the list.

Not that hard to imagine anymore, with National Security Letters and whatnot.

It can easily be reverse engineered.

Then compile it with gcc on cygwin and/or llvm and compare.

Then it won't match. Your only hope of getting exactly the same binary is to use the same compiler with all the same settings.

If you have verified the source code and the build process is sound and you produce the exact same binary as the distribution, then yes. But you're right that it's unlikely you'll produce _exactly_ the same binary. If you don't trust the source, the best way to be sure is to compile yourself.

There are many more reasons than that. Getting a deterministic binary is a achievement in and of itself:

http://gitian.org/

It could still be useful to try a tool like zynamics bindiff to compare a build from the source against the binary download.

Shouldn't we already know if TrueCrypt is back-doored or not considering its popularity ?

Why would that be? I don't even understand what you're suggesting, why could we assume 'we already know' about a backdoor in a popular product?

I believe he is just surprised that it not already vetted.

Sorry, see https://news.ycombinator.com/item?id=6525398

Like most mortals, I depend on Bruce Schneier: "Since I started working with Snowden's documents, I have been using GPG, Silent Circle, Tails, OTR, TrueCrypt, BleachBit, and a few other things I'm not going to write about. There's an undocumented encryption feature in my Password Safe program from the command line); I've been using that as well." http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...

There have been several important legal cases that would have significantly benefited from cracking the defendant's TrueCrypt volumes. To my knowledge, these attempts have all been unsuccessful.

If the NSA has a backdoor, then they're not sharing it with other law enforcement agencies, and keeping it a better secret than everything else they were up to.

We only know those things that we know. The NSA must still have some secrets.

Quite right. I wouldn't entrust my life to TrueCrypt, and hope nobody else would either.

So what would you trust your life to? If you are a dissident, what products and procedures would security professionals suggest?

They'd be hard pressed to recommend any off-the-shelf products or practices right now? Because PKI is in shreds, nobody trusts trucrpyt, and TOR users have been rooted left right and centre recently.

With my life? If a security vulnerability would be life threatening, I would not trust anything on the internet, I'd keep it off the internet -- and maybe even keep it off computers entirely. (Although if they can get physical access to my non-internet computer, they can get physical access to hard copy notes too, of course).

Yeah, that's hella inconvenient. But not quite as inconvenient as being murdered or disappeared to a torture prison.

Compare and contrast with the internet bringing democrazy and the Arab spring...

So how exactly would you communicate, share files and information if you were organizing an uprising for example?

You can't always physically transport those files, and sometimes it may be more dangerous to do so (if you are wanted person for example). You also have issue if you are having those files transported cross border then you may get border issues (Philip Greewalds partner being help in UK). For speed and ease, it would have to be via the internet somehow. For higher security, it would have to be non-network connected computers and via USB. For even higher security it would be non-computer but then I would have to memorise everything and I don't have a photographic memory :(

I'm not sure what I would do in this case either tbh.

How did people organize an uprising before there was an internet?

Or, perhaps, yes, organizing an uprising neccesarily means risking your life.

But here's schneier on air gaps for his recommendations against protecting yourself from very powerful attackers. https://www.schneier.com/blog/archives/2013/10/air_gaps.html

That's what I was thinking about.

I would assume the NSA has a variety of backdoors they do not share with other law enforcement agencies.

It was actually surprising to me that they shared ANY of them.

This is how intelligence agencies work -- they want to keep it a secret what they can crack, so the adversary will keep on using it, and they can keep on cracking it. For intelligence purposes.

Intelligence is different from law enforcement. Or at least, it used to be. In the US, theoretically the constitution means you can't use secret evidence against someone in court. But of course you can use secretly gathered intelligence for polticial/military/geopolitical purposes. The merging of intelligence and law enforcement is not unrelated to the push to keep more and more legal proceedings secret -- a significant threat to the constitution.

They can always use the backdoor themselves and use the information decrypted to provide hints to local law enforcement on where to look for evidence via parallel construction

That's.. odd.

Reply on news.ycombinator.com