Hacker News new | comments | show | ask | jobs | submit login

It's in a weird logistical state. I'll take a healthy chunk of the blame.

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.




Thanks Thomas.

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.



Please do go ahead and post a link to HN when you do.


Also: speaking in no "official" capacity whatsoever, I'd advise you to stay away from the forks of Truecrypt.

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.


Wow those are serious concerns, thank you for linking that.

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)


There is pretty much zero chance that the TC audit project is going to sponsor a rewrite of Truecrypt. That's a project that would cost much more than the TC project has to spend.


It just seems futile to spend the money on TC. I get the number of users of it is huge and the money was donated for this specific purpose. Users of TC should already be looking to move away from it whether there's a vulnerability or not. Even if a vulnerability is found, how is it legally patched? Is it almost better not to know?

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 money was contributed for a specific purpose, and Matthew and Kenn are scrupulous about ensuring that it gets used for that purpose. They actually can't take the money and use it as a seed for a different project. It isn't a slush fund.


If only the design/architecture would be contracted to experts and the actual implementation be written by the community how expensive would that be?

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 think this would work. The details of how block-level crypto work are intimately connected to a bunch of fiddley systems programming details like bootup, power saving, and memory management. It's not nearly enough just to propose a workable design for how to make a virtual hardware-encrypted disk with XTS; you need to evaluate a lot of raw code, too.


@ghostly_s

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.


So you're proposing keeping elite crypto expert(s) on the payroll for--what, years?--as they patiently wait for the community to build something that meets their standards? I'm not going to say such a person or people don't exist, but Linus is a rare sort; considering the market value of crypto experts' talents I think chances of finding someone willing to serve in such a role are rather slim.


Can we still safely use TC 7.1a?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: