6 ms·

Yes, this is definitely needed. There are two angles to investigate: checking the cryptography itself for mistakes, assuming good faith; and checking the packag

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/e2ec88b9b7dfb3a8fee9/TrueCrypt%20Setup%207.1a.exe 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.

pbsd 13y ago
> 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.
- lambada 13y ago
  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 https://wiki.debian.org/ReproducibleBuilds
- NateLawson 13y ago
  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.
  - foobarbazqux 13y ago
    > 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?
    - Hello71 13y ago
      This is likely a reference to the Debian OpenSSL fiasco. http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571
jl6 13y ago
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?
- WizzleKake 13y ago
  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).
  - jl6 13y ago
    Plus I guess Visual Studio could be backdoored to recognise the TrueCrypt source code and insert malicious code?
    - bmm6o 13y ago
      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.
      - DigitalJack 13y ago
        Not that hard to imagine anymore, with National Security Letters and whatnot.
quantumpotato_ 13y ago
That's.. odd.
johnchristopher 13y ago
Shouldn't we already know if TrueCrypt is back-doored or not considering its popularity ?
- jrochkind1 13y ago
  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?
  - RexRollman 13y ago
    I believe he is just surprised that it not already vetted.
  - johnchristopher 13y ago
    Sorry, see https://news.ycombinator.com/item?id=6525398 https://news.ycombinator.com/item?id=6525398
- interstitial 13y ago
  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-remain-secure-surveillance http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...
- dublinben 13y ago
  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.
  - 13y ago
Lagged2Death 13y ago
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.

pbsd 13y ago

> 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.

lambada 13y ago
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 https://wiki.debian.org/ReproducibleBuilds
NateLawson 13y ago
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.
- foobarbazqux 13y ago
  > 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?
  - Hello71 13y ago
    This is likely a reference to the Debian OpenSSL fiasco. http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571

jl6 13y ago

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?

WizzleKake 13y ago
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).
- jl6 13y ago
  Plus I guess Visual Studio could be backdoored to recognise the TrueCrypt source code and insert malicious code?
  - bmm6o 13y ago
    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.
    - DigitalJack 13y ago
      Not that hard to imagine anymore, with National Security Letters and whatnot.

quantumpotato_ 13y ago

That's.. odd.

johnchristopher 13y ago

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

jrochkind1 13y ago
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?
- RexRollman 13y ago
  I believe he is just surprised that it not already vetted.
- johnchristopher 13y ago
  Sorry, see https://news.ycombinator.com/item?id=6525398 https://news.ycombinator.com/item?id=6525398
interstitial 13y ago
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-remain-secure-surveillance http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...
dublinben 13y ago
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.
- 13y ago

Lagged2Death 13y ago

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.