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".

http://en.wikipedia.org/wiki/TrueCrypt#Planned_features

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?