Hi, read the blog post. According to both the blog post and ISEC, you had a pathetically easy man-in-the-middle attack against all of your code, including deployed code in real world use, not just the "buggy" IOS client. Care to explain how that can be taken "out of context?" Even if the rest of the audit was a complete lie, that would still be "brutal."

From the ISEC REPORT:

"CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notification. An attacker performing a man-in-the-middle attack against the client's XMPP or HTTPS stream can inject their own OTR key in the discussion after a user has authenticated their peer's OTR fingerprint. This permits the attacker to decrypt all messages that follow, and no user would have reason to suspect the compromise. Group multi-party discussions do not seem to suffer from the same vulnerability." (emphasis mine)

Your response in the blog:

"... This is a problem that can be exploited in some real-world scenarios and needs to be addressed with appropriate authentication warnings. Thanks to these audits, this issue was caught in Cryptocat for iPhone before it was released. Therefore, unlike the desktop version, Cryptocat for iPhone was never affected by this issue."

You're doing crypto in the browser, while claiming on your home page:

> Everything is encrypted before it leaves your computer. Even the Cryptocat network itself can't read your messages.

You're seriously misleading users regarding the security of crypto -- the web is an environment that has ZERO controls on code updates. Given this remarkably self-serving and ill-conceived stance, it's difficult to imagine how your crypto could ever be considered trustworthy.

Web-based distribution simply is not, in its current form, a viable model for distributing code that must survive the compromise of the original distributing party. None of the technical (off-server code signing) or social (review of update notices) tools available in non-web distribution methods are available.

The damage that you and other projects cause to public awareness and comprehension of crypto issues is potential staggering.

When you factor in the real risks people take when relying on crypto to communicate in hostile situations, you're doing more than just making nerds grumpy -- you have the potential to significantly harm people's lives.

Crypto is not an amateur's game. Some things are too important to be left to experimentation by unqualified engineers.

I don't think CryptoCat has been distributed as a traditional web app for at least a year (probably more). The browser code is distributed as an extension, which does not have the properties you describe.

edit for sub-comment: A traditional web app updates every time you hit the URL. In a browser extension your code is not necessarily tied to any remote origin, including the Chrome/Firefox stores. It is a user's choice to automatically receive updates from the vendor and this is the same choice that you make if you use apt-get vs manual download/checksum/sig check/audit.

> The browser code is distributed as an extension, which does not have the properties you describe.

Actually, browser extensions have the exact same properties except for being code signed. That's not enough: http://arstechnica.com/security/2014/01/malware-vendors-buy-...

> I don't think CryptoCat has been distributed as a traditional web app for at least a year (probably more).

That they ever shipped in-browser crypto demonstrates that they shouldn't be shipping crypto.

Malicious people buying extensions and then malwareing it is as likely or not as malicious people buying the vendor of whatever tool you are using on the desktop once its auto-updating feature is good enough (that would actually be slightly worse, because in the case if the extension you at least get to read what's actually executed).

What you are saying is that you don't trust any kind of application to do crypto unless you have previously audited it. That's a reasonable stance to take but it's irrelevant whether you distrust a third-party browser extension or a third-party native app.

The main argument against crypto in JS extensions is that getting crypto correct in regards to timing based side-channel attacks is very hard to impossible.

But if you are dealing with a specific browser in an extension context, this might be somewhat mitigated which would bring us back to the trust issue, which, again, IMHO is not dependent on the platform you use

> ... once its auto-updating feature is good enough ...

This is why it's a very bad idea to implement silent automatic updates, and why they're the wrong thing to copy from the web.

Was it commissioned by you? The audit I saw had the Open Technology Fund's logo on it. OTF is a US Government effort driven by Radio Free Asia and the Broadcast Board of Governors.

OTF, again (smartly) using US taxpayer dollars, funds audits of a variety of privacy technologies.

For instance, they also funded a good-sized chunk of the Truecrypt audit.

Hi Thomas,

OTF provides a form projects like ours can fill to commission this type of audit. So basically, we asked OTF to commission it for us and they accepted. TextSecure, a great encryption app that I've seen you recommend, also approached OTF and obtained an audit from iSEC via this same process. However, TextSecure decided not to publish their audit results.

You can read about OTF's reaction to these audits here: https://www.opentechfund.org/article/bringing-openness-secur...

I feel very comfortable recommending TextSecure. TextSecure might be the only secure messaging app I feel that way about.

For whatever it's worth: I have no commercial relationship with the TextSecure team, have never worked with them, have never been paid to audit their code, and am only faintly acquainted with Moxie (I've talked to him in person to know that he's extremely pleasant and surprisingly soft spoken, but not more than that).

Trevor Perrin, who worked with the TextSecure project to help design their cryptography, is someone I know a little bit better; it would be safe to say that Trevor Perrin is the only reason I know anything about cryptography, and, given a few bar napkins, I can outline a pretty convincing story that he is the root of basically every TLS vulnerability discovered after Marsh Ray found the resumption bug.

TextSecure is a great project, and if anyone was debating between it and some other cryptographic messaging application, I hope I've made that decision a little easier.

I agree! TextSecure is an excellent project. We're actually very lucky to be able to bring in Trevor Perrin this month to contribute to Cryptocat.

It's really great seeing Trevor contributing on the IETF [TLS] working group mailing list.

To clarify, these audits aren't a choice, they are a contractual obligation as part of receiving grant funding from OTF. Projects are allowed some flexibility in terms of when they schedule it, but it has to be done. I think it's a great idea.

Also, during the period of time when TextSecure received audits from firms as part of an OTF grant, publishing the results was not an option that was contractually available to us. It's not something we "decided."

Since I am familiar with the process, I know for a fact that OTF asks every project whether they'd like to publish their audits, including TextSecure.

That being said, what is stopping you from publishing the audits today?

They do that now. Dan's OTF post suggests that it wasn't always that straightforward, because the auditors had a proprietary interest in their reports.

Hmm. Cryptocat was actually the first ever OTF project. I believe they've always asked for the publication of audits.

What I'm curious about is, why don't other projects such as TextSecure publish their audits as well? I'd certainly appreciate Moxie answering this question.

The OTF blog post certainly makes good points for this to happen. I also personally believe that this reticence to publish audits is damaging to the opportunity for the honest evaluation of encryption software and the establishment of a realistic perception of encryption software. It also misleads users.

>What I'm curious about is, why don't other projects such as TextSecure publish their audits as well?

Its embarrassing, duh.

For who, TextSecure or the auditors? Both are possibilities, one slightly more likely than the other. Auditors hate having reports published with no major findings.

Why isn't Moxie replying? Publishing an audit, with or without vulnerabilities, surely is beneficial to TextSecure. I don't understand their reticence to publish audits. We know OTF has commissioned at least two audits for them, but not a word has been heard about them.

In fact, OTF has actually complained about their projects choosing not to publish audits: https://www.opentechfund.org/article/bringing-openness-secur...

This is the sixth time you've "asked" in this thread about TextSecure's audit. Cryptocat has literally never implemented a crypto feature of any sort, from random number generation all the way through user authentication, without some terrible vulnerability. TextSecure, on the other hand, is the subject of a total of zero published crypto vulnerabilities.

Whatever Moxie's reasons for not having published their audit, I'm sure they're valid. Either way, no amount of innuendo about TextSecure is going to change the ground truth about your own project.

There might be no person on the Internet more poorly positioned to cast aspersions on other people's projects than you. Please stop.

To be clear, I'm not trying to cast aspersions. As I've already stated, TextSecure is a great project that I strongly recommend.

I'm trying to have a serious discussion regarding transparency of audits. I feel your reaction is overly aggressive and not genuinely constructive.

I can't tell if you actually don't know who commissioned it or if this is your way of suggesting that the parent comment is a lie. It seems like information you would have access to, considering your connection with iSEC, no? (I'm not trying to stir up shit, just genuinely curious.)

Whoah! I'm not saying anyone is being dishonest. I know approximately as much as anyone who can read the linked PDF knows, modulo that I also know a bit about how OTF works because I worked with Matthew Green on coordinating the Truecrypt audit.

I was asking for clarification, but my writing style is dry and blunt, so I'm not surprised if I managed to convey something different. I apologize in advance if so.

More than anything else, I wrote the comment as a (hopefully mild) F-U to the sentiment that the USG is hellbent on destroying privacy on the Internet. Big parts of it are, sure, but there are good people working inside of it too. :)

I do not work for isec or matasano and I had the same question tptacek posted. The lead developer says that audit was commissioned by "us" and yet page 7 of the audit states:

  The Open Technology Fund (OTF) engaged iSEC Partners to perform a source-code
  assisted security review of the CryptoCat iOS application.

Another option is that OTF approached CryptoCat, from where their options would be:

a) don't do an audit - and the public would ask what they are hiding

b) agree to an audit being done, meaning you 'commissioned' it.

So it is just as important to know who approached who in this situation.

One answer, given downthread, might be that the audit was a requirement attached to grant funding from OTF.

It is nice that OTF is funding audits and releasing the reports. It is too bad we can not find out more info on the mythic SJCL audit.

I agree; the work Dan Meredith at OTF is doing is truly impressive.

they(cryptocat) commissioned it or were at least involved. https://news.ycombinator.com/item?id=7519431

> It's very unfortunate that this audit is being taken out of context like this and used to attack our effort.

No, what's unfortunate is your continued and repeated claims that cryptocat should be used today by people who expect privacy, when it is not yet safe or secure for private messaging.

You're going to get people killed. You don't seem to care.

The audit doesn't even seem terribly brutal. Just thorough. I wish every bug report were like this ;)

I don't know if this is news to some people, or what, but it is usual, when having a product professionally tested, to have the testers test it in earnest, as if it were ready for release. They won't avoid telling you about some obvious hole just because it was obviously accidentally left in and would be a 10 second fix (or whatever - that is just a random example).

If you've never been through this before then, presented with a big pile of bugs, it can seem like the project has been proven a total fuckup, and its authors obvious failures, and so on. But in fact, once you've got this concrete list of all the ways in which your program has so far proven itself hopelessly unsuitable for release, it's actually quite surprising how quickly they all get fixed...

(Edit - This is more of a general comment than anything specifically about cryptocat)

We commissioned this audit in late December and iSec began working on it in January. They audited a pre-release prototype that we provided. This is noted in the audit document, but it's hard to spot unfortunately.

The reason we commissioned this audit is to make sure our prototype was audited before release on the App Store. We're very happy to have benefited from this audit, but linking to this PDF alone de-contextualizes the effort and makes it seem like it's an audit of the production version of Cryptocat for iPhone, whereas the version we provided was an early prototype. The audit did find some issues with the (already-released) desktop version and server configuration, and those were also fixed and documented in our blog post.

I sincerely appreciate you taking the time to read our blog post on the matter and thank you for your understanding.

How was this a "pre-release prototype" audit of Cryptocat if the app was for iOS was rejected from the Apple app store in December.... and the audit took place after that in mid January? Seems dubious to say it was all about some extra debug logging when there are some serious flaws here found weeks after it almost was approved on the Apple store.

http://www.theverge.com/2013/12/27/5249402/encrypted-chat-se...

We submitted a pre-emptive build just to obtain approval from Apple. We were going to wait to update it with the audited build before actually releasing it (Apple lets you schedule releases in advance.) In retrospect, it was lucky we got Apple's rejection early on, so we were able to deal with it better.

Page 7/35 of the report:

Addendum(3/15/14): The iOS application was in development code that at time of testing was available only in a preproduction form on GitHub and not distributed via the AppStore. The CryptoCat team had time to review the vulnerabilities prior to publication in the AppStore and claims to have addressed them; however, iSEC has not validated any fixes and cannot make any claims to the current status of any vulnerabilities

Rest assured of my utmost respect and support, Nadim.

Upvoted your comment, flagged OP post. Don't think I've flagged anything on HN before, but I think this warrants that.