It is also important to always remember that a crypto app isn't like other apps. If the protesters in Turkey rely on shoddy crypto today, it might cost them their lives a few months from now. I sincerely hope it doesn't come to that but it is a realistic example.
Always be sure of what you are doing, rely on external review and never, I repeat, _never_ overstate the security of your crypto system.
This point cannot be emphasized enough. In the extreme case, which Cryptocat marketing materials have employed, secure communications software is life safety critical on a level similar to medical or aviation software. As such, the admit-your-mistakes-and-fix-them-later model of development isn't agile, open, or any of those buzzwords. It's a way to get people killed.
Cryptocat has always provided ample warnings that no software can ever be trusted with your life. These warnings appear every time you launch Cryptocat, on the website and in various guides and blog posts.
And I agree, that's a bare minimum warning for all such software. I appreciate your efforts to make strong crypto more accessible to the general public.
That being said, you and I both know that people are using Cryptocat in dangerous situations. And having worked on both medical imaging and secure messaging systems, I have a healthy respect for the consequences of implementation failure. As such, I feel that your disregard for these consequences in broadly releasing such broken software would displease any professional review board, and I frankly doubt you'd ever attain such a license given such a history of poor professional judgment.
In short, I take my profession damn seriously, and jokers like you are why nobody trusts software.
It's important to note that this audit was commissioned to evaluate a prototype build before release. It was expected to find bugs, and all bugs were fixed before release. I believe I take my job very seriously when I commission such audits on a bi-annual basis and transparently discuss the results. Independent individuals who find bugs (such as "Decryptocat") are also listened to and rewarded for their effort. I believe that I and my team have been competent, honest and hard-working. If all encryption projects were as transparent as us, you would realize that this kind of issues happens everywhere.
Please make sure to read our blog post and Github discussions to see the kind of open discussion we're hoping to lead so that our software can benefit.
That being said, I suppose comments like yours are why I've been having recurring suicidal thoughts for the past two years. I don't know what else to say at this point.
I read the blog post reacting to this batch of audit results quite carefully, in point of fact. In general, when I read vendor responses to such devastating findings, I'm looking for a concrete plan to improve the threat modeling and development practices deficiencies which are inevitably the root cause of the class of issues uncovered by the iSec and Least Authority audits. Without such changes, saying that you're going to keep getting audited is precisely equivalent to saying that you're going to to keep writing security bugs and hope someone finds them before the actual red team owns you.
While I agree that the degree of openness your team has maintained is highly desirable, repeatedly shipping bugs which adherence to industry best practices such as "don't use fixed IVs" or "always use constant-time compares" would have avoided makes it difficult to believe that your team possesses the competence you claim as well as undermining the credibility of your communication about such issues. Thus my failure to be impressed by a post which only proposes band-aids and completely fails to apologize for the lapses in judgment which led to this state of affairs.
I don't take using this level of harshness in a public forum lightly, and I'm truly sorry to contribute to your unhappiness as a result. Please do talk to somebody, even if it's not a professional, I've found it always helps.
I disagree; I don't think your summary is accurate. This is an audit of a pre-release prototype. All the bugs were fixed before release, and our blog post at https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp... does not discuss mere band-aids. It discusses, at length, real solutions to complex problems that many encryption apps face. It resolves pitfalls that even companies like Apple commit on a much wider scale and on a much more dangerous level.
For example. We didn't simply "re-use fixed IVs". We know not to do that. The resulting bug was the series of a much more complicated and hard to spot issue with the re-keying mechanism. Understand you might not have the full picture here.
Simply put, I refuse the assertion that Cryptocat's team has not dealt with its software development in a competent, professional, responsible and honest fashion.
I want to discuss this further with you. I want to convince you of my point of view. Please email me at nadim@nadim.cc so I can have the opportunity to discuss with you and hopefully convince that your perspective isn't exactly right on this.
I made no criticisms of how you responded to individual issues raised by the audit, and in fact it's encouraging to see many of the long-standing contact authorization issues finally being addressed as well as what I would generally consider an acceptable approach to handling individual security issues. But I don't think either of these points addresses my concerns regarding security conscious development practices.
I appreciate your willingness to continue this discussion, dropped you an email.
You keep saying "I commission the audits". Isn't OTF the one paying for these audits? Are you taking OTF grant money? If so, aren't you required to have the audits done?
I have, and I still believe he's being extremist. No one is in this space unscathed. For no other product have I seen the same level of vitriol and hate being spit at Cryptocat, despite it being absolutely not the only entrant.
That's both not true, and misleading; even comparing it to applications that have had serious published flaws, this one has vulnerabilities of a number and magnitude that distinguish it.
Always be sure of what you are doing, rely on external review and never, I repeat, _never_ overstate the security of your crypto system.