There’s quite a bit of confusion still. It certainly smells like a website defacement at first, with a possibly compromised account/key.

But according to a supposed SourceForge representative (HN user “rgaloppini”) in the HN thread about this (https://news.ycombinator.com/item?id=7813121), there’s no indication of a compromised account. Granted, this HN user is a whopping TWO hours old. Certainly smells like bullshit at first sniff. And I can’t tell if this new user is claiming to be an actual representative from SF, or if s/he’s merely relaying info from SF that they have somehow gotten a hold of. In either case, I’m unaware of anything official coming from SF and am inclined to disregard this comment in the HN thread.

Frustratingly, I don’t have access to the keys that were on the truecrypt.org website prior to the recent changes. But, assuming the data from the concordia.ca link is valid… the provided keys match. Do the binaries and their signatures correspond to this key?

So… the binaries and their signatures correspond to this “new” key which appears to be the same as the “old” key. The key’s fingerprint also matches Google’s cached version of the truecrypt.org download page (third result):

So… the key is good? The binaries are signed against it? The fingerprint (appears) to match? And yet… the announcement page isn’t signed by the devs… And it just smells so fishy…

It’s all very confusing. I’m not a crypto expert, but it certainly looks like the “new” key is indeed the same as the old key, and the binary signatures correspond to it. Makes me think the TC developers have just thrown in the towel, or their key has been compromised –along with the truecrypt.org domain and the sourceforge account. Seeing as their identities are a complete mystery, I don’t exactly know how they could ever recover from a total compromise of keys, domains, and accounts. There’d be no way to assuage concerns that they are the “real” TC devs and not the imposters because every source of trust has been compromised. I’m not saying such an all-compromising attack of every account/key is impossible, but damn: it’d be a pretty impressive amount of work to compromise all of that.

I look forward to reading an expert’s take on the matter in the coming hours. In fact, I think this whole situation would be an excellent basis for a more real-world-based training exercise involving various cryptographic tools and how to properly use them to navigate a foggy situation like this one.

edit: Made slight edit for filename consistency when I crunched the digest of the files (I had renamed them on my machine at one point; editing so it’s all consistent)

I’m leaning toward this as the more likely scenario than an NSL canary. My understanding is that the 7.1a release hasn’t been touched in over a year. The only active work on the codebase that I know of has been to audit it. As well, the license for the 7.2 release was changed to remove the advertising clause. I’m not a lawyer, but I believe this was the only major hang-up in getting truecrypt to actually be considered “open source” by FSF and OSI (IIRC, there was also some concern about trademark usage). But then again, they went and gutted the actual source code for this particular point release, leaving me to wonder whether the license change only applies to 7.2 code or retroactively to any commit or point release that has the meat of the encryption code.

However… I suppose it’s just a sign of the times that the NSL canary possibility is more than “remote” and somewhere between “unlikely” and “well, maybe.” That… and the stated reasoning –Windows XP being EOL, ergo no more TrueCrypt– is just fantastically flimsy; surely the devs would just say “we’ve moved on.” Indeed, they’ve changed the license. Why not just come out and say that they’re leaving the project and feel free to do as you wish with the new open source licensing terms? Why the BitLocker suggestion? Why wipe the repositories? Why the big red letters and warning dialogs saying the program is insecure? Why go through all of the extra effort of gutting the codebase to generate a point release that only decrypts?

In short: this isn’t typically how orphaned or abandoned projects behave.

Hey, thanks for this! I’ve seen a bunch of assertions about the validity of the keys, but nowhere else such a detailed examination of it.

I think the most likely possibility at this point is that it’s effectively an NSL canary; the devs were coerced and gagged and rather than go mutely along with it implied compromise and shuffled people away.