The sudden death of TrueCrypt

[SteveRiley]

(seen from https://www.kubuntuforums.net/showthread.php?65354)

TrueCrypt is dead. The developer warns it "may contain unfixed security issues." A updated binary was posted that allows users to decrypt TrueCrypt-protected information, but will no longer encrypt.

Interesting summaries and speculations: Ars Technica, Brian Krebs, Cory Doctorow, Bruce Schneier, Slashdot, Reddit.

An archived cryptanalysis presentation from a SANS event in 2010 that covers many available cryptography tools has a very curious entry on the TrueCrypt page: "Removed at request of US Government."

A visit to TrueCrypt's site now redirects you to a SourceForge page suggesting that TrueCrypt development ended because Microsoft discontinued support for Windows XP and recommends that people switch to BitLocker. So mystifying! And also strikes me as something of a red herring. TrueCrypt was open source and cross platform. Why recommend a closed source single platform alternative?

The Register wonders if this is some kind of warrant canary:

One intriguing possibility – and one that's it's very difficult to either prove or disprove – is that this is a warrant canary triggered by pressure on TrueCrypt's developers by the feds to backdoor the software – which is favoured by the likes of Edward Snowden and his journo pals. Effectively, it would be a signal to the world that something is not right, without breaching any gagging order that may also be in place.

It could even be in response to a threat to unmask the development team. "Somebody was about to de-anonymize the Truecrypt developers, and this is their response," suggested Prof Green.

For so long as TrueCrypt existed, its developer(s) remained anonymous. iSec, a Seattle-based security firm, was contracted to conduct an audit of the code. While no back doors were found, the code contains a number of weaknesses.

But of all the conspiracy theory guessing going on, one commenter on Brian Krebs's site kept his speculation more grounded:

The iSec initial audit report was very critical of the TC code quality, and implied that it looks like the work of a single coder. There was no update for 2 years. The build process requires a 20 year old MS compiler, manually extracted from an exe installer.

Imagine yourself as the lead/solo developer working on TC. No one pays you for this, governments hate you, much of the crypto community is throwing rocks at you while your user community spends half of its time joining in with clueless paranoia and the other half whining about feature gaps (e.g. GPT boot disks.) You have to eat, so you have a real paying job. You’re not so young any more (doing the TC crap for a decade) and maybe the real job now includes responsibilities that crowd out side work. Or maybe you’ve got a family you love more than the whiny paranoids you encounter via TC. And now iSec is telling you your code is sloppy and unreadable, and that you should take on a buttload of mind-numbing work to pretty it up so they will have an easier time figuring out where some scotch-fueled coding session in 2005 (or maybe something you inherited from a past developer) resulted in a gaping exploitable hole that everyone will end up calling a NSA backdoor.

Maybe you just toss it in. Why not? Anyone with a maintained OS has an integrated alternative and as imperfect as they may be, they are better than TC for most users. Maintaining TC isn’t really doing much good for many people and the audit just pushed a giant steaming pile of the least interesting sort of maintenance into top priority. Seems like a fine time to drop it and be your kids’ soccer coach.

[HalationEffect]

Hmmm... one counterpoint to the grounded speculation occurs: when devs abandon a project due to mundane real life concerns (such as lack of time, family, the need to pay bills, etc.) they usually aren't shy about signing off with a statement saying their reasons for dropping the project. The absence of such a statement, while not conclusive, to me is very suggestive that TC's demise isn't for the usual mundane reasons.

Right now, I'm leaning toward the warrant canary hypothesis.

A fun analogy just occurred to me: consider two very different ways a fictional starship can end its career - 1) flown into space-dock and honourably decommissioned; 2) the crew has abandoned ship, all escape pods have been launched, and the auto-destruct timer has been set and is counting down.

What's going on with TrueCrypt right now sure feels more like the latter scenario than the former to me.

[GreyGeek]

The US government via the NSA and other spook agencies have been making war on the American people for well over 15 years, long before 9/11 and "terrorism". Remember Janet Reno's clipper chip fiasco? Or, the attempts to get Zimmerman to put a back door into PGP? Remember in 1997 when the Senate Commerce Committee Chairman John McCain pushed the Secure Public Networks Act through his committee? This bill would have codified the administration’s export ban and started a key escrow system. One of his original co-sponsors was his fellow Vietnam vet and good friend from across the aisle, John Kerry. Remember Sen. Ashcroft's response in a 1997 speech?

While we need to revise our laws to reflect the digital age, one thing that does not need revision is the Fourth Amendment… Now, more than ever, we must protect citizens’ privacy from the excesses of an arrogant, overly powerful government.

But, in gambits all too familiar now, politicians like to make statements on both sides of any issue so that they can later use the finger test to see which one becomes popular, or, to hide their primary agenda. In 1994 John Kerry trashed Ashcroft: http://reason.com/archives/2004/07/2...trous-record-o

...Kerry has promised to "end the era of John Ashcroft and renew our faith in the Constitution."
... Kerry, like every other senator in the chamber except Russell Feingold (D-Wis.), voted for the USA PATRIOT Act

and

Proponents such as McCain and Kerry claimed that law enforcement could not get the key from any third-party agency without a court order. Critics responded that there were loopholes in the law, that it opened the door to abuses, and that it punished a technology rather than wrongdoers who used that technology.

In a similar vein, there are groups and political parties doing their best to punish another technology rather than the wrongdoers who use that technology. In doing so, they attack the 2nd Amendment, and the entire Constitution as well, along with our fore fathers who wrote that great document.

So, while we fuss about the security of our person, home and papers, our right to defend ourselves is also being destroyed. From ProPublica:

The full extent of the N.S.A.’s decoding capabilities is known only to a limited group of top analysts from the so-called Five Eyes: the N.S.A. and its counterparts in Britain, Canada, Australia and New Zealand. Only they are cleared for the Bullrun program, the successor to one called Manassas — both names of American Civil War battles. A parallel GCHQ counterencryption program is called Edgehill, named for the first battle of the English Civil War of the 17th century.


Unlike some classified information that can be parceled out on a strict “need to know” basis, one document makes clear that with Bullrun, “there will be NO ‘need to know.’ ”
Only a small cadre of trusted contractors were allowed to join Bullrun. It does not appear that Mr. Snowden was among them, but he nonetheless managed to obtain dozens of classified documents referring to the program’s capabilities, methods and sources.

Even rhetorically, our governments have declared civil war on us and our privacy, and our right to defend ourselves from our own government when it goes rogue, which it has.

Personally, I only use encryption signing on my email so as to prevent anyone from modifying it to add to what I have written or to remove what I did write.

[SteveRiley]

More information.

A Forbes article by James Lyne is one of the better written summaries I've read.

As usual, Steve Gibson spews his torpid, steamy bullshopt:

The developers' jealousy is perhaps made more understandable by examining the code they have created. It is truly lovely. It is beautifully constructed.

Nobody else in the security field agrees with this.

The TrueCrypt Audit Project was funded on Indiegogo. The "Relevant History / Past Work" timeline is illuminating, including questions about the software's openness and the difficulty of compiling Windows binaries.

Truecrypt.Ch is a project that's attempting to gather as much information as it can, with the goal of creating a fork. Notably, it is not anonymous.

[GreyGeek]

It's interesting that TrueCrypt.ch has a quote from Gibson:

Steve Gibson: TrueCrypt is still safe to use

My suspicion is that this sudden abandonment is a form of a "canary warrant" warning that the developers had been pressured by the government to put in a back door and they decided that rather than do that they would kill the project at 7.1a, which by all accounts is still good software. Probably better than BitLocker.

EDIT:
I decided to take a look at the 7.1a x64 code for Linux. It looks rather clean and polished. "Beautiful"? That's in the eye of the beholder.

However, I did some searching about any previous audits done on TrueCypt and found one made in 2011.
https://www.privacy-cd.org/downloads...nalysis-en.pdf

The conclusions are very interesting:

8. Conclusion

TrueCrypt 7.0a is a highly secure program for encrypting containers based on the current state of the art in cryptography. We found no back door or security-related mistake in the published source code except for our attack on keyfiles. If you use this program in a secure environment such as Ubuntu privacy remix you may assume with high certainty that no one can get access to the data stored in your containers as long as they are closed, the passwords are really good and the attacker doesn't apply highly advanced methods below the layer of the operation system, such as BIOS rootkits, hardware keyloggers or video surveillance.

There is a fundamental problem with the analysis of binary packages published on the TrueCrypt website. Without a very expensive “reverse engineering” it can't be proved that they are compiled from the published source code. Since we haven't done such a reverse engineering we can't preclude that there is a back door hidden within those binary packages. As argued in section 6 our tcanalyzer program also can't rule out the possibility of a back door in a binary package.

Therefore we recommend to compile your binaries yourself from the published source code for not to put blind confidence in the TrueCrypt Foundation. In section 3 we gave some details how this could be done.

From the analysis in sections 6 and 7 the following particular conclusions may be drawn. The rational behind these conclusions is given in the sections mentioned.
• All encryption and hash algorithms are good. If your hardware is fast enough you could enhance the security by selecting a combination of several ciphers such as Serpent-AES, if not the standard AES is a good choice for you. For the hash algorithm we recommend SHA-512.

•Old containers created with TrueCrypt versions before 5.0 should be replaced by new containers created with TrueCrypt 7.0a. Such an old container should be deleted after copying its contents to a new container.

•The use of keyfiles is insecure. They doesn't weaken the security supplied by the password used in conjunction with a keyfile but if a weak or even empty password is used with keyfiles you are no longer secure.

• Hidden volumes are secure and provide you with “plausible deniability”. That means that an attacker can't distinguish whether there is a hidden volume within an outer container or not even if the password for the outer container is revealed to him.

• On creating a container we recommend to uncheck the check box for “Show” in the last dialog and to wiggle with the mouse for about a minute before clicking on the the “Format” button in that dialog.

A more recent audit is here:
https://opencryptoaudit.org/reports/...Assessment.pdf

Phase I involved a review of TrueCrypt source code and an analysis of its software architecture. The audit report uncovered vulnerabilities and some sloppy coding practices but no evidence of the kinds of backdoors alleged to have been deliberately built into some popular crypto schemes by the NSA.
Not out of the woods yet

Further Reading

Report: RSA endowed crypto product with second NSA-influenced code

Extended Random like "dousing yourself with gasoline," professor warns.


The preliminary finding was a relief given TrueCrypt's status as a decade-old program created by anonymous developers. But it by no means should be regarded as giving TrueCrypt a clean bill of health. That's because crypto backdoors can easily be stashed in random number generators, encryption ciphers, or other mathematical components of a complex piece of encryption software. Indeed, RSA reportedly endowed its BSAFE crypto toolkit with a random number generator that was engineered by the NSA. The lack of entropy when the algorithm, called Dual EC_DRBG, picked numbers to seed keys gave eavesdroppers a way to break the BSAFE-protected communications, Reuters reported in December.

So far, every explanation as to why TrueCrypt shut down could be valid. The code may be trash. The binary may not derive from a compilation of the released source code. The NSA may have coerced the TrueCrypt team and they responded by shutting down. The TrueCrypt team may have realized that a full, complete (but costly) reverse engineering of the binary may reveal a hidden door and releasing a disabled version that allowed people to pull out their data from existing containers and moving it to BitLocker would minimize the risk. Who wants to waste time and money analysing code that everyone is going to abandon? Maybe the folks behind the NSA (or BitLocker) discovered some past or present criminal behavior by the TrueCrypt developers and blackmailed them into abandoning the code. Maybe aliens mind melded with them.

Aliens or not, it seems to me that the audit of TrueCrypt may result in a truly open source fork which is even more secure.