- 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... ).
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).
> 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.
[...] 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.
The development of TrueCrypt was ended in 5/2014 after
Microsoft terminated support of Windows XP.
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.
That's an interesting thought, although I don't think there's any way to verify that it's actually gone 'wrong', is there?
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.
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).
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.
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.
The important point is that the developers (?) are advocating that users stop using their product.
Forest through the trees, if you will.
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! ;-)
Incorrect, all the guy did was compare diffs of the source. He did not compile the source to make sure the binaries matched.
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...