ChristopherPrice.net

Don’t Fear Forking TrueCrypt

Whatever reason that caused TrueCrypt’s demise, probably would also stop anyone suing over a license breach. As someone who started officially forking Android this week, I figured I should chime in on forking TrueCrypt.

For the record, I have no affiliation with TrueCrypt. Haven’t used it in years. I care about corporate thieves and everyone on Team @iConsole is required to full-disk encrypt however. It paid off when an extended TSA checkpoint inspection spanned three metal tables at JFK late last year, and someone walked off with my totally-encrypted MacBook Air.

I wasn’t watching it, because I was worried about the engineering gear that couldn’t be encrypted, and that’s what caught TSA’s eyes in the X-Ray. After that – nobody has griped once since about my encryption policy… and there were a few people on the team that didn’t understand my demands to encrypt before that – it sent a message.

I have no idea if TrueCrypt was served an unconstitutional NSL. I have no idea if TrueCrypt had a backdoor inserted in it. I have no idea what in the world caused TrueCrypt to go away.

I do, however, know that career engineers do not fold up a project like that, unless it was something significant. And, whatever significant thing it was, it prohibited them from discussing the matter.

In Switzerland, a group of developers have forked the code and are continuing development – disregarding TrueCrypt’s license terms and replacing them. A crowd-funded code audit of the code being used is continuing too.

Don’t fear the courts this time…

TrueCrypt had an odd license. While the source code was shared, TrueCrypt’s authors prohibited forking. It does not have any compatible source code licenses with things like GPL or Apache – the source was being shared, according to the authors for transparency reasons. Otherwise, nobody would trust the code didn’t have backdoors. And, people still don’t – some believe the compiled binaries might have backdoors that the source-compiled builds didn’t.

Either way, I can respect the licensing situation. It’s also to preclude people from using old/vulnerable versions in their code, making it a nightmare to keep TrueCrypt secure if others run wild with old versions that might have known exploits in the wild. From an ethical stance, having just “one TrueCrypt” was logical – if problems cropped up in the code, everyone would update at the same time and people wouldn’t be left vulnerable (a la OpenSSL Heartbleed).

But, TrueCrypt didn’t waive the license when they folded up. Some fear litigation for using the abandoned code.

If TrueCrypt engineers were to sue anyone for using said forks, they would have to establish damages. Considering TrueCrypt formally terminated the project, making a case for damages would be challenging. Then you have to fear lawfare – when litigants know there are little to no damages, but sue anyways to bleed the other party of money as they are forced to hire attorneys and defend meritless motion after meritless motion (been there, done that).

Arguments against some IP being breached or value in a dead project, would be subject to interrogation in a court. Any good attorney would then have a field day asking, under oath and compulsion of a court, to direct the Plaintiff (TrueCrypt) to explain why the project was terminated.

And I suspect, whatever the reason, that the person in that deposition chair would not be willing to answer. As such, the case would collapse.

I see no other alternative for TrueCrypt to threaten people from continuing its development. I’d love to hear a theory that challenges my opinion, however.

That all said, there is still the fear that TrueCrypt has some sort of backdoor, and that the developers of TrueCrypt killed off the project due to fear that the backdoor would be discovered. First, this is unlikely – a code audit of TrueCrypt started long ago, is ongoing, and has yet to find any known backdoor.

But, if there is a backdoor, one would be forking code that is truly not secure anymore. Code audits however, will get to the bottom of that as well as the community can. At the end of the day, if a government has the ability to sneak exploits into open source code, forking TrueCrypt will at least allow for continuity in traction and allow for more eyeballs to inspect the code, and find such an exploit faster.

I will also poke one hole in the TrueCrypt developer’s claims during the shutdown notice. They claimed that Windows XP’s expiration prompted the project’s shutdown, as Windows Vista, 7, and 8 all offered BitLocker. A ridiculous reason, seeing as TrueCrypt also supported Linux and OS X, not to mention that consumer SKUs of Windows Vista, 7, and 8 lack BitLocker. But, moreover, TrueCrypt’s own authors noted this previously as a touted feature. The notion that they recommended enterprise BitLocker, and didn’t even mention Windows 8.1’s new built-in free encryption (based on the same BitLocker technology), is also very telling. It tells me that someone forced or convinced them that shutting down TrueCrypt was in their interest.

In closing, what I actually fear is too much forking. FOSS extremists will probably refuse to allow any code that has touched TrueCrypt to entire common Linux distributions, arguing that code converted to a common license (like GPLv2) would come from “tainted” upstream code still tied to the TrueCrypt License. As such, we’re going to see a mess of cryptologists that either embrace TrueCrypt, or move away from it and spawn dozens of weaker, less-reviewed alternatives.

Long term, it may be best to take dm-crypt and modernize it, create a sexy GUI and re-create the TrueCrypt bootloader atop Gummiboot or something similar. But for now, keeping TrueCrypt alive shouldn’t be a feared act.

Exit mobile version