Hacker News new | past | comments | ask | show | jobs | submit login
TrueCrypt suggesting migration to BitLocker? (sourceforge.net)
797 points by dewey on May 28, 2014 | hide | past | favorite | 382 comments

In order of likelihood:

    * Defaced site, timed to screw up a big announcement
    * Rogue content maintainer
    * Phase II of audit turned up something rather bad
      (edit: NO - see tptacek below)
edit: Variations on "developer forced to do this" (cf simmerian's comment):

    * Developer was big brother all along and they are shutting it down
    * Security vuln about to be disclosed, dev scrambles to inform (albeit poorly)
    * Legally or otherwise compelled to compromise source code,
      dev complies and/or nukes project from orbit
The last alternative would be suggested in part by the strange content of the page, assuming it is legit from the developer: Normally I'd expect at least something like "there's a major vuln that is unfixable and we'll disclose formally in a week/two, migrate now.".

After examining all the facts, I think it's most likely they just didn't want to develop it anymore:

    * PGP matches
    * Authenticode matches
    * SourceForge data was modified
    * DNS records were modified
And to top it off, let's put ourselves in the theoretical attacker's shoes, the binaries when run make no unexpected connection attempts or write to any unexpected places and don't appear to contain any unexpected imports, so if this was a hack, it's a very stealthy and very boring one. The most they achieved would be uninteresting to most attackers. It would only really be an effective attack against people who had TrueCrypt volumes but not a current copy of TrueCrypt as there's no compelling reason for anyone to upgrade to 7.2 and certainly they'd be skeptical after this. Any attacker with the intelligence and patience for such an attack would surely realize how poor an execution this would be. A better attack would be "here, it's TrueCrypt 8, it has loads of EFI support and mad security, everyone should install it, it's the best!". There's simply no reason to shut it down like this, unless the attack is just an elaborate practical joke.

It's quite possible this came from 1 big developer hack, but considering how the release was done, with full source and everything for every supported platform... if it was a hack, it's a very, very good one. They've also decided to modify the license terms, perhaps bringing it into compatibility with more common FOSS licenses.

I think it's far more likely at this point that the devs, who had not updated their software in years, finally decided to call the project over and have marked it insecure because the codebase is now unmaintained and should be assumed insecure.

I agree that it appears the developers are calling it quits. If you look at the diff itself, they have replaced large chunks of logic with an abort routine, passing the message "Insecure App".

This does not explicitly suggest vulnerabilities exist in older versions, but rather the latest version with these changes is very explicitly insecure and should not be used. This does leave room for issues to have been discovered in old versions - maybe rather than fix, they are throwing in the towel.

I think it's most likely they just didn't want to develop it anymore...

It would be so easy for the person(s) in question to just say that, though.

I don't know what to think.

After the years of silence and the previously infrequent updates, I don't consider it farfetched at all.

>>After examining all the facts, I think it's most likely they just didn't want to develop it anymore:

So they decided to end things with such an extremely juvenile behavior devaluating the years they have invested in this project even if not recently?

Unless the responsible one fell into clinical depression it's a pretty strange reason.

They haven't updated it for years.

I'd hardly call the behavior "juvenile" nor would i call it "devaluating". They've simply abandoned it and are offering alternatives.

I think suggesting BitLocker as a viable alternative to their work is "devaluing" their work. Who would trust BitLocker not to be vastly more compromised that TrueCrypt?

(Devaluating? sic? Or is that actually a word?)

You're right - few would trust it more. However, it is the closest viable alternative to TrueCrypt on the windows platform today.

They don't offer alternatives. Please take a moment to read the second page - the instructions for "other operating systems." The linux instructions make it damned obvious that someone is playing a game. The question is who and why.

If it's the actual TC crew, the explanations toward an NSL or a new vuln that an NSL or similar applies to seem to be about the only rationale - though even then, it seems to me it'd be possible to steer the code audit in the right direction.

Given the churn of new keys today, I'm more inclined to think that the comms of TC have been broken and the breach is being used to drive people away from the releases of the tool for which source is available.

They're offering an encryption product, not a service, an NSL would seem pointless unless they want to slap one at everyone who implements cryptography. and there's plenty of better ways for 3 letter agencies to obtain FDE keys. The Linux instructions just make it clear that your options and process vary per distro, if they're ditching the project I doubt they felt like writing piles more docs to describe every possible combination of loop-aes, dm-crypt, ecryptfs, encfs, luks, etc.

>> They haven't updated it for years.

As I said even if not recently they still invested many years into that project.

Of course it is juvenile to senselessly ruin the code and suddenly advertising a very different commercial product, especially without proper scientific reason.

Not to mention that precisely because they haven't done much work lately I don't see any reason why the developers would disfigure their project like that.

I think it makes sense, it can wear on a developer fairly heavily to be burdened by the user community of a cryptography product. Just look at this very thread, so many paranoid theories about NSLs and such, where they don't even make remote sense. They most likely just wanted to stop needing to work on the project or respond to comments.

They're not "advertising a very different commercial product". They're recommending you actually use a maintained alternative. Bitlocker is probably the most viable alternative on Windows.

It's also possible that Bitlocker solved the problem well enough for them so they saw no gain in maintain TC any further.

"Bitlocker is probably the most viable alternative on Windows."

How would a software with closed source from a company that has been gladly working with the US government in the past be a "viable alternative" to TrueCrypt? Really, please try to read the comments above before you enter the discussion.

Easily. It performs the same task, is actively maintained and supports things like EFI. If you know of a better alternative on the windows platform, please do tell, because I'm not aware of one and neither are the TC devs it appears. Just because an alternative is not as perfect as you would like does not invalidate it completely. If you try actually reading, you'll note that I am the poster of many of the comments above. Please avoid making an ass out of yourself in the future. And keep your retarded paranoia out of legitimate discussion.

One of TrueCrypt's best features was hidden volumes. As far as I know, BitLocker doesn't haven anything like that. I can definitely see that someone would have an interest in getting that shut down.

BitLocker lacks another one of TrueCrypt's most important features: open-source code, readable, verifiable, and compilable by any interested user. BitLocker is almost definitely already backdoored, so encouraging people to switch to that makes all of that data accessible by the powers that be.

I think it's silly to pretend like no authorities would have an interest in promoting the use of closed-source encryption techs. Apple and Microsoft were both willful participants in the PRISM program. TrueCrypt was the only open-source FDE software that had widespread adoption on non-Linux systems. After this, no major corporation or group is going to use TrueCrypt to encrypt anything anymore and will rely entirely on the backdoored encryption solutions provided by the NSA's known and confirmed compatriots.

Does National Security Letter sound depressing enough?

I guess the new license only applies to the release it is distributed with and this latest version removed encryption features so I doubt it will make the truecrypt project more compatible with FOSS licenses.

True, but they likely intended it for all releases and I highly doubt the dev(s) are going to burn their anonymity to go after you even if they didn't.

Though I suppose that's not the best legal rationale, now is it?

Could you post the PGP & Authenticode details? I was unable to verify the 7.1 releases.

This is legit and I am willing to bet.


The entire source has been modified to reflect the Sourceforge page its contents. Encryption process is disabled. The current binaries can only be used to "migrate". You can deface a webpage but the effort it takes to rewrite the entire source code, compromise the GPG, compromise domain, compromise mail servers et cetera is not minimal.

It is happening. Whether they are being forced to do so is a whole different story.

I agree that this really looks like it is legit. It looks like, for some reason (we don't believe in the legend version, do we?) they abruptly (the diff contains many normal changes also) stopped the development and are burning all the bridges. They also slightly changed the license so now the forks are free to not mention that they are based on TrueCrypt, they are not allowed to link to truecrypt.org site or mention the TrueCrypt name in their product's domain name. They also removed all the links to their site from the source code (even the donation page).

> we don't believe in the legend version, do we?

I dunno. We saw the legend version happening with a lot of people recently. Yep, we still mostly don't belive it, but...

What's the oposite to The Boy that Cried Wolf?

The element that does not square with any theories that suggest benevolent intent behind the change is the recommendation that users switch to Bitlocker. Surely, a Truecrypt developer who got served a gagging order to build in a backdoor would realise that a big and compliant target such as Microsoft would have been subject to the same measure long ago, and likewise that if a pre-existing vulnerability on a sufficient scale to justify this went unnoticed in an open-source project even after a proper audit, the situation is unlikely to look that much better in a closed-source solution (that only the makers and government agencies have access to).

While this might be reading a tad much into it, the language of the announcement, specifically the "...as it may contain unfixed security issues" bit, sounds like what somebody who just came out on the losing end of a heated debate about whether some bug-feature should or should not be considered the former would say. Knowing the vitriol and determination with which software developer arguments are often carried out, this would explain the observed combination of remarkable dedication and haphazard execution.

> The element that does not square with any theories that suggest benevolent intent behind the change is the recommendation that users switch to Bitlocker.

I realize we are firmly in conspiracy theory territory here, but perhaps the suggestion that users switch to Bitlocker is intended to be so patently absurd as to be a signal that the developers are under duress?

That's my take on it as well, even though it fails the Occam's razor test. This all sounds like a very understated way of saying "we can no longer develop truecrypt with impunity, and the only other options are closed source, and highly likely to be compromised out of the gate".

This is currently my favorite theory, for lack of a better word. It's also potentially pretty disturbing news. I saw another user mention the term warrant canary. I'd call it a warrant canary for the cautious/well informed. Unless there is some serious action on the horizon, no one well informed will ever use a truecrypt release past 7.2 ever again. https://en.wikipedia.org/wiki/Warrant_canary

My very first thought upon hearing this news was that just maybe the trucrypt devs are secretly cheering for others to come and replace the hole they fill in this world. Maybe this is the best possible thing they could do to inspire the next generation of truecrypt. They've laid a good foundation but they know they can't win the war for free information security on their own. So what better good could they do than to inspire the mother of invention; necessity.

I'd agree, that seems more believable than some of the other theories I've read.

As crazy as it sounds, I think you're right and it's just the developer(s) quitting (rage-quitting?) the project. Nothing else makes sense.

The Bitlocker thing seems strange until you realize that it probably really IS the best alternative for most users. The users who are paranoid enough to not trust Bitlocker can probably look out for their own security, so it makes sense to give instructions for the rest.

None of the explanations people have came up with regarding intelligence agencies and conspiracies really hold water. If the devs were compromised, I doubt they would be given the freedom to post something like they did today. If they were under some kind of NSL or gag order, this would almost certainly violate it.

No more than shutting down Lavabit violated whatever NSLs/court orders were directed at it.

> The Bitlocker thing seems strange until you realize that it probably really IS the best alternative for most users. The users who are paranoid enough to not trust Bitlocker can probably look out for their own security, so it makes sense to give instructions for the rest.

It seems odd to me that security specialists would recommend a flawed tool to 'the masses'. It just doesn't fit with what I usually read from people in this line of work.

It's pragmatic. BitLocker may or may not be flawed[1], but I don't see a lot of better options for disk encryption on Windows being presented.

[1] - Whether it's flawed or not depends on your needs. Not everyone cares about defending their data against an attacker with the resources of a nation-state - many just want their laptop's hard drives to be effectively inaccessible if the device is stolen or lost.

Agreed on the language/vitriol interpretation. I was thinking the same when I listed rogue content maintainer.

Another possibility - the author was required by a court order to provide a backdoor for unfettered access to truecrypt disk, and to not disclose the existence of the order. The solution was to modify the code so that everyone has unfettered access (i.e. disable encryption entirely) and make the recommendation that everyone switch to something else.

Question: has any such court order, ever, in the history of the United States, actually been given? Can it be given? Because that would be news to me.

Because while specific orders can't be disclosed if they'd give away information to the actual target, the general nature of such orders is well known - information can be demanded if held. You can't be compelled to engage in subterfuge though, and since such an order would be illegal, you could freely disclose it and let the civilian courts strike it down.

As one might note from the Lavabit fiasco, things only got weird because Lavabit decided to screw around being non-compliant, while also always having the technical capacity to decrypt everyone's email (and thus opening up the legal doorway to just seize the keys and all the data, rather then the tiny chunk that was wanted).

Maybe while looking at the code themselves they found a very bad bug which would make previously made encrypted partitions easily crackable, and fixing it would obviously make the world aware to this, and they don't want to endanger or ruin the lives of everybody who has had a truecrypt container with sensitive data taken from them (for example to a malicious government), so the only way to go for them is to tell people their product should not be used any more and is bad.

That's rather radical move in the face of the audit currenlty being conducted. If the bug is so dramatic, it will be revealed by the audit with high probability rendering this move practically useless.

It could be that they've simply lost interest in developing it. It's quite the ongoing responsibility, and they may well be tired of working on it - a decade is a long time in anyone's life.

If this is true, then perhaps such listlessness was also catalysed by the ongoing audit. Maybe seeing such a mass of crowdfunding income towards a project to pick Truecrypt apart, in contrast to the scant donations to its development, disheartened the authors towards further work?

Abandoning it in this rather dramatic way ensures that Truecrypt's users are warned against using unsupported software where any bugs will remain unfixed. This is especially important when such bugs revealed in the future (and maybe ones already known) have the possibility of being deleterious for security.

If you're developing a free product and you're going to throw in the towel anyway, why not just open up the sources with a liberal license and/or hand the project over to someone else who's willing to carry the torch.

Cryptsetup 1.6 supports Truecrypt volumes now, using its own reimplementation:


So at least Linux users should be covered.

The license was changed with the new release.

Edit: The following clause was deleted in the 7.2 release.

- c. Phrase "Based on TrueCrypt, freely available at - http://www.truecrypt.org/" must be displayed by Your Product - (if technically feasible) and contained in its - documentation. Alternatively, if This Product or its portion - You included in Your Product constitutes only a minor - portion of Your Product, phrase "Portions of this product - are based in part on TrueCrypt, freely available at - http://www.truecrypt.org/" may be displayed instead. In each - of the cases mentioned above in this paragraph, - "http://www.truecrypt.org/" must be a hyperlink (if - technically feasible) pointing to http://www.truecrypt.org/ - and You may freely choose the location within the user - interface (if there is any) of Your Product (e.g., an - "About" window, etc.) and the way in which Your Product will - display the respective phrase.

Indeed it was.

As was its ability to encrypt, apparently. I don't exactly count those as one in the same.

It may be the same strong sense of ownership and control that precluded the liberalisation of Truecrypt's license during its lifetime in the past decade.

Your reply seems to be the most sensible out of the lot. (Side note: I presumed there'd be a couple other ones that suggested it's open source--never mind that prior to the removal of some of the license text it wasn't "free as in beer" open. To be fair, I had forgotten myself that TrueCrypt wasn't exactly open source.)

Perhaps ownership does run deep, even if you've never really released a product for money and it's always been free. Still, it's something I don't understand: If I had a tool that I released for free and finally gave up on it, I'd like to think I'd open it up under an exceptionally liberal license or just dump it in the public domain. That'd be especially true if it had a lot of users.

That's what makes me think that if this isn't some elaborate scheme it's likely the result of some sort of legal requirement or action (e.g. Lavabit) which would preclude the author(s) from doing anything else with the software. It's a shame they couldn't take a scorched earth-esque approach of dumping everything in the public domain, including notes on why this was happening, everyone else be damned, but I'd imagine their entire career might be in jeopardy at that point (and possibly their freedom).

The one thing I have to add. Maybe by taking this route, the author(s) hope to inspire others to see the obvious need for a project like truecryp more dramatically. It's not like old bin/source repos aren't available in 100 different locations across the net; if you need the program you can get it. But this action does send a strong message and it's that there is no adequate existing cross-platform solution to this problem outside of trusting your os or using (not so plausibly deniable) file archives. I'd like to think that the author(s) are trying to highlight the necessity while secretly cheering on the next generation of trucrypt.

That's a good point, and it's certainly true on many fronts. Commercial alternatives are questionable at best (particularly given the NSA revelations), but the F/OSS community (and others) relied perhaps too heavily on popular software like TrueCrypt to fill the void. Now that it's gone and the other alternatives aren't quite as cross-platform as one might like, it does seem to illustrate a dearth of cryptographic software available for the general public.

Given that border searches of electronic hardware are becoming more commonplace in the US, I should think that something like this is important. I know when I was driving back and forth to university, the thought crossed my mind when I had my laptop with me as I went through the border patrol checkpoint that there wasn't anything much I could do (outside lawyering up) if they took it upon themselves to grab it and search. Sure, the worst they could have done was read my email (and maybe clear out the junk folder for me while they're at it), but it was the principle of feeling so violated by the act itself that drove me to stuff all my school work into a TrueCrypt volume.

(This was years ago, and TC was the best option for XP. Though I later switched the laptop over to Linux.)

It's already open-source.

As far as I know, its license is incompatible with other open source licenses due to an advertising clause (all derivative works have to state "based on Truecrypt" somewhere in the documentation or via use of the software). The old four clause BSD license had a similar issue.

One of the changes in the newly-uploaded version is indeed a change in the license.

It does appear that the authors have removed the advertising clause in this latest license version. Also the section on commercial licensing, some mentions of registered trademarks, and all specific references to the truecrypt.org domain, including email addresses.

However it's unclear if this change is only for Truecrypt 7.2 or can be applied retrospectively to previous versions. As the authors have deleted sizeable portions of the encryption code in this final version, such ambiguity could be problematic.

the devs themselves are anon

no one is going to come after anyone for licensing fees

The donations thing could be true, but Truecrypt simply wasn't a donation-friendly project.

It was developed in almost total secrecy, with binaries and code being tossed over the wall once in a while, provided under a non-OSI license.

I built it from source a few times, but Truecrypt was used by a lot of people, far beyond the developer community, people who totally lacked the technical skill needed to compile it. SO it's a safe bet the majority just used those binaries. And those binaries actually changed without warning more than once, independent of the version changing. That alone bred suspicion and fueled the demand for an audit.

The behavior of the developers (and their total lack of a public presence, regardless of the reason) may have also discouraged donations. Same with the behavior of the forum moderators, whoever they were.

What if this is an attempt to smoke out the TrueCrypt devs?

While this move seems odd, the new binaries are properly signed and the domains have been updated accordingly. If this was another project, like Rails, the maintainer could come out and say they were hacked and the last good version was X. Otherwise, the project would likely die off.

But since we know so little about the TrueCrypt maintainers, there's little way for us to hear that this isn't legitimate. In order to keep the project from dying (if this is a hoax), they would have to prove that they are the maintainers, because any plausible deniability would undermine their claim that the change was not legitimate.

Wouldn't they just have to published a signed message stating that the change was not theirs and the key is compromised? Or better yet, revoke the key?

If two groups with opposing messages control the key, it's pretty clear that the key is compromised in some manner.

If 7.2 is part of the hoax, then they would be signing with a compromised key. This would be evidence, but would not be conclusive.

No, because the suggested "hackers" have published a signed message.

Doesn't matter. Publish another message signed with the same key saying "this key is compromised."

> If two groups with opposing messages control the key, it's pretty clear that the key is compromised in some manner.

If the audit turned up something bad, the obvious step to take would be to publish it in all detail, fix the flaw, and then tell users to upgrade as soon as possible. Not go "OK SHOW'S OVER, USE PROPRIETY SOFTWARE FROM NOW ON".

Nitpick: Truecrypt is proprietary (it's source is viewable, but you aren't licensed to distribute modifications of it).

Open(ish) source but non-free.

Yes. This would be just about the worst way to announce and make recommendations. Looks like defacement to me.

Unless some kind of backdoor was about to be discovered...and they'd rather close it down before it gets discovered.

My order of likelihood is #1. This is a canary. https://en.wikipedia.org/wiki/Warrant_canary

Do agencies like the NSA/FBI/etc have the power to make a company publicly lie against their will?

if you count lies of omission, yes. you can be required as part of an ongoing investigation or court case to not talk about it. The legal term is "gag order".

If you are ordered not to communicate something, you are ordered not to communicate it. Doing a "I'm not not telling you something, ha ha" might work on the playground, but not in real life.

I meant can the NSA force you to keep publishing "we have not worked with the NSA" when you have worked with them.

* That's a lot of wasted effort for a defacement with seemingly no motive except some (uncredited) lulz.

* Possible, but once again I see no motive that would produce this brand of outburst.

* And it's unfixable? That would be a world first.

I think it's much more plausible this is some powerful entity forcing a hand. We know by now there's plenty of motive and candidates to fit that shoe.

It is a lot of effort, and you make good points. I'll add a note to my original post.

Phase 2 of the audit hasn't started yet.

Seems to point towards compromised SF account.

There's a new binary that recommends moving to BitLocker during install, and the signature matches.

Edit: with a new, compromised key.

Project on SF is still available if you have a direct link:




Odd, 6 hours ago someone updated the TruCrypt-key.asc files, then 3 hours later posted all the new binaries.

Also odd is whoever posted the new binaries completely yanked all the previous ones, leaving only the new and questionable binary available for download.


Looks like it's the same key as before (F0D6B1E0)

On a day like this, compare the entire key.

It's the same. Original key: http://pgp.mit.edu/pks/lookup?op=get&search=0xE3BA73CAF0D6B1...

And the new key can be found on the SF site.

Is source still available? Can we check the commit tree for anything suspicious lately? Can someone compile it and check the hash against the 7.2 binary being offered?

It's not that simple. It won't match anyway. Signatures, compiler versions, SDK versions, etc.

This guy managed to compile a previous version and have it match the released binaries https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...

Not quite. First, it was a ton of work to do so. Second, in the end he in fact only managed to match most of the released binary. Then, for most of the unmatched parts he came up with some solid arguments why they would be different (timestamps, pathnames and such). However, in the end there were still a couple of chunks of unmatched data that he couldn't explain why it has the value it does. Finally he argues that these chunks probably can't contain any hidden backdoors. This last bit I have a bit of a problem with because it's just speculation, all the rest of the research is very solid and without guesswork, and the conclusion of the article IMO incorrectly states he "has matched the binaries".

I'm chalking this up to, after all that work, having come so far, kind of wanting to say you did it, and providing a few (IMO) hand-wavy arguments why those last impossible chunks of bits probably don't matter, instead of having to admit defeat after being able to account for 99.9% of all bytes.

I can understand that, I've been wanting to type "but it's probably not backdoored" three times already typing this post, and catching myself because really I have nothing to go on to make or back that statement.

Yes, but did they sign it using the same key they were using before?

edit: Apparently not, according to the link @Alupis posted.

Their mail server is on the same IP as truecrypt.org, and it's now rejecting mail.

Also might be coming from lack of donations. I remember that button becoming more and more prominent lately...

That would not result in a message of "True Crypt Is Not Secure!!!!" in bold red. Seems to be geared towards frightening people.

I concur -- likely an elaborate website deface.

That's not what the message says, though.

> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

That is a perfectly reasonable thing to say if you are abandoning security software. Any issues discovered will not be fixed, so you should stop relying on this software for security.

Scroll all the way to the bottom

As irrational it may be, I've seen people writing something like that out of frustrations...

I don't think any legit organization would do that, but what if it's maintained by a small team or even individual -- I don't think I've ever seen a single face of TrueCrypt developers out there...

Good point.

If true, I'd much rather have them post a countdown clock and say "If we don't reach X funding goal in donations by date Y, then we will be forced to close the project". Funds would come in then... a lot of people depend on truecrypt.

* SourceForge account compromised and developers unwisely stored private keys and other information somewhere inside this account, permitting the attacker to compromise lots of other stuff and generally have a blast.

NSA is obviously in on it. Who else would recommend using holy-bug-riddled proprietary-back-doored-on-purpose encryption software? ;-P

I choose to believe Niels Ferguson when he says "Over my dead body.": http://blogs.msdn.com/b/si_team/archive/2006/03/02/542590.as...

If I were the NSA, I'd try to get one of my hundreds of world-class cryptographers a job on the BitLocker team.

In fact, BitLocker would be the first thing I'd weaken. Because

1) It's closed source, hard to externally audit.

2) It's one of the most used encryption packages in the world.

3) Microsoft's poor security track record provides excellent cover if the weakness is ever found.

Closed-source security software is a recipe for disaster.

A NSL is powerful enough to render all this moot. Therein lies the great danger of NSLs.

2 things.

1) Obviously I was joking in my comment above.

2) That post is dated well before common knowledge of how "in-bed" Microsoft is with the USA spy agencies (at least management is).

This is a topic for another discussion, but I just want to point out that, of course someone being coerced under gag order to install less-than above-water "features" and/or purposefully weaken the product would say exactly what is in the blog post.

> Over my dead body.

> Well, maybe not literally---I’m not ready to be a martyr quite yet

So, in short he's written 8 years ago that in principle he was totally against backdoors. Times have changed so much that a statement of that tone is almost entirely useless IMHO.

Providing some details from SourceForge:

1. We have had no contact with the TrueCrypt project team (and thus no complaints).

2. We see no indicator of account compromise; current usage is consistent with past usage.

3. Our recent SourceForge forced password change was triggered by infrastructure improvements not a compromise. FMI see http://sourceforge.net/blog/forced-password-change/

Thank you,

The SourceForge Team communityteam@sourceforge.net

2. We see no indicator of account compromise; current usage is consistent with past usage.

I'm calling BS. This site was disabled repeatedly for exceeding bandwidth today. I find it hard to believe traffic is as usual.

Actually, this is standard behavior for the SourceForge project web service. Bandwidth usage is capped to prevent folks from serving files from project web instead of the mirror network-backed download service. Staff saw the surge in traffic to the project web site, confirmed it wasn't file serving activity, and re-enabled the site.

um... we're all looking at the site due to the change. We all used bandwidth.

I think it's fairly safe to say that rgaloppini meant account usage. i.e login and other authenticated activity.

- Signature is valid, so it's not a defacement. ( http://www.reddit.com/r/netsec/comments/26pz9b/truecrypt_dev... )

- The version there works and does not seem to have a trojan, so probably not a regular hacker. ( https://news.ycombinator.com/item?id=7813373 )

- Instructs to migrate to dubious alternatives, so it's not a legit security effort.

- License change, precise instructions and decrypt-only version indicate it's not a completely rushed press release. (license change: https://github.com/warewolf/truecrypt/compare/master...7.2#d... )

- On the other hand the Linux instruction is a joke, so it's not completely well thought either. ( http://truecrypt.sourceforge.net/OtherPlatforms.html )

- The security audit was so far ok, so it's not a sudden vulnerability discovered there. ( https://twitter.com/matthew_d_green/status/47174183672207360... )

- No details whatsoever other than a "may contain unfixed security issues", so it might be an automated release (doesn't know what happened) or gagged reaction (can't say what happened).

- Source code includes unrelated changes, so it probably comes from a developer. ( https://news.ycombinator.com/item?id=7812674 )

If I had to wager a crazy bet, I would go with newly developed Dead-Man's-Switch gone wrong.

Edit: someone on Reddit has an interesting view that it may be a halfhearted attempt at complying with an NSA request ( http://www.reddit.com/r/sysadmin/comments/26pxol/truecrypt_i... ).

If I were to wager a non-crazy, Occam's Razor-compatible bet, I'd say the author had a bad day, saw one too many digs at the quality of their decade-long work, got pissy, and decided to call it quits. I love popcorn-munching news as much as anyone, but this probably isn't it.

Then why pour so much work into re-authoring and re-releasing the program for all os's? And why offer such a canned bullshit explanation like the end of the availability of windows xp? All to show the trolls how much they miss truecrypt now that it's gone? I don't think so... anyone can find an old cloned repo/bin. I don't think it's impossible but it doesn't sit right with me that someone who could write/manage a program as objectively beneficial to society as truecrypt could also write such horrid bullshit that stands against every principal of FOSS. That being said, I've witnessed lives torn apart by depression first hand and it can be easy to idealize a person you've never even met so who really knows.

Well, free project by anonymous developers right?

At some point the reward metric for that shifts away from your interests. It's never going to be picked up by like, major companies for enterprise-y use since Bitlocker has that market sewn up and it's never been really practical to use with Linux (from what I recall of looking into FDE for my notebook a few times in the past).

That's been my thinking as well since this came out yesterday. And it kind of makes sense why they modified the license to no longer require attribution, the only thing left in 7.2 is decryption related code, this would allow 3rd parties to distribute derivative works around decrypting legacy volumes (and possibly migrating to other encryption methods). But would stop anyone from creating a fork of earlier versions that still contained the encryption routines.

I'm taking the risk of sounding sarcastic, which I don't want to, but:

> Signature is valid, so it's not a defacement.

Under normal circumstances, I would assume the same, but given the exceptional situation and chaos ensued, I think it's not entirely silly to think that this could be a case of http://xkcd.com/538/

That could explain the inconsistency of a hypothetical scenario where the key is compromised by a third-party but the owner doesn't come out. If they are under physical threat, I suspect a lot of the "normal" measures like revocation certificates would be hard/impossible to achieve.

infosecslave said in a dead comment:

    [...] you have to consider the fact that Truecrypt project
    was started before FDE was popular, maybe their goal all 
    this time was to popularize such encryption. With XPs 
    demise that goal would have been achieved as every  
    current Windows version comes with Bitlocker.
Your comment is dead but makes a lot of sense, especially in light of the message on the website:

    The development of TrueCrypt was ended in 5/2014 after
    Microsoft terminated support of Windows XP.
I don't agree Bitlocker is a sensible alternative, but this piece does fit the puzzle.

"..as every current Windows version comes with Bitlocker."

It's only available in Ultimate and Enterprise Vista/Win7 and Pro/Enterprise versions of Win8. Lots of machines ship(ped) with only Win7 Home Premium or vanilla Win8.

One of the planned features according to the TrueCrypt website, was "Full support for Windows 8".


Server 2003 is still a supported version of windows for another year.

>If I had to wager a crazy bet, I would go with newly developed Dead-Man's-Switch gone wrong.

That's an interesting thought, although I don't think there's any way to verify that it's actually gone 'wrong', is there?

If it was operator error during the development of a Dead-Man's-Switch, the developer will probably come out in public explaining the situation and apologizing.

And if this is a Dead-Man's-Switch gone right, why are they advocating the use of BitLocker and searching for random Linux packages?

Edit: is "coming out in public" the correct term here? I have a feeling it only applies to closet-like scenarios.

If it was a hastily constructed DMS (such as in the event of imminent threat), the author may not have had time to research and test a comparable Linux alternative. If you knew that something bad could happen, you would work as fast as possible to set it up, rather than risk not being able to have anything working in time.

The reason why is quite simple: if a malicious third party were to raid or steal the private key, this kind of deterrent message should act as ample warning not to trust any further releases than what has already been released. If a government agent were to capture a developer and hold him or her hostage to attain the key (and thus release a backdoor), this type of DMS would immediately draw scrutiny to any actor attempting to release a new version that claims differently. If anything, the implicit statement is "continue using 7.1a and do not update beyond that in the event that something newer is offered." In light of the recent audit, it appears that 7.1a is secure -- and as a result, it can still be used for cryptography purposes (however subsequent releases may not).

I just had a thought that might negate such a thing in the eyes of the general public (or at least the easily trusting sorts).

Let's assume that this is a faulty DMS that was slapped together due to imminent threat by state actors. If these state actors were sufficiently powerful, couldn't they instead press ahead anyway with obtaining the developer's private keys, account data, etc., while publicly parading either the real developer (or an actor) in front of the spotlight briefly enough to claim that this was all a mistake? Next, release another series of new versions (with backdoors) that are fully controlled by the state actor under the guise that they're perfectly okay.

Of course, this would itself be easily defeated by either examining the history of the individual who claims to be the developer (if applicable) and through some scrutiny of the new binaries, although I'd imagine the latter would be anticipated by the actors behind the charade.

The closest thing in my mind that this resembles is a warrant canary as someone else pointed out earlier today. I suppose that in effect the DMS and canary achieve roughly the same goal so perhaps I'm just splitting hairs at this point. I also don't see either of these scenarios working perfectly except to warn people who are themselves already somewhat paranoid.

Why have dozens of steps and seventeen screenshots detailing how to migrate a Windows partition and only a joke line for the Linux version? And why Bitlocker? Then there was the license change, new version with different features... This imbalance of effort strikes me as incredibly odd if the author was merely rushed.

Linux users can be trusted to work things out for themselves?

I'll wager most Linux users don't even use TrueCrypt, since we've had FDE in the form of LUKS/DMcrypt since forever, and could not give a damn about being able to read those partitions from other OSes (as if! Since when do Windows and OSX support Linux filesystems? it's always been the other way around).

>And if this is a Dead-Man's-Switch gone right, why are they advocating the use of BitLocker and searching for random Linux packages?

One possibility is that they did it this way specifically because it's legally compliant with some order they got, but suspicious enough to raise alarm in the tech community and telegraph that something has gone deeply, deeply wrong.

This could be a warrant canary.

I don't think it's important what alternative they are suggesting.

The important point is that the developers (?) are advocating that users stop using their product.

Forest through the trees, if you will.

I can imagine how TrueCrypt with all the features like the plausible deniability was a major pain in terms of 'national security'.

And it is apparent the project was shut down by the original developer in a way that at best satisfies a gag order but doesn't actually hold up to scrutiny, so I see only two possible explanations for what happened:

1. An NSL with a gag order;

2. A nice lump sum of money in exchange for silence.

Or of course a combination of the two which is the most likely.

I don't blame the dev - he obviously spent years developing software which provided nothing in return.

I can only say one thing - if you want to hide stuff from the big brother, don't use BitLocker! ;-)

>- The version there works and does not seem to have a trojan, so probably not a regular hacker.

Incorrect, all the guy did was compare diffs of the source. He did not compile the source to make sure the binaries matched.

Are you sure? He does say "binaries when run make no unexpected...".

And matching binaries is not a trivial task because of OS, compiler and SDK versions. The last time someone did this for Truecrypt it made the news: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...

Binaries could have code that will activate in future.

If you have a copy of the source that you've vetted, and you can compile it in such a way that the resulting binary is a bit-for-bit match of the developer released binary, then you know that either there is no future-activation code or you missed it in your review or your compiler was itself compiled maliciously with the intent of inserting malicious code into that exact version of truecrypt every time it was compiled. Or there is no future activation code.

which is a fucking pain in the ass as stated such that it is a newsworthy feat?

Suppose that the author received a secret order from a secret court that required the author keep secret the secrecy of the secret order from the secret court. Furthermore, the author was secretly required to turn over his secret signing key to a secret third party. If you were the author, what would you do? Consider your options. One is that you could issue an update with a warning that the program is no longer secure. Even though the program really is, at this moment, secure. The only source code changes are to insert the warnings. But what the warnings are warning you about, but cannot just come out and say, is that the program will not be secure in the future because a third party now has the keys to sign authentic new insecure versions. This wouldn't be unlike Lavabit shutting down. The author is choosing to fall on his sword for the good of everyone.

Continuing the thought experiment. By stating the "reason" you're shutting down is that your project is "no longer necessary", then (i) your userbase will rapidly infer that the reason is odd (e.g., https://news.ycombinator.com/item?id=7813799 ), while (ii) you can plausibly defend closing down with a straight face, in court if required ("Our raison d'être no longer applies. So obviously this was the perfect time to shutdown the project for totally this reason and not any others.") Additionally, by changing the TrueCrypt License from 3.0 to 3.1 (removing the clause requiring advertising truecrypt.org), you tacitly support TrueCrypt forks while simultaneously de-emphasising the now-compromised truecrypt.org.

This is without a doubt the most parsimonious explanation for all available evidence.

That strategy would be consistent w/ Peter Watts' The Scorched Earth Society: A Suicide Bomber's Guide to Online Privacy: http://boingboing.net/2014/05/27/peter-wattss-the-scorched-e...

I bet the number of days they had to turn over the keys was very low (~48hrs), hence the ability to get the commits at the last minute before the deadline but still do a proper release process and building binaries for each platform.

Interestingly enough, they also changed the TrueCrypt license.

    -TrueCrypt License Version 3.0
    +TrueCrypt License Version 3.1
This lead me to think about the legal implications of changing a software license using stolen signing keys, when signing keys are all that you have to verify that the software is official (such is the case with TrueCrypt and its anonymous authors). If the license is changed, and the package is signed with the same signing keys, can I legally use the new license in derivative software?

The new license removes the following restrictions regarding attribution:

    -    c. Phrase "Based on TrueCrypt, freely available at
    -    http://www.truecrypt.org/" must be displayed by Your Product
    -    (if technically feasible) and contained in its
    -    documentation. Alternatively, if This Product or its portion
    -    You included in Your Product constitutes only a minor
    -    portion of Your Product, phrase "Portions of this product
    -    are based in part on TrueCrypt, freely available at
    -    http://www.truecrypt.org/" may be displayed instead. In each
    -    of the cases mentioned above in this paragraph,
    -    "http://www.truecrypt.org/" must be a hyperlink (if
    -    technically feasible) pointing to http://www.truecrypt.org/
    -    and You may freely choose the location within the user
    -    interface (if there is any) of Your Product (e.g., an
    -    "About" window, etc.) and the way in which Your Product will
    -    display the respective phrase.

Interesting, especially since the author(s) are anonymous and not working off public repositories, it will be very hard, if not impossible, for them to prove that they did not release this software.

If two groups with opposing messages control the key, it's pretty clear that the key is compromised in some manner.

Only if the derivative software is based on this 7.2 release, which, given its authenticity is in question, is in violation of the prior license version.

If, and only if, this is a legitament change done by a majority copyright holder(s) and/or project owner.

Of course, but when all you have to verify that a change is by the copyright holder/project owner is a signature, the whole situation becomes very murky.

The only authenticity test that I can think of is to actively distribute a fork of TrueCrypt using the new license and wait to get sued. If you get sued by the copyright holder (who would have to come out of anonymity to sue), then you can be sure that the new license was unauthorized. Not the safest way to test authenticity, but it should work.

hurrah, they removed the obnoxious advertising clause.

....but only with the 7.2 version that isn't actually encrypting anything.

Is it possible that this is the result of a "dead man's switch" (DMS) set by the developer(s)? Perhaps a (continually updated) process was set up so that TrueCrypt would shut itself down if the developer were unable to prove he or she was still actively maintaining the software.

I can see a couple of scenarios where this would be wise:

A) The developer passes away, leaving nobody else to maintain TrueCrypt. Zero-day 1234 is discovered which compromises TrueCrypt. The DMS activates, depreciating the software and advising users to migrate to another alternative (why BitLocker, I have no idea).

B) The developer(s) is(are) coerced into compromising TrueCrypt in some way. As a part of the coercion, the developer(s) is(are) unable to demonstrate proof of life to the DMS, so the system nukes itself.

What about the version 7.2 released? Either the dead man's switch:

a) knows how to change the code to make such a version

b) is updated often to keep up with the main branch

c) was developed recently

From that, "a" is wildly unlikely because coding is hard. "b" indicates a lot of work to maintain the DMS tool, which goes against the bare bones HTML page we are seeing and poor Linux instructions.

It could be something newly developed because they knew they were in danger. Or it accidentally triggered during development, which would explain why is it updated and why the warning page is lacking.

the page specifically mentions that it's ending support in may because ms is dropping xp support, though

Not quite, though. The page says "The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP." We can infer that the two are connected, but it would be equally valid to say "The development of TrueCrypt was ended in 5/2014 after Snowden interviewed with NBC."

The reason I make this distinction is because continuing from a cautious/paranoid perspective, the DMS might not say "WARNING! Dead Man's Switch Activated! If you are reading this, I may have been compromised, and am no longer available to maintain TrueCrypt." It's possible that the landing page simply references a relatively innocuous event in the cyber security world to plausibly discontinue the software. The best evidence I have for this is the fact that TrueCrypt didn't shut down precisely when XP support was dropped. (In fact, according to http://www.microsoft.com/en-us/windows/enterprise/end-of-sup... official support ended in April, not May like the landing page states.)

A very interesting comment from netsec: http://www.reddit.com/r/netsec/comments/26pz9b/truecrypt_dev...

This is very strange. I have another theory since I don't believe in coincidences. We don't know the real author of TrueCrypt. I think someone found his identity (cough NSA) and made him an offer like lavabit.com received. This time probably with security classification so he can't talk about that. HOWEVER, if we take a look on diff of his code, we can see two interesting things:

    messages about TrueCrypt not being secure
    and the second thing he changed everywhere U.S. text to United States
Do you think that somoene who is closing a project would pay attention to doing such thing? I don't think so. I think that he tried to point a real reason of closing his project by that. I won't be surprised when truecrypt fork appears in TOR network soon...

Interesting, but probably unrelated:

http://www.reddit.com/r/netsec/comments/26pz9b/truecrypt_dev... says:

> I asked around and apparently Visual Studio switched from generating "U.S." to "United States" in VS2010. Hence it is probably just the author having upgraded their VS at some point recently.

There was a lot of unrelated changes, this release was most likely just cut off their development branch.

The point is that a search and replace from "U.S." to "United States" is an unusual change. I have not seen evidence of this firsthand yet so I am just taking Moral_ on his word but if that is the case and there are a number of occurrences then it is certainly an interesting thing for the author to think to change.

I just came across this on Twitter: https://github.com/warewolf/truecrypt/compare/master...7.2

This is supposedly the commit for the 7.2 release. Just looks like a bunch of code replaced with the app aborting as insecure.

I'm not sure how legit this is, the repository was just created a few minutes ago. Apparently there is a new binary release that goes along with this, though.

[I've created a fork here just in case the original goes down: https://github.com/timothyarmstrong/truecrypt/compare/master...]

Notice the added functions like IsNonSysPartitionOnSysDrive and ResolveAmbiguousSelection, and all the unrelated minor changes like the comment line in Common/Volumes.h. Looks a lot like they based it on current pre-release development code.

Sourceforge seems to have recently updated their password hashing algorithm, so that might hint at the cause of a compromise. Here's the body of the email sent to me on the 22nd:

  To make sure we're following current best practices for security, we've
  made some changes to how we're storing user passwords. As a result, the
  next time you go to login to your SourceForge.net account, you will be
  prompted to change your password. Once this is done, your password will be
  stored more securely. We recommend that you do this at your earliest
  convenience by visiting the SourceForge website and logging in.
  And, as always, be vigilant about password security. Use a secure password,
  never include your password in an email, and don't click on links for
  unsolicited password resets.
  If you have any concerns about this, please contact SourceForge support at
  Best regards,
  SourceForge Team
  SourceForge.net has made this mailing to you as a registered user of
  the SourceForge.net site to convey important information regarding
  your SourceForge.net account or your use of SourceForge.net services.
  We make a small number of directed mailings to registered users each
  year regarding their account or data, to help preserve the security of
  their account or prevent loss of data or service access.
  If you have concerns about this mailing please contact our Support
  team per: http://sourceforge.net/support

Sourceforge's representative says it's unrelated: https://news.ycombinator.com/item?id=7813121

This is creepy as hell.

No mention of why it's supposed to be not secure - it's an open source project so it would be easy to point to a specific vulnerability. All of this shortly after passing audit. There are detailed steps towards switching to supposedly secure closed-source solutions by companies known to be working closely with the NSA.

Also, since when do open source projects suddenly decide they are not as good enough as a closed-source alternative and then stop the project? Are we in danger of seeing a similar message on the homepage of LibreOffice and OpenOffice, declaring that you should switch to Microsoft Office?

I can't even begin to imagine a valid scenario in which something like this would be put up by the developers, with no pressure other than some fatal security flaw about which they just really don't want to talk.

It doesn't matter why. If "we are now insecure" then the last thing you say is, "so please download these new versions, used only to decrypt your old files and nothing else." No we won't tell you what, if anything, was wrong, so you can make an informed decision.

The motivation would be so that if you had a TrueCrypt archive lying around on a drive that you find in 5 years time, it would be possible to decrypt it - but they don't want to allow encryption because they won't be continuing development, and so fixing future bugs will not be possible.

If that's the motivation then in 5 years' time, who's to say the new version will work as well (assuming that it also won't be updated)? That doesn't make any sense.

They're saying that one should not continue to use orphaned software (when it's so security critical). So they're stopping the distribution of the encryption part of it, and continuing to distribute the part of the software that decrypts the code. This means that if (in five years) you find an archive that you can't open without TrueCrypt (and you uninstalled it etc) you'll still be easily able to find a signed version that will decrypt it for you.

At the same time, the developer clearly doesn't want people to be encrypting new archives with it, so have removed that functionality.

Removing the software in total would have lead to many mirror sites springing up, most with unproved providence (and a great opportunity for exploits). This method allows an official version to still exist (unmaintained, but still compatible with the current archives), whilst severely restricting new usages (by strongly warning against it and requiring using the dubious mirrors to obtain the software).

> This means that if (in five years) you find an archive that you can't open without TrueCrypt (and you uninstalled it etc) you'll still be easily able to find a signed version that will decrypt it for you.

That still doesn't seem to answer the point. The differences between 7.1* and the questionable 7.2 are exclusively limited to what was ripped out. In 5 years, 7.1 and 7.2 will likely work precisely the same in terms of decryption. If a glibc update or similar breaks 7.1, it'll likely break 7.2.

Perhaps I wasn't clear enough in my first comment, but fundamentally it seems like a silly argument to make to suggest that distributing a new release for some measure of future proofing readability is necessary. Outside "don't use this, it's broken," I can't really see "this will still work in 5 years' time" as a valid reason.

No matter how far in the future: If you find an 'old' TC volume/drive all you need to do is to install Win2k/XP/Vista/7, install TC 7.1a and decrypt. There's simply no need and practical use for a TC 7.2 with crippled functionality. Except one is forced by 'force majeure'. BTW: 7.1a is around on so many mirrors (and would be uploaded by enthusiasts if not) that it is ridiculous to post a crippled 7.2. Except one is forced by 'force majeure'.

I tried sending a message to their contact email PGP-encrypted to their public key, asking them for a PGP-signed confirmation. And it came back:

550 5.1.1 <contact@truecrypt.org>: Recipient address rejected: User unknown in local

If they got hacked, it's not just their sourceforge account.

I'll leave others more knowledgeable in such things to comment on the legitimacy of this, but one practical thing I'll note: the assertion on the site that Windows Vista/7/8 has support for encrypted disks is only half true. Quoting from Wikipedia [1] "BitLocker is available in the Enterprise and Ultimate editions of Windows Vista and Windows 7. It is also available in the Pro and Enterprise editions of Windows 8."

Since a lot of domestic users will be using Home or Home Premium versions of Windows, and as one of those users who uses Truecrypt for full disk encryption, this does not leave us with as easy a migration path as this site now suggests.

[1] https://en.wikipedia.org/wiki/BitLocker_Drive_Encryption

It's worth pointing out that it doesn't leave people with a free migration path, but it is absolutely easy. Windows 7 and 8 both support "anytime upgrade" functionality, where you can pretty trivially upgrade from Home/Home Premium to a higher-level edition of Windows without needing to reinstall anything or move data--just as long as you pay for the more expensive edition.

Also there are 3rd party (paid and free) FDE tools available.

The advice for Linux is "Search available installation packages for words encryption and crypt, install any of the packages found and follow its documentation."

So... just any of them, then? Sure, ok.

I think the point was just that the advice given was so vague, that it seems suspicious that this is actually an official communication.

Wikipedia entry was edited and reversed with similar message: https://en.wikipedia.org/w/index.php?title=TrueCrypt&action=...

By "Truecrypt-end" user: https://en.wikipedia.org/wiki/Special:Contributions/Truecryp...

8 hours ago on the IndieGoGo TrueCrypt Audit page [1]

> p.s. We hope to have some big announcements this week, so stay tuned.

[1] https://www.indiegogo.com/projects/the-truecrypt-audit#activ...

Although Kenn White, who wrote that message, has no idea what's going on [1]

> .@FiloSottile @matthew_d_green no idea. It's doing a 301 perm to a static pg @ SF, now blocked. Possibly compromised. pic.twitter.com/g5tSFUuXzu

[1] https://twitter.com/kennwhite/status/471740840478797824

He's responded specifically about the message:

  .@Costly no idea. The announcement was about a
  new Open Crypto Audit Project initiative, not TC.

i just wanted to say thanks to the truecrypt devs for a decade of largely unthanked and criticised work that, as far as i can tell, has been impressively reliable.

[kinda disappointed that, despite arriving so late to this thread, no-one seems to have said this.]

Interestingly, an Infoworld review of the recent TrueCrypt audit [1] says: "One major issue was how compiling TrueCrypt from source required the use of an older Windows build environment that's noticeably out of date [...] using a shockingly old version of Microsoft Visual C++ released in 1993."

Align this with what the TC website says now: "development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP."

Could it be that the original developer is somehow unable to update the build process to work on newer OSes, or unwilling to do so? Maybe they don't trust any VC++ released after 1993, and that version is probably not going to work on Windows 7 or 8.

[1] http://www.infoworld.com/t/encryption/sloppy-secure-open-sou...

I would be absolutely shocked if there was some reason any VC++ lib would not install on any modern Windows OS.

Microsoft has many faults, but backwards compatibility is not one of them.

I doubt this would be the reason. (Also, TrueCrypt runs on OSX and Linux too, so a build environment dependent on Windows-only seems odd).

The version of MSVC needed is 1.52c, which was 16-bit, and was the last version able to create 16-bit binaries. It was likely needed for building the bootloader. (Why this couldn't be moved over to a FOSS compiler, I don't know.)

VC++ 1.52 is required to build the boot loader. You can still download it from MSDN. I can see why they would have an "if it ain't broke, don't fix it" attitude there.

But, being a 16-bit program, it won't run on 64-bit windows. I'm not even sure it would install properly on anything newer than XP. I haven't tried installing it since the 9x days.

There are several things MS has released that don't install on newer systems very well. There are some where the installer depends on an old version of Internet Explorer being installed and which fail miserably on newer versions.

Its a boot loader, It runs while the system is in real mode (16bit), before windows itself has booted.

The compiler is 16-bit [1]. It won't run on 64-bit Windows.

So if you have a Windows-based build server, it's probably running Windows Server 2008 or later. Which is 64-bit only.

You can run it on a recent 32-bit version of Windows, but client editions only.

And in the next year or two I imagine Windows 9 or 10 going exclusively x64/ARM.

[1] http://en.wikipedia.org/wiki/Visual_C%2B%2B

I meant MSVC 1.52c is 16-bit.

I build my own TrueCrypt binaries on my 64bit Windows 7 box.

Yesterday my Windows XP virtual machine killed itself after a Software Update related to Malware Protection Center.

I will try to reinstall it today, and have VS 2008 running inside.

Nothing kept them from having an XP (VM) offline just for compilation. It was best practice for security related products (actually for any development) to develop and compile offline anyway.

> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

I see many readers here and on Twitter who interpret that as "TrueCrypt has security issues". That's not what it says. It says that it might be insecure. That does not make too much sense right now, but considering this webpage would be meant to stay up, unchanged, for years, that makes a lot more sense: security problems may be found, and will not have been fixed in the version on the page.

So, it's a deprecation warning, not a security issue warning.

For security software, deprecation is effectively a security issue since there are no plans for fixing future bugs.

At the bottom of this page it says "WARNING: Using TrueCrypt is not secure"

Looks like they've taken out the ambiguity.


The first time around you curled "www.trucrypt.org" (note the missing "e") and it went to a domain parking service (findingresult.com).

The second time you went to the real "www.truecrypt.org", which is the real domain that now redirects to SF.

Are you sure about the domain www.trucrypt.org ? there's a typo there, no?

Well - this comes as a pretty big surprise.

Is this real? Is there a known vulnerability that catalyzed this? Money from Microsoft? Threats?

I'm not buying into conspiracy theories, but it does seem pretty out of place.

The binaries are properly GPG-signed with the same key as the previous binaries, check for yourself. [They] either compromised their private key too or the actual developer(s) did this. Be it voluntarily or by force of secret three-character agencies / a massive pay check.

Maybe something like the Lavabit scenario where they rather close the shop than sell their users out. On the other hand, proposing Bitlocker as an alternative would be rather suspect in that case.

IF THIS IS THE CASE and that's an IF then it seriously brings into suspect backdoors in larger proprietary software. Because really if they're going after trucrypt then they have to already have gone after the big players.

I'm not going to jump the gun just yet but after snowden it's not out of the question.

Not "backdoors" but it seems Microsoft stores the BitLocker decryption key, based on this leaked slide (just found on twitter): https://twitter.com/TheBlogPirate/status/471759810644283392/...

edit: Confirmed Microsoft stores your recovery key on their servers if you're not connected to a domain: http://windows.microsoft.com/en-AU/windows-8/bitlocker-recov...

Microsoft storing your key is opt-in and optional.

Whether or not they superstitiously store it anyway is a different question.

Well, the thing is though, it's not that they were hosting users' data. It's not like they would be forced to provide the contents of users' communication.

I suppose they could be approached by someone to plant backdoor into the software, but I wonder if that can be done without someone noticing it...

If they put a backdor on the binaries, but not source, lots of people will be compromissed, and for a really long time nobody may notice.

EDIT: I normaly don't care. But this time I'd be glad if who downmoded this post explained why.

Yeah it could be a gag order from a secret court. maybe they folded because they were forced to compromise the code...

considering heartbleed... yes

Same key as the previous binaries? I doubt it, given that the keys were replaced mere 3 hours before the new binaries were published:


Anyone have key fingerprints for pub keys used for the 7.1a vs 7.2 signing? Preferably pub key from a while ago I guess.

This looks like the previous key: https://github.com/DrWhax/truecrypt-archive/blob/master/True...

Besides the different file name, the contents of the files match: http://www.diffchecker.com/szpb500v

Yes, I can confirm that F0D6B1E0 was on the Truecrypt web site about a year or two ago, since it's been on my keyring for at least that long. I've installed Truecrypt multiple times over the past few years, and have always used this key to verify (or its signing subkey, I suppose).

There's a "TrueCrypt Foundation" key on the keyservers from 2004, the ID is E3BA73CAF0D6B1E0.

The time stamp on key servers can not be trusted. Anyone can spoof keys in anyone elses name, with any timestamp they want.

The only way to verify is if you have the previous key stored somewhere, or can find a trustpath to it.

I have the key stored in my local keychain:

E3BA73CAF0D6B1E0 C5F4 BAC4 A7B2 2DB8 B8F8 5538 E3BA 73CA F0D6 B1E0

Checks out.

I have 7.1a binaries, source, sigs and pub key from September 2013.

  pub   1024D/F0D6B1E0 2004-06-06
        Key fingerprint = C5F4 BAC4 A7B2 2DB8 B8F8  5538 E3BA 73CA F0D6 B1E0
  uid                  TrueCrypt Foundation <contact@truecrypt.org>
  sub   4077g/6B136ECF 2004-06-06
My version from September is identical to the pub key at http://sourceforge.net/projects/truecrypt/files/TrueCrypt/Ot... .

Could you post the SHA1s of those? I'm failing to use GPG properly.

  tc/linux$ sha1sum *
  c2a8c78a23f97ffb17bf47448c9f2daa3c8f80cd  truecrypt-7.1a-linux-console-x64.tar.gz
  078cdd4a58f0342cb872d7456c0ba49e310fcad9  truecrypt-7.1a-linux-console-x64.tar.gz.sig
  a53a7a609a25d9a1e33f720ce5c0265ddd4e8b25  truecrypt-7.1a-linux-console-x86.tar.gz
  66060f9444d5df70b4fcdeb655dc60131fce5ad1  truecrypt-7.1a-linux-console-x86.tar.gz.sig
  086cf24fad36c2c99a6ac32774833c74091acc4d  truecrypt-7.1a-linux-x64.tar.gz
  45f65bf755d9481d8afa0d17de6a034062b7a7bd  truecrypt-7.1a-linux-x64.tar.gz.sig
  0e77b220dbbc6f14101f3f913966f2c818b0f588  truecrypt-7.1a-linux-x86.tar.gz
  9efcd79e963126d6d8ef242857b4fafb06eb8ff0  truecrypt-7.1a-linux-x86.tar.gz.sig
  d43e0dbe05c04e316447d87413c4f74c68f5de24  TrueCrypt 7.1a Source.tar.gz
  caeb2bb1d5605d1fc960e936a06e52611033788c  TrueCrypt 7.1a Source.tar.gz.sig
  c871f833d6c115f4b4861eed859ff512e994b9fc  TrueCrypt-Foundation-Public-Key.asc

  tc/windows$ sha1sum *
  06961d83e39c7248df09c132cb6e9b9f528ce69a  Configuration.xml
  88b323b416290924621901a10da3f4f7482e3f77  License.txt
  4c4891f5eafcf9b96be01e31031992d9e98d39c3  TrueCrypt.exe
  34442e400e6cb2534f33a0b1599defe36eefef2a  TrueCrypt Format.exe
  7689d038c76bd1df695d295c026961e50e4a62ea  TrueCrypt Setup 7.1a.exe
  e1e3efaeac2fbcdbff0c2c62ac33233bd356edfa  TrueCrypt Setup 7.1a.exe.sig
  62fc4f76540740e63c7f0a33e3a1b66411f0a303  truecrypt.sys
  17249d979b3bc52d0a33821cc7f810337ddea2b6  TrueCrypt User Guide.pdf
  17c46ebc6f4977afbcf4aa11eccee524fd95b1c8  truecrypt-x64.sys

Can you please make these available for download, the Linux ones at least?

All of the files available here: http://truecrypt.ch/ have the same hashes as provided by this person.

Don't just trust my SHA1s, verify with the sigs and the TrueCrypt Foundation public key. Ensure the key has the fingerprint shown in the great-great-great grandparent of this comment, independently verified by others in this thread.

  gpg --import TrueCrypt-Foundation-Public-Key.asc
  gpg --fingerprint F0D6B1E0
  gpg --verify truecrypt-7.1a-linux-x64.tar.gz.sig
You should see:

  gpg: Signature made Tue 07 Feb 2012 12:45:26 PM PST using DSA key ID F0D6B1E0
  gpg: Good signature from "TrueCrypt Foundation <contact@truecrypt.org>"
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: C5F4 BAC4 A7B2 2DB8 B8F8  5538 E3BA 73CA F0D6 B1E0


Time to call in the underhanded C contest (http://underhanded.xcott.com/) participants on a special bugfinding challenge :)

Not needed.

Just quickly scroll through the diff (better version here: https://gist.github.com/anonymous/e5791d5703325b9cf6d1) and you will immediately see that all that was done is disable/remove a majority of the functionality.

    AbortProcess ("INSECURE_APP");
    Print ("WARNING: Using TrueCrypt is not secure");
They added exceptions/rose errors/printed warnings everywhere where you could possibly encrypt and all of it reflects their intent at the Sourceforge page.

The whole point of the underhanded c contest is that the code looks extremely benign, and you wouldn't know that it's doing something evil by staring at it for a short time. Example: http://underhanded.xcott.com/?page_id=22

Anyway, it was a joke.

edit: But I'm not touching that binary with a 10 foot pole, thank you. There isn't even any guarantee yet that that source compiles into the given binary.

If this is a hack, then the truecrypt.org site (or dns) and sourceforge site are both compromised, suggesting a dev got hacked who would have had access to both, and perhaps the TC signing key as well (not everyone practices good signing key hygiene, like keeping it offline, even for important software projects).

Even if it's a legit announcement, I wouldn't run that 7.2 binary. Anyone running truecrypt already has truecrypt, right? I don't know why they'd release a new version at the same time as such a dire and panic-inducing announcement.

SourceForge recently forced their users to change their passwords [1] because of an attack on their infrastructure [2]. Pure speculation but I'm not sure if that had anything to do with this?

[1] http://sourceforge.net/blog/sourceforge-net-global-password-...

[2] http://sourceforge.net/blog/sourceforge-net-attack/

Those two SourceForge blog posts are from January 2011, a year before the release of TrueCrypt 7.1a. The recent forced change was due to infrastructure changes.


> Anyone running truecrypt already has truecrypt, right?

I frequently reformat my boot volumes—but I've had a .tc file laying around on an external HD since forever, with my websites' X.509 private keys and such inside.

I'm probably going to do exactly as this announcement says: download the export-only binary, create a loop-mounted LUKS volume, and migrate everything over.

Recent versions of cryptsetup support decrypting truecrypt volumes, just use cryptsetup for both.

A much simpler explanation is someone defaced the site around the same time a new release was coming out. Is there anything in the signed release package to corroborate what the site says?

Yes. See the sibling poster's image link. I also installed 7.2 in a VM and received the same warning. It also looks like I can't encrypt anything, just decrypt.

If their site/dns/whatever was compromised than there's no way you can trust the GPG signature at this point. I'll await a proper press release.

Matthew Green (@matthew_d_green) was involved in the audit. Follow him for what's what.

> The audit did not find anything -- or rather, nothing that we haven't already published.


Call me paranoid but this just looks like really good evidence that Truecrypt was secure.

...or that BitLocker isn't.

I know everyone likes to bash MS around here but is there any actual proof of Bitlocker's insecurity that is more recent than 2008? If you look at wikipedia it seems like the only known real vulnerability requires someone with physical access to boot via USB into another OS within a few minutes of turning the computer off. When is this a real risk for anyone? I am not a security expert but unless you are doing things shady enough to get raided by the FBI, it seems like Bitlocker is pretty secure. The same problem occurs in other encryption programs on Linux and OSX. Also, it may not be open source like what we want, but MS lets its partners and enterprise customers audit the code subject to an NDA.


It's really not that hard to imagine scenarios where this might happen. Simply leaving your notebook unattended after a shutdown might leave you compromised. Besides, government agencies in other countries might have a slightly different view on what constitutes "shady behaviour" (think regime critics).

Don't forget that M$ gives you the great 'service' to store your BL-key in your M$-account (on their servers) as soon as a) your machine is not connected to a domain and b) you're [...] enough (most are!) to log on with an M$-account to Win8.x.

Put it this way. There's no proof that BitLocker is any more effective than rot13.

It's not open source so who knows what's lurking in there? It's not like anyone has been able to audit the source of Bitlocker.

...and that BitLocker isn't.

Best advice is for everyone to sit tight and not do anything for at least 24 hours. You'll be saving yourself a world of heartburn.

According to this http://dnshistory.org/dns-records/truecrypt.org the A record for www.truecrypt.org hasn't changed (still resolves to So not a DNS hijack.

This doesn't pass the smell test. Either there was some underlying political reason for this migration or someone hijacked the DNS.

Anyone know who the main committers/project leads are so we could reach out for comment/clarification?

Well, if red Times New Roman on a Sourceforge page says so...

http://truecrypt.org/ redirects there, too.

Tom has a point, though. The nature of the message (abandoning truecrypt rather than fixing it simply because XP is end-of-lifed?) and the unwillingness to fix it rather than post a dire message about its insecurity and recommend migrating to other solutions that don't have hidden volume functionality -- it suggests it's either very poorly handled, or a fake message.

It might be more likely that a dev got hacked, compromising the signing key, sourceforge project, and truecrypt.org site.

We don't know much about the TC developers, do we? It's also possible that they're just really cavalier about this stuff, and that this is their response to the TC audit process ("stop bothering us about it and use something that's maintained").

True. Security announcements have been botched in the past, for all sorts of reasons, not that you have any experience with that, of course. But what does XP being EOL'd have to do with anything? That and the blithe recommendation to use other solutions, even though they don't have hidden volume functionality which is a main selling point of TC, is what changed my mind, from thinking this is probably a legit mishandled disclosure, to thinking it's probably fake.

On the other hand, as pointed out in other subthreads, if the devs are tired of maintaining it, this could be a legit, unappreciated-developer version of a temper tantrum. Nobody seems to know (yet).

> But what does XP being EOL'd have to do with anything?

Every version of Windows after XP has a native disk encryption utility. TrueCrypt was built to bring full disk encryption to Windows, which didn't exist at the time - this is the developers way of saying "you don't need us anymore, Windows now does what we did"

Not every version... In case of Vista and 7 only Enterprise and Ultimate editions have it and in case of 8/8.1 you need to have Pro or Enterprise edition.

True, but if you need disk encryption you probably use one of those already.

I mean, a normal use case is a corporate laptop used when traveling or similar. Normal home users certainly have no need of it, for them it's just something else that can go wrong and destroy all their data.

FDE was available from different vendors (I bought DriveCrypt PlusPack more than 15 yr ago and tried CompuSec (free) more than 10 yr ago, Comodo FDE is around since ~2k8). So availability of FDE software can hardly be the reason. Neither the credibility of M$, in matters of quality of code as well as especially being an US based company.

Certainly possible, although this from the audit web page doesn't sound like that would be a big problem:

"Wed, Oct 24, 2013: We have made contact with the TrueCrypt development team. They have stated a commitment to a thorough, independent security audit and cryptanalysis of the code."

Since TC developers were unknown for a long time. Perhaps the audit effort, or someone involved with it, intentionally or not, somehow opened some clue that allowed some 3-letters agency go after the developers and they receive those weird proposals like Lavabit ??

Or the NSA was maintaining it the whole time, and they've just sent everyone to the next best thing for them, because of the coming audit.

Perhaps the TC devs were ticked off that this audit kickstarter/indiegogo has netted so much money none of which goes to the devs. And this is their way of not playing along with the whole shenanigan.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact