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.

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.

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.

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

  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 */
  }

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

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

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.

https://wiki.debian.org/ReproducibleBuilds

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.

http://gitian.org/

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

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.

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

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

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.

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

I couldn't make any pledge input work (just kept getting errors) but I'm matching Matthew Green's own pledge.

Email in profile for confirmation.

Is fundfill broken? (and if so, should I trust it with money?) Or is there a secret decoder ring that I'm missing?

[edit] On further digging, I'm going to say "no , I should not trust it with my money". The 'funds' are a mix of 2/3 year old and current requests, mostly people asking for money in a kickstarter-like fashion, as opposed to the bounty system that appears to be the intent.

The site has various issues, and while their twitter account is active the whole thing just has an air of not-something-I'd-trust about it.

/opinion

[edit 2]

Come to think of it, wouldn't kickstarter or something similar be better? Get an estimate for the work and start a fund to get it done?

tcplay[1] is a BSD licensed CLI tool that can be used to create and open truecrtpt volumes.

cryptsetup[2] is a GPL licensed CLI tool that can be used to open truecrypt volumes.

zuluCrypt[3] is GPL licensed CLI and GUI tool that can be used to open and create truecrypt volumes.

arch linux users can get zuluCrypt from[4]

[1] https://github.com/bwalex/tc-play

[2] http://code.google.com/p/cryptsetup/

[3] http://code.google.com/p/zulucrypt/

[4] https://aur.archlinux.org/packages/zulucrypt/

cryptsetup is a front end to dm-crypt,an infrastructure in linux kernel that deal with block device encryption.cryptsetup just parses truecrypt header for volume properties,the hard crypto stuff is done by the kernel.

tcplay does the same thing,it just parses the truecrypt volume header and the hard lifting is done by linux kernel in linux and bsb kernel in BSD systems.

In both two projects,the crypto stuff is done either by crypto routines in kernels or by libgcrypt or openssl.

zuluCrypt is just a front end to the two projects above.

None of these projects do crypto stuff themselves.

It should be possible and to some,"trivial" for windows or OSX tools that deal with block device encryption to support truecrypt format.I think this will be a better use of the resources.

should the link be changed to http://fundfill.com/fund/TrueCryptAudited ? NO - SEE EDIT ABOVE

it's not clear what this link is, but the page requests using the link above for public sharing. it might possibly be the source of errors people are having donating...

My guess is that their software is severely broken.

I'm curious why didn't this go up on kickstarter?

http://en.wikipedia.org/wiki/Disk_encryption_theory

See

http://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&sect...

and

https://wiki.archlinux.org/index.php/Tcplay

That won't help much for Windows (esp. not with system encryption), but it might be able to help guard against weak key generation.

In either case, I'm unable to pledge using FB connect. Please advise.

instead of the accurate one. Just letting you guys/gals know in case you were extremely confused like I was for a couple minutes.

Not sure why this site would be used instead of IndieGogo

Also says PayPal and then links out via Stripe.

Interested, but not the site for this.

Truecrypt's UI/UX sucks at the moment. I'd love an alternative. I just discovered the CLI interfaced mentioned in another thread, which I intend to use over their GUI going forward.

Perhaps the submission link should have been of the far more insightful website http://istruecryptauditedyet.com/ ?

Someone in that thread quotes this paper: https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis...

...

It were three major weaknesses in the TrueCrypt keyfile algorithm which facilitated the attack. The first weakness was the application of the cryptographically insecure CRC-32 algorithm. Its input can easily be crafted to yield any desired output. The second weakness was the linearity of the operations by which the pool bytes were changed, that is the additions. This made the attack a simple application of linear algebra. The third weakness was the local nature of changes to the pool. Every byte of the keyfile only changes four bytes of the pool. This enabled us to do the attack successively making one byte of the pool after the other zero.

Holy crap. Any one of those weaknesses would be ridiculous from a security standpoint. The fact that all three exist is evidence of incompetence, at the very least. (Whether the incompetence is intentional or not is an open question.)

Not using CRC-32 is pretty much cryptography 101. Avoiding linearity is "preventing cryptanalysis 101". Avoiding local changes to the output (i.e. every byte of the keyfile should change the output completely) is called the avalanche effect and is, similarly, an incredibly basic requirement of cryptography. http://en.wikipedia.org/wiki/Avalanche_effect

Here is TrueCrypt's response to the attack:

“Hello,

First, thank you for reviewing our software–we really welcome and appreciate all inde- pendent reviews. It should be noted that when we designed the keyfile processing algorithm, we had been very well aware of the properties of the CRC-32 algorithm that you mentioned in the document.

Below is our response to the attack you reported to us:

No matter what keyfile processing algorithm is used, if the attacker can modify the con- tent of your keyfile before you create your volume, he can reduce the entropy/strength of the keyfile. Just as you cannot allow an attacker to modify or prepare your password when you create a volume, you cannot allow an attacker to modify or prepare your key- file before you create your volume, either. Otherwise, if you do that, you cannot reason- ably expect to have any security.

It is a basic security requirement that cryptographic keys (whether passwords, keyfiles, or master keys) must be secret and unknown to attackers. Your attack violates this requirement and is therefore invalid/bogus.

This is valid whether you use CRC-32 or HMAC-SHA-512, whether you use the True- Crypt keyfile processing algorithm or something different.

Thank you again for taking the time to review our software. We hope that the mistakes will be corrected before the review is published (publishing an invalid attack would be misleading).

Sincerely,

David

PS - Even if the attack was valid (it is not) and a cryptographically secure hash (such as HMAC-SHA-512) was used instead of CRC-32 (your suggested fix), the attacker would still be able to 'crack' your keyfile by a comparatively short brute force attack (it would only be slightly slower, as the attacker would merely have to find the correct key- file among the thousands or millions of keyfiles he crafted).”

... and here is the paper's response to their response:

This response is mistaken. It fails to differentiate between the secrecy of a password or key and the inability of an attacker to modify the password or key. The secrecy of the password and keyfile is indeed a basic prerequisite for the security of a TrueCrypt volume as it is in any other crypto- graphic application. However, it is quite possible that an attacker is able to modify a keyfile to a cer- tain extent while that keyfile at the same time remains perfectly secret and unknown to him. The point to be considered here is that cryptography has means to provide security even in such a weird situation.

As an example for such a situation consider an attacker who distributes an image editing software. He might add our attack algorithm to his software so that it secretly manipulates any image it pro- cesses to have no effect as a TrueCrypt keyfile. Our algorithm is even small enough to run on embedded systems. Therefore, even a digital camera might process the pictures it takes and out- put manipulated picture files. The pictures would nevertheless show what the user wanted and would remain unknown the the vendor of the camera or the image editing software. So they may be kept secret although they have been modified by an attacker.

In that situation a keyfile algorithm based on HMAC-SHA-512 would provide perfect security while the TrueCrypt keyfile algorithm fails completely. A brute force attack would be impossible as the attacker has not to find the correct keyfile among millions of keyfiles he crafted but among a practi- cally infinite number of possible pictures which might have been taken with his camera or pro- cessed with his image editing software.

I've never seen what's wrong with dm-crypt. It just works, and is mostly transparent.

edit

I am not shooting down. Just thought we have to be explicit that this is not a one time thing. I do think once it is verified and studied, and people like it, the contribution will continue to come. We might be able to build new products out of truecrypt.

The project makes more sense when you realize how untrustworthy that code might be today.

1: http://corp.galois.com/cryptol/

How big is TrueCrypt and how many contributions does it get? Certainly Linux kernel is so big and gets so many patches a day that even changeset analysis can be hard.

I should note that I'm on Windows as my home machine, so I'm personally most interested in that.

Chrome, OSX.

Is the link not stable or something?