It appears that the truecrypt project is officially dead. At approximately 1800hrs the Truecrypt project’s sourceforge project page was updated, with the status being set to ‘inactive’ and new binaries posted – ostensibly of ‘Truecrypt v7.2′. The main page featured the warning that “Truecrypt is not secure as it may contain unfixed security issues.’ The signing keys used match those used previously. Krebs notes that there have been no changes to delegation, etc.
Their rationale that Truecrypt development was ended as a result of Windows XP becoming end-of-support seems curious as there appears no relationship between the two. Their advice to to abandon Truecrypt for propreitary solutions like Microsoft’s (almost certainly backdoored) BitLocker also seems odd.
Users on Schneier’s blog have been discussing the various possibilities with the most plausible mentioned being that the Truecrypt team were compelled via NSL or other government instrument to co-operate and that burning down the project was potentially the thing that they could have done. This is possibly why they were unable to give a legitimate explanation, instead citing the ludicrous one regarding Windows XP support. Another possibility is that Matthew Green et. al.’s TrueCrypt audit had spooked the authors in some way.
Just twelve hours ago I believed that this was a website compromise, but I am now convinced these actions were initiated by a member of the TC team and not by a malicious attacker. It is indeed possible that one of the developers has gone rogue, but I believe that it is almost a certainty at this point that TC – as we have known it, at least – is dead. Given the licensing issues (TC’s license is not completely FOSS friendly) it remains far from certain that anyone will fork the source from 7.1a and continue to develop the software.
This marks the death of the second free(ish) Windows full disk encryption suite with the first being FreeOTFE. The important thing to note is that Truecrypt had several very large stumbling blocks in the way of its acceptance by the community – some of them technical, some of them legal and license related, and the vast majority of them social. The shadowy Truecrypt Foundation and the way the organization attempted to shield themselves from any scrutiny made many understandably cautious of the software. Only several months ago on this very blog I detailed the myriad issues I have with Truecrypt and advised readers not to trust the product and to instead seek alternatives. That said, there are no free and trustworthy full disk encryption products for Windows (and obviously, Windows itself – and the underlying Wintel architecture – has some major trust issues of its own).
Mike the Crypto Goat 
TrueCrypt was bleeding skill and knowledge, they no longer have the capability to keep up with new features, and in fact some of the “quality issues” highlighted in the audit also indicate they have run up against design limitations / code quality limitations / knowledge that enables them to squeeze in what they need to the boot loader. That explains why they cannot add Guid Partition Table Support.
http://it.slashdot.org/comments.pl?sid=5212985&cid=47115785
”
They probably just decided to end the project. My experience is that it has been slowly dieing for a long time. I have been heavily involved with truecrpyt and its source code for many years. I make programs to custom edit the boot screen and otherwise customise TC’s appearance. My programs are not forks, rather they edit the actual binary code installed, so that users can easily use it on existing installations. What you have to understand is that truecrypt has added very little functionality for a very long time. In particular they seem to have lost the key developers who did the code in the boot sectors. For those who don’t know, along time ago the program was to big to fit into the boot sectors, and a special deflate algorithm was added to decompression the boot sector code. My code to unzip the boot program and edit its string display strings is still the same code from tc 5.0, and it still works on the latest edition. The guys who code this section appear to be long gone from the project, hence absolutely nothing done over UEFI. The changes that have occured look questionable, in that the people making them seem to have very limited assembly understanding and were hacking on bits instead of properly modifing the programs flow. Secondly getting TC to work with operating systems is extremely complicated, especially for windows. It was micorosoft who eventually released the API’s that were used to make truecrypt properly handle sleep/hibernate. These API’s are not forthcoming to Win8 or beyond, and in all honesty – windows is the only market that matters. I am going to guess that one of the last known developers knows there is a bug that they can not longer believe they have the experience or skill to fix properly, and hence has decided to shut it down.
”
TrueCrypt died two years ago it looks like, they just didn’t have the courage to announce it then and came up with this rubbish excuse to save face.
It’s true, they won’t re-license, they don’t want a fork they consider it harmful, they no longer have the capability to maintain and develop TrueCrypt.
They said offically it’s over.
http://truecrypt.ch/
TrueCrypt revival project.
I guess the cause of the closure isn’t relevant – what’s important is that people don’t act rashly and decrypt their drives thinking that they are no longer secure. I am not a fan of TC and have my doubts about a lot of what has been said but those users who have got encrypted containers or entire drives should just take a deep breath and consider their next move.
Personally I think the decision to refuse relicensing is a good one. TC was tainted with both non-free code and allegedly stolen code from E4M. Forking from this wouldn’t be such a great idea. In fact, even using the TC code as a reference isn’t such a great move as the code is terse, poorly documented and certainly doesn’t do things in a standard manner.
What we need is a “new” TC alternative that brings LUKS compatible volumes to Windows systems. This shouldn’t be too hard to do with a virtual storage driver, some kind of loader to get the credentials on boot and a simple GUI to maintain things. UEFI doesn’t necessarily make things much harder – rather than fighting it, perhaps they can just use it to their advantage. The hackintosh people have several good (and open source) UEFI based shim loaders that can be used as a reference.
Only the “legal or beneficial” owner of a copyrighted work can sue over infringement, at least in the US. Given an anonymous development team that doesn’t seem to want to out themselves, I’m not sure who would have standing to oppose anybody who DID fork, maintain, edit or distribute the code.
So I don’t think the codebase is necessarily dead. Although much like OpenSSL it’s not exactly a great basis to start from, but I see no reason a team couldn’t tear it apart and clean it up akin to the LibreSSL project.
I’d agree with you Brian. They’d be compromising their identities anyway if they were to sue (that said, at least some of the developers have surfaced – i.e. Barnhart around the time that Green started the “istruecryptauditedyet” project).
As we’ve seen the codebase isn’t completely dead in the water – we’ve got ciphershed and truecrypt.ch.