The only solace that I have is that I'm reasonably careful about my sensitive information and I'm well under the radar. I suppose the best thing to do is sit tight and not panic, then follow what reputable experts recommend.
Many have suggested intelligence agencies are behind this. A good conspiracy theory is always fun, but in this case, there may be an entirely prosaic justification.
Some wonder if the coder behind TrueCrypt has taken offense to the security audit his code is currently undergoing, and in response, has spitefully decided to close down the entire project.
The auditors checking the code have regularly criticized the code's quality. They've also said nearly all the code appears to be the work of a single individual.
When closing down the project, the maintainer suggested users adopt a Microsoft product of extremely questionable usefulness. If the project were being shut down to help Truecrypt users, why recommend a solution that most believe to be insecure?
If this is a warrant canary, why recommend the Microsoft product? Closing down would be enough of a signal, more than enough. The source code is out there. If there were a hole, why not quietly point the security auditors towards that hole? If there is no hole, why not license the code under better terms?
The author's refusal to adopt a proper license combined with this extremely odd way of shutting down the project make a strong argument that petulance is driving this, not interference from intelligence agencies.
But has petulance been displayed by the author(s) previously? This announcement seems so out-of-character that it garners suspicion.
Ask yourself who benefits from this development? Who could possibly want TrueCrypt discredited? Who has the power to make that happen?
Venturing into conspiracy-theory-land? Perhaps, but have you been paying attention to NSA actions lately?
Fine. But then why write TrueCrypt in the first place? If the entire project was an exercise in ego, why remain anonymous?
As for the Microsoft recommendation: I'm not going to say that any encryption shipping with the most popular desktop OS is backdoored by the NSA, I'd just be surprised if it wasn't. I am not a TrueCrypt user, but I suspect other TrueCrypt users would laugh outright at such a recommendation. Therefore the recommendation serves two theoretical tinfoil-hat purposes: It complies with the letter of (supposed) government pressure, while simultaneously communicating (to the properly paranoid) to do the exact opposite of what is stated (i.e., don't use Bitlocker).
Ego gratification isn't necessarily public: plenty of people will get a kick from privately doing something cool and challenging.
Just what I was thinking. After the Lavabit case (and who knows how many others?), it's hard to believe that Truecrypt hadn't come under pressure from $GOVTDEPT to build a backdoor: $GOVTDEPT wouldn't be doing its job otherwise. And if you were Truecrypt's builder in that situation, what would you be most likely to do? Kill the project rather than compromise it, and recommend an alternative which $GOVTDEPT couldn't object to, but which the security-conscious would understandably be wary of.
Brian Krebs think that the warning page may be legitimate.
I'm not convinced yet.
However, a commenter on Krebs's site suggested DiskCryptor, which is GPL'ed, and supposed to be TC compatible. Time to do some extensive research and reading...
Edited to add: I'm beginning to wonder whether the TrueCrypt gang go a visit from a three-lettered agency, à la Levinson...
My Linux laptop for travel has whole-disk encryption - easy enough to do in Ubuntu and Fedora. If you are so concerned about security that you need the disk encryption, while also needing to move physical data around, that's the only real option.
Although, I can see some enterprising kernel hacker taking the shadow volume concept and building it into a filesystem somehow...
I'm agreeing with the prevailing theory that this is a variation on the Lavabit scenario: the Truecrypt team is shutting it all down, rather than be compromised.
My guess is that they had something of a contingency plan for this situation, and they worked out the code for the final version of Truecrypt, but didn't finish preparing supporting documentation. So there are fairly complete details on migrating from Truecrypt to Bitlocker on Windows, incomplete details on migrating to an OS X solution, and a few notes on Linux that amount to, "just install whatever you can find".
I think it's a fairly reasonable theory that the bizarre message -- along with recommending alternatives that don't make sense (for Linux he just says "search for any package with the word 'encryption' in it") -- is designed to comply with the letter of a NSL while strongly setting off warning bells to anyone with any sense.
I don't think that suspecting he was visited by Feds is tinfoil-hatish in any way, in our current environment. We know full well that many tech giants have been made to put backdoors in their products, and that security products like Lavabit have been pressured into revealing their keys.
And someone as into security as the TC dev is exactly the kind of person who might put a bizarre dead-man's switch in place.
This of course is the answer; those of us who have been using TrueCrypt know that it works and it work well; it DOES do the job it was designed for, and does it beautifully! It helps keep our stuff private! And THAT is what our 'overlords' truly hate: that it works! What's better for them than to make people question it's usability. Kind of a 'reverse' selling point!
If THEY hate it, YOU'RE gonna love it!
Ok, so a Mac alternative would be appreciated.
The author(s) are extremely secretive and have been shown to be rather cantankerous in the past on the rare occasions that they do make statements.
Truecrypt has also been largely unmaintained for a couple of years now.
My guess is that whomever was maintaining it got tired of the project, and then got a notice from someone that they found a vulnerability and basically just said "fuck it".
Why is the license a problem? If the developer(s) is/are anonymous then how would they stop someone from releasing a fork? They'd have to come out in to the open, and find a way of proving ownership.
Secondly, since when has legality ever stopped hackers? Just release anonymously, problem solved.
For those on Linux,
crytpsetup should be available in just about any distribution, and while setup is a little complicated the first time, it works pretty well.
It doesn't support multiple volumes with different keys, but some level of plausible deniability is had from the fact that the filesystem to be encrypted in created in a regular file, so if just appears to be a large file of random bits -- with the appropriate name it could, for example, be asserted to just be some kind of binary data cache.
Creating the Volume
- Create a disk file of the appropriate size. To create a 10 MB file
system, for example:
dd if=/dev/zero of=/path/to/file bs=1M count=10
- Create the loopback and assign a password
losetup /dev/loop0 /path/to/file
cryptsetup -c aes -y create container /dev/loop0
(You will be prompted for a password/phrase at the second command.)
- Create the filesystem, i.e.:
mke2fs -j /dev/mapper/container
Using the Volume
losetup /dev/loop0 /path/to/file
cryptsetup -c aes -y create container /dev/loop0
mount /dev/mapper/container /mount/point
cryptsetup remove container
losetup -d /dev/loop0
This. They can't really show they weren't forced to fork over the signing keys (or lost control of them), and that's really the only thing that established that they were the authors. Without that, how do they enforce the license? How do we know they're the authors and have standing? Of course, IANAL, and IDKTROLMTMA (I don't know that rule of law means that much anymore).
I work in this area.
I think Marktech has it. To the best of my knowledge, the TC site never had a 'Warrant Canary'. If they've been hit by an NSL, they can be compelled not to say that has happened, but can't be compelled to lie.
Saying that the program "may" have "unfixed security bugs" is a true statement - it's true of any non-trivial program. Changing stance from 'these are not thought to be serious, and we will fix them' to 'these are utterly fatal, stop using the program', is a change in opinion, not a lie. Ditto posting an 'update' to the program.
As others have noted, the recommendations for replacements are ludicrous. The suggestion for OS X proposes setting up an encrypted virtual disk with an "Encryption Method" of 'None'. To anyone skilled in the art, these instructions stand out like a sore thumb; not factually wrong, but so odd as to call attention to themselves.
The longer we go without new communications from the devs, the more likely this scenario appears.
Can any actual lawyers weigh in on this, exactly what could the developer(s) of TC do if someone did decide to fork it? What jurisdictions would that apply to?
who would say what plausible deniability they have? then it wouldn't be plausible...i'm on to you cory...
The only solace that I have is that I'm reasonably careful about my sensitive information and I'm well under the radar.