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.
Unless something new has come to light since last I looked, the licensing situation on the TC code is weird:
... 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)
With the money left, maybe a smart fund-raiser could get some conversations started with bigger donors who could match grants and go in a large round. The money might buy you the time of a Bruce Schneier or Richard Stallman to advise and promote the project in its infancy. And non-profit software orgs are underpaid and work on shoestring budgets already that this is real money to them.
The experts shouldn't write any line of code, use the community as code monkeys, only accepting pull requests and merge them in the project(basically what Linus does this days). Would that not be feasible?
I don't see this as the roadblock. They (the experts) could bill by the hour. The most intensive period is the initial specification/design/architecture. After the burst period they just have to review the commits for security pitfalls and merge them if OK. The community could have some volunteer reviewers for triage.
I have no idea if this actually works and I also didn't heard anything like this done before, so take it with a grain of salt. That's why I asked more knowledgeable people how feasible this could be.