Security Experts Looking To Possibly Fork And Rescue TrueCrypt

from the not-a-surprise dept

People are still trying to figure out what the hell happened with TrueCrypt suddenly announcing that development had stopped and that the code was not secure. However, as people sort that out, the same folks who were leading the charge on the TrueCrypt audit have announced that they’re looking into the possibility of picking up the TrueCrypt project and running with it themselves. The idea would be to complete the security audit, but then start managing a fork of the project themselves. They haven’t fully committed to this, but it sounds like that’s what they’d like to do. Yet another example of how open source projects are quite handy.

Filed Under: , , , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Security Experts Looking To Possibly Fork And Rescue TrueCrypt”

Subscribe: RSS Leave a comment
Todd Knarr (profile) says:

Grain of salt

Before I’d trust a fork, I’d want an idea of why the original developers considered it insecure in the first place. I’d think if they just didn’t have the resources or interest to maintain it, they’d say they were ceasing to maintain it rather than make an ambiguous statement about security. And there’s more than one security risk. If it were something like they were ordered to hand over copies of the private key used to sign binaries, rendering TrueCrypt vulnerable to government-created “official” versions, that can be dealt with in several ways. If it’s a case of TrueCrypt being unable to protect the data against interception within Windows on it’s way to the application, there’s nothing anyone can do about that and it has to be mitigated against in other ways. And if finally there really is some obscure and fatal flaw in the basic design or coding of TrueCrypt that makes it inherently vulnerable, we’d need to know what it is so we know any new maintainers have in fact fixed it before we could trust the new fork.

I’d note one interesting indirect attack: use methods that’ll cause the most secure projects to declare themselves at risk without letting them say why, letting paranoia push users into switching to software maintained by less scrupulous companies who’ll stay quiet about their software being compromised until forced by outside discovery of the compromise.

vancedecker (profile) says:

Re: Grain of salt

Prior to posting this, did you do any research whatsoever?

Even a small google search would have revealed that it’s obviously a disinformation campaign by the NSA dirty tricks office.

Do you really think any real programmer would encourage you to migrate to a Microsoft product? THINK!

With that said, one thing that people haven’t really addressed is that if you haven’t committed a crime, then you cannot be parallel constructed into Jail.

Parallel Construction only works if you are breaking the law.

alternatives() says:

Re: Re: Re:2 Grain of salt

Pre-fascist? Benito had the following to say:

?Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power?

?The definition of fascism is The marriage of corporation and state ?

“Fascism, the more it considers and observes the future and the development of humanity, quite apart from political considerations of the moment, believes neither in the possibility nor the utility of perpetual peace.?

Richard (profile) says:

Re: Grain of salt

Before I’d trust a fork, I’d want an idea of why the original developers considered it insecure in the first place.

Before I’d trust a fork, I’d want an idea of why the original developers or somebody impersonating them, said that they considered it insecure in the first place.

Because that is all we actually know.

Rich Kulawiec (profile) says:

Re: Grain of salt

“Before I’d trust a fork, I’d want an idea of why the original developers considered it insecure in the first place.”

I would guess that (in part) the just-completed first part of the audit might have something to do with it.

There’s a good summary of events and theories here:
(UPDATE: now includes response from developer)

You can download the entire source tree (using “git clone”) from here:

Steve Gibson summarizes here:

There’s a how-to that explains how to check the signature here:

There’s an interesting commentary here:

Bill Cole (one of the most seasoned people on the ‘net) has a terrific observation here:

The Wanderer (profile) says:

Re: Dear Techdirt...

This sort of bare comment isn’t really helpful. What exactly about the Techdirt comment system do you see as antiquated, or otherwise problematic?

I think it’s one of the better ones I’ve seen in current use. About the only thing I could point to as unambiguously improvable about it is the fact that posting a new comment takes you to a different page, and you have to go “back” to continue reading from where you left off.

(There are of course quite a few of what I might call “ambiguously improvable” things, i.e., things which if changed in the way I have in mind might end up better, or worse, or even just different after all.)

andre (user link) says:

TrueCrypt 7.1a download + Komplettes Archiv mit SourceCode und informationen

For all looking for the current secure release + older versions and sources and some additional information, i recently made website about the whole events with a data archive. all files with hashes for download.

visit for further information

Rich Kulawiec (profile) says:

Re: Gibson's new summary & links page

Well, the developers are certainly correct about Bitlocker: nobody who’s serious about security would even consider using Windows, so for those people who insist on doing so anyway…let them use Bitlocker, it’s only the second-worst decision they’ve made.

I do hope the neo-Truecrypt project takes that to heart and excises all support for Windows. Supporting an inferior operating system is a lot of work, and takes away resources that could be better spent elsewhere. The focus should be entirely on ‘nix-based systems.

Rich Kulawiec (profile) says:

Re: Re: Re: Gibson's new summary & links page

“The problem with BitLocker isn’t that it runs on Windows […]”

Yes. It is. People who care about security and privacy do not use Windows (a) because it’s a maldesigned piece of junk with an enormous and still-growing litany of baked-in security problems and (b) it’s closed-source, which means if it’s backdoored — and I think there’s a fair chance that it is — that it will be very difficult to discover that.

If you want at least a modicum of security, then make a better choice in OS. But please, let’s not even put “Windows” and “security” in the same room together.

John Fenderson (profile) says:

Re: Re: Re:2 Gibson's new summary & links page

I don’t disagree, basically (although it is certainly possible to run a secure Windows installation, it takes more work and skill than most people are willing to invest. It’s easier just to use a more secure OS from the start.) But we’re talking about two different things. I’m talking about the security of the crypto, not the OS.

Anonymous Coward says:

Re: Re: Gibson's new summary & links page

Great – lets only allow protection to the informed and clever and leave the unwashed masses without any.

That was sarcasm, and you sir are an elitist snob.

We should support good encryption EVERYWHERE and let people make their choice regardless of what OS they use.

Anonymous Coward says:

fix license issue first

TrueCrypt is not FOSS. They’ll need to fix the license issue first. I’m guessing they’ll have to deal with removing and replacing the contended E4M derived code before they can be in the clear abut forking it. This assuming the current developers want to allow forking the original portions of the code.

doug says:

Re: fix license issue first

There is a forked version already. I don’t know all the details of the license issues.

“The realcrypt application in the RPM Fusion repo is an encryption application based on truecrypt, freely available at It differs from truecrypt in only the following ways:

“- The name truecrypt is changed to realcrypt throughout the application, as requested by the truecrypt License:

” -All original graphics are replaced with entirely original new ones, as requested by the truecrypt License:”


“It does not differ from truecrypt in any other respect; in particular, no code relating to actual encryption or decryption is modified. Nevertheless, the truecrypt License requires that we ask you to report any and all bugs you find to [ RPM Fusion’s Bugzilla] and not to the truecrypt project.”

Source —

Anonymous Coward says:

Backdoors can be anywhere including open source s/w

The problem for s/w developers today is that all systems can be “backdoored” without the backdoor existing in the source code of the application you are compiling.

Any toolchain in use can be compromised without the source code being compromised. All it takes is to generate a single compiler that inserts the backdoor into any system in a specific manner and all compilers and all applications generated thereafter can be compromised.

When we look at something like *ix systems, at some point we need to use a binary to compile the source code of the compilers we use. All it takes is a single infestation into a distribution to propagate that infection.

To get around this, it requires knowing the provenance of all code within the system, including any binaries that are in use.

Of course, it goes without saying that to do this requires real skill, foresight and knowledge. This is not necessarily the domain of any of our security forces/organisations.

Anonymous Coward says:

Re: Backdoors can be anywhere including open source s/w

Any toolchain in use can be compromised without the source code being compromised. All it takes is to generate a single compiler that inserts the backdoor into any system in a specific manner and all compilers and all applications generated thereafter can be compromised.

I presume you are referring the the Ken Thompson hack. All such hacks are liable to discovery as a system evolves, and better debugging tools become available. Also they are liable to failure when the underlying system changes. Such hacks have to be targeted to very specific routines, and have to assume that neither the routine name, or required actions change. Relying on any external code introduces another point of failure. All code that is not maintained will fail due to external changes at some point in time.
Note one extreme weakness of such hacks, they cannot keep their insertions hidden from a reverse assembler, as it is always possible to write a reverse assembler and compile it without the hack being able to detect it, never mind change it. Similarly, with open source, it is always possible to add logging code to the kernel that the hack cannot detect and bypass. Code that did not exist prior to the hack being implemented, or never available to the person carrying out the hack cannot be modified by the hack.

Anonymous Coward says:

Re: Re: Backdoors can be anywhere including open source s/w

Agreed, they are not completely hidden (particularly with reverse assemblers), but the ting here is that with the various optimisations that compilers do do, various signatures in the object code can be recognised to place the compromised object code accordingly.

Any part of the toolchain can be compromised accordingly for this kind of purpose up to and including the linkers and loaders.

We see enough problems with source code having errors, let alone trying to determine what is actually happening with the object code generated.

The problem is that most people “trust” that the tools they are using are okay and don’t go that extra 100 miles to check the binary code generated.

I know that in my youth I would set aside time to examine the binary code produced particularly if strange errors were being obtained. But these days, for the kind of stuff I do, I don’t put in such time as I have other things that need to be done.

All I am saying is that backdoors can be put in without any changes being made to the source code.

DaveHowe (profile) says:

Audit guys are backpeddling a bit but..

Or at least this guy:

His original tweet was:
“We are considering several scenarios, including potentially supporting a fork under appropriate free license, w/ a fully reproducible build.”
But later followed up with:
“Just for the record, we are not ‘forking Truecrypt’. We plan to audit it and perhaps organize (financial) support around such an effort.”

Now, there IS a fork in the process of creation over at but as it is in the early stages of the process, and the Audit guys have yet to complete the rest of their study of the app crypto, it would be better to leave this on the back-burner until we know what bugs need to be fixed….

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...