I was a little surprised to find out this morning that this was already public.
The cryptography audit for Truecrypt is going to be run much differently than the software security audit. We'll have more to say about it next week, but for now: it's something in between a "public bug bounty" and a "summer of code" program. Me, Nate, and several other crypto people will be working not as consultants to the projects, but as "mentors" (I hate that term) leading developers interested in cryptography.
As to why the audit is proceeding: it's obvious, at least to me. Tens of thousands of people will continue to use Truecrypt no matter what we do, and if nobody takes a serious and organized look at its cryptography, the circumstances behind the conclusion of its development will create yet another Internet Crypto Urban Legend.
Since the truecrypt story broke i checked and discovered that I'm using version 6 and it seems to date from 2008.
Will your audit have anything to say about older versions?
There's a lot of potential scope for covering all the crypto that has ever come into contact with Truecrypt; the amount of it we actually cover will depend on the response we get from the community.
What did you make of the bizarre sourceforge page? Did it pass the basic smell-test for you? struck me as very different from how other projects have communicated what the sf page ostensibly communicates, but maybe it's not a signal.
We already know. The developer(s) got tired of supporting the project. The world seen through HN/Reddit's prism believes Linux Truecrypt is an incredibly important project. The Truecrypt developers beg to differ: Windows was what was important to them (and, for that matter, for most non-tech users). Microsoft now provides FDE as part of the OS. They're done.
I'm glad the audit is moving on and I really hope Truecrypt 8 sees the light of the day. Back in October'13 when the funding link was posted, I remember feeling a sigh of relief. Thank you to all those who are contributing to this.
One of the things I see you regularly talk about, and something that bothers me a little, is this idea of crypto "pedigree". That is, folks without crypto backgrounds attempting to write crypto software tend to, in my observation, evoke your ire, and the ire of many others in the field.
Taking that for granted for a moment, would this security audit be for the folks who've already become part of this class of "elites", or is this something one would do in an effort to be taken seriously in the security community by those currently in it?
Give me a break. 12,000 people have signed up for our crypto challenges, in which they write 6-7 batches of 8 crypto exploits each in the language of their choosing --- people have invented new programming languages to do them in, and we've gotten them through all of the challenges --- and, by directly engaging us over email, get both validation of each of their challenge responses and 1:1 support. I am off the charts tired of people acting like my issue with incompetent crypto is a form of "elitism".
The fact that you managed to inject that bogus complaint into this particular story, which, if you'd read the just 142 words I wrote a little carefully, is obviously the exact opposite of what you're "concerned" about, is all the more annoying.
What "draws my ire" is cryptographic incompetence. Cryptographic incompetence gets people hurt. I do not give a shit about how those developers feel.
For whatever it's worth to anyone else reading this: you will rarely ever see me get pissy about an incompetent amateur breaking crypto. Breaking crypto is what you're supposed to do to get good at crypto.
Your last statement is exactly what's always bothered me about your attitude, and how it contradicts directly with the sentence prior.
I'm not going to give you a break so long as you don't give folks who are trying to create things a break. Bad crypto gets people killed, but no crypto does too, and perhaps your elitist attitude (and it's not just you, it's the community at large) is why we have only TrueCrypt and nothing else.
Bad crypto gets more people hurt than no crypto, because it tricks them into revealing secrets to investigators under the pretense that they're safe when they're not.
No part of my attitude impacts how many FDE solutions we have. We don't have lots of FDE systems because, unlike terribly broken Javascript cryptography applications, FDE systems are very difficult to write.
Apropos neither of those last two statements: it's not clear to me that you understand what's actually being announced in this Ars story.
Well, naturally you, possibly part of the problem, would deny the problem exists. We had this discussion before, and this is where we quickly landed.
As for the article, I haven't actually commented on it whatsoever; I was commenting on your announcement. It's interesting to me you wrote that, but whatever.
Is it intended for experienced crypto programmers or new folks who want to learn more? Does that question make sense? You didn't give many details (which is fair).
If you're an experienced crypto designer, we'd like to talk to you about volunteering alongside Nate and I as unpaid advisors.
If you're interested in learning more about cryptography, we'd like to talk to you about working on the audit directly, reporting to an advisor. As I understand it, many of these auditor roles will have stipends associated with them.
If you're aware of an elite cadre of crypto people that might be available to serve in the auditor roles, I'd love to know about it. The overwhelming majority of the people that do our crypto challenges have zero prior crypto experience, and many of those are the same people we hope to see staffing Phase 2 of the audit.
Teaching a bunch of developers some new stuff about cryptography would be a nice knock-on benefit of the audit, but it's important that I be clear that the funding for this audit was earmarked for actually improving the security situation for Truecrypt. So we'll probably be somewhat selective about the audit team. I'll have more to say about this next week. This all got sprung on me very quickly, like I said, because of this week's events.
You might want to think a little deeper about your last statement.
If you don't have access to crypto, you can take other precautions. If you use bad crypto, you can be lulled into a false sense of security. There is nothing more dangerous than thinking you are secure, when in actuality, you aren't.
First, I think that if you cannot think of an alternative to crypto, you should think twice about doing anything that could get you or your friends killed.
Second, I urge you to consider the difference between these two developers:
Developer A is just learning crypto. She makes many mistakes and builds some truly horrible systems. But, she is just learning and she never actually intends for anyone to use her systems.
Developer B thinks she is a crypto god. She releases a tool and claims it is incredibly secure. However, it contains fatal flaws.
If someone bullies developer A, I think that many people would jump to her defense. On the other hand, developer B is a very dangerous person whose hubris has created a dangerous situation.
The developer we really love is Developer C. Developer C has looked at what's happened with A & B, done some reading, and decided they're genuinely interested in cryptography and want to understand what makes it tick.
So, rather than learning exactly enough cryptography to built an application that appears to journalists to be secure but actually isn't, Developer C takes the time to read papers and actually code up crypto attacks.
Man, we love Developer C. Developer C is awesome. Developer C is going to learn so much building crypto attacks. There's a good chance that after doing that for just a couple months, Developer C will discover novel variations of crypto attacks nobody has thought of yet. From that work, everyone (who really cares about crypto) will benefit.
At the end of this process, Developer C will not only be terrifying, but also in a vastly better position to implement sound cryptography than other developers. Ironically, though, the experience of seeing so much broken cryptography is going to make Developer C hesitant to publish random new cryptographic tools the moment they hit their text editor. Like Adam Langley and Trevor Perrin, they will quietly hone their designs for months or even years, making sure they've gotten things right before getting other people to risk their secrets by using them.
Developer C is just getting started now. We love Developer C. We have an avalanche of crypto exercises for them to play with, and, if they know they're interested and engaged, there's a good chance I want to talk to Developer C about helping with the Truecrypt audit this summer.
If only it were so clear, which developers were which. Developer B is what everyone in the industry assumes everyone is, even if they're just developer A.
When you brag on Twitter that Edward Snowden and Glenn Greenwald used your tool to coordinate the largest intelligence leak in the history of the world, I think it's safe to say the jury is in about whether you're Developer A or Developer B.
This is getting off topic, but I have learned something very valuable about the technology industry. If you are developer A, do not be afraid to admit that you are still learning and that you don't know what you don't know. If you approach your own learning process with humility, I can guarantee that you will find many people who are willing to help you.
People run into trouble when they try to pass themselves off as being more qualified than they are.
Just to be clear, are you suggesting that there is an elite cadre of cryptobullies browbeating the general public into broadcasting compromising information all over the cleartext internet?
Nope, I'm suggesting that a negative and hostile attitude, like the one exhibited towards the CryptoCat team by tptacek and others is not healthy to the industry.
In crypto, its justified. Crypto is like flying a plane. You can't do it just because you read lots of books and try really hard. Extra smart people have very little advantage over those of average intelligence. Most importantly, due to the nature of the beast, the first mistake is the last. It doesn't matter if you get everything right for 99.9% of the flight and only make a mistake during 0.1% of it, the result is still a 0% success.
Pilots are also a bunch of elitist snobs. I wouldn't fly with anyone else.
I think what's especially dangerous about it, as a software developer, is that broken crypto runs identically to properly-implemented crypto. If one is in the mentality of rewriting a program until runs without crashing a few times, well, that seems sufficient to land a gig to code printer drivers, but falls short of the rigor I'd hope would go into implementing a secure system.
Nevertheless, at this moment there's a PHP programmer somewhere in the world writing new code that stores passwords hashed with one round of MD5.
Many (most?) TrueCrypt users obtained the software as a prebuilt Windows binary; they did not compile it from source. So even if the source code is clean, maybe the binaries were not. Is there any way to audit this and if so is that being done?
The cryptography audit for Truecrypt is going to be run much differently than the software security audit. We'll have more to say about it next week, but for now: it's something in between a "public bug bounty" and a "summer of code" program. Me, Nate, and several other crypto people will be working not as consultants to the projects, but as "mentors" (I hate that term) leading developers interested in cryptography.
As to why the audit is proceeding: it's obvious, at least to me. Tens of thousands of people will continue to use Truecrypt no matter what we do, and if nobody takes a serious and organized look at its cryptography, the circumstances behind the conclusion of its development will create yet another Internet Crypto Urban Legend.