Two key contributors, Matthew Green (https://twitter.com/matthew_d_green) and Kenn White (https://twitter.com/kennwhite) remain active on Twitter.
I am aware of VeraCrypt and CipherShed but these appear orthogonal to the original audit.
Does anyone know what the heck is going on?
The TC audit project commissioned iSEC to do a formal code audit. That audit was completed professionally and efficiently. No smoking gun problems were found (several nits were, but nothing that would make it any easier to decide whether to trust the package).
That iSEC audit was the headline achievement for the project, so the fact that it was finished should reassure people worrying about whether the project did anything.
After the code audit, the project was supposed to move on to review the cryptography in TC. Which is where I come in.
Because the project was considering commissioning services from professional appsec firms, I recused myself from the project (at the time, I worked for a very large appsec firm). My feeling is that a better use of the TC project resources would be to set up some kind of crowdsourced audit slash bug bounty. When the code audit was completed, and after I had left Matasano, I volunteered to coordinate a crowdsourced crypto audit.
Unfortunately, I was also in the midst of starting a new company and recruiting cofounders and then the holidays hit and long story short things went off the rails.
There are two big paths forward for the TC project that I am aware of:
1. They can rekindle the crowdsourced crypto audit (I'd be happy to remain involved, or to talk to any other subject matter expert that wanted to do that job --- n.b., I was going to do the work gratis). If any kind of formal review of TC's cryptography is to be done, this is the way to do it; the project can't afford what it costs to retain professional cryptography engineers to review the code (real crypto security consulting costs a multiple of what appsec consulting does).
2. They can devote all the remaining funds to a public bug bounty for Truecrypt.
There may be options 3 or 4 that I'm not aware of. I have a decent relationship with Kenn and Matthew, but I have not been trying to keep myself in the loop on the project.
There you go: more than you wanted to know about the TC audit project!
None of it has much of anything to do with that weird announcement from last year.
This is Matt Green, one of the two people running the audit. As tptacek explained, we went down a few blind alleys following the public collapse of the Truecrypt (development) project.
In the last few weeks we've signed a contract to begin a commercial evaluation of the cryptography in Truecrypt. We've also been doing some internal evaluation of portions of the source code. For reasons related to getting the best price, the start date of the audit was allowed to drift forward a bit. This was necessary to make sure that the donated money stretches as far as possible.
Rather than giving all the details in an HN post, I'm going to write an update on my blog (blog.cryptographyengineering.com) but it won't be up until we've notified everyone involved that we're making the details public, probably around 4:30-5pm ET today.
http://blog.cryptographyengineering.com/2015/02/another-upda...
Unless something new has come to light since last I looked, the licensing situation on the TC code is weird:
http://lists.freedesktop.org/archives/distributions/2008-Oct...
... which means there is a pretty strong disincentive for people with serious crypto and systems expertise to invest their time and energy building on it. You don't want to trust crypto platforms with built-in adverse selection problems.
Maybe they have an email list of the original donors and can propose some multiple choice options:
1 - bug bounty
2 - attempt to hire someone at a steeply reduced rate for the audit
3 - use the money to seed a complete replacement or a clean room rewrite if possible (this is a can of worms but given the license issues seems like the only realistic way forward... might need the help of FSF or ASF or the like)
Also what does HN think about still using TrueCrypt? Any reason not to?
[1]https://ssd.eff.org/en/module/how-encrypt-your-windows-devic...
I take the view that for my own threat model (i.e. someone nabbing my machine) DC, even TC would be perfectly adequate for that first layer of protection. Advice given by tptacek on using PGP individually for sensitive information (if I have understood correctly) could then be coupled to that FDE where required.
For my own purposes this would protect what needs protecting in terms of at-rest data. A vast improvement over the no-encryption situation.
SSDs with hardware encryption seem to be the new frontline defense for mainstream users such as myself. Same issues as with any FDE, I suppose, but coupled with filesystem PGP encryption ought to again offer adequate protection from opportunistic thieves.
I don't know of any other software that provides cross-platform, encrypted, and mountable disk images. We have Bitlocker, Filevault, and Luks, but none of these work (easily, at least) on different platforms.
Cross platform encryption is very important, and you should look for good solutions (most of us who rely on encryption for real operational reasons just hold our noses are use PGP). But full disk encryption has very limited utility. The idea of a USB drive you can plug into any computer that is locked by default is attractive, but you can get better security out of a USB drive that holds nothing but files encrypted at the application layer.
More:
Out of interest: Doesn't the use of error detecting filesystems like ZFS and Btrfs solve the authentication problem? I don't have anything resembling a formal argument, but intuitively having each block checked in a Merkle tree like fashion should inhibit attacks where attackers can only change blocks in a random manner or restore old backups of the blocks. Of course time traveling - i.e. replaying - the file system as whole is still possible, but selectively manipulating the data should not.
Full disk encryption has the advantage of being transparent and not application-specific, so you don't have to teach every random application to do application-level crypto.
Sure, if you have a few specific files you want to encrypt, you could run gpg. You could even teach specific tools to understand gpg, such as text editors that can decrypt to memory, edit, and re-encrypt before writing to disk. But what about a source tree, stored in a git repository, regularly manipulated with git and various command-line utilities, and edited with a variety of editors? How would you store that, securely, other than on a block device encrypted with full-disk encryption?
Would you suggest a file-level encrypting filesystem instead, similar to eCryptFS? Would you suggest integrating encryption into ext4 (currently being worked on) and other filesystems?
I haven't had to do this often, but the times I have had to do it, it's been a lifesaver.
Any advice, apart from keeping better backups so I don't have to do any cross-platform data recovery?
Yes it's not perfect and if you use it and let your devices to go to sleep rather than power off you are vulnerable to various memory access and coldboot attacks.
However with TPM/USB Storage for the keys, with secure boot enabled Bitlocker offers one of the better data encryption capabilities out there.
Yes MSFT might have backdoored it, TPM is an oxymoron and all that might be true. However if the only thing you are worried about is what happens to your data if your device gets lost or stolen you are probably more than fine with using this setup.
If you are worried about the NSA having your files well then probably there isn't much you can do about it if they want them they'll get them. Whether its by backdooring your OS, internet connection, or by sending intelligence support activity assets to your home to tap into it while you sleep :)
TrueCrypt,the binary application is the one that is dead but its on-disk format will probably live on as a cross platform on-disk format as there are other projects out there that are supporting it and more projects will probably follow.
tcplay[1] is one of the projects that have full support for TrueCrypt,the on-disk format.
If you already have a TrueCrypt volume and you dont want to use TrueCrypt,the binary application,then you can search for these alternatives and start using them.
If that's the case, what's the purpose of of the audit?
Thank you, tptacek, for the huge amount of time you're spending answering questions in these threads.
