Hi, I'm the lead developer for Cryptocat.
I strongly urge you all to please read our blog post regarding this audit: <a href="https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/" rel="nofollow">https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...</a><p>This audit document alone does not give enough context. This audit was commissioned by us and concerns a pre-release version of Cryptocat for iPhone. Many of the bugs it found are due to the fact that it was reviewing a prototype with debugging features (such as NSLog) turned on. While this audit definitely does find some vulnerabilities and room for improvement, none of the critical bugs in this audit ever made it to Cryptocat for iPhone's release.<p>It's very unfortunate that this audit is being taken out of context like this and used to attack our effort. I'd appreciate it if you could please upvote this comment and help me contextualize this audit. Again, please, read the blog post for context (and also for the results of another audit we comissioned in parallel.) We've done our best to address these issues and are working towards an open discussion on how to improve accessible encryption. <a href="https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/" rel="nofollow">https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...</a><p>The blog post's last section ("On the Significance of Audits") discusses why it is that Cryptocat has seen more audits published about it than other encryption projects. Please, dare to discern. Read what we're doing to improve the security of accessible encryption and our reasoning for publishing these audits. I'll be grateful for you taking the time to read on what we're doing and I am more than happy to discuss with you and answer your questions.
This is most alarming.<p><i>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.</i>
When I saw one of the main CryptoCat developers present in 2012, I came away with the impression that nobody on the core team understood crypto, security, or software engineering. This audit is another rock on the mountain of evidence I've seen supporting this impression in the following years.<p>A really nice job by iSec, though.
Also of interest is their blog post about how they plan to handle the issues described in this report: <a href="https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/" rel="nofollow">https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...</a><p>Reading that, I still am not sure why anyone would use CryptoCat especially with things like TextSecure on the market that seem to take crypto far more seriously. The only reason I can see for that is that they have clients on more platforms, but if this is similar to the state of all of them, then what's the point?
There is a "many ways to skin a cat" joke here somewhere. It is actually terrible - the hmac timing attack requires around 3 minutes of google searching to avoid and is basic public domain knowledge. The other are much worse.
This is awesome. I'm sad that CryptoCat is getting slammed for this for being one of the brave few to post this online. I am sure there are an infinite number of "security-critical" apps which would fail an audit like this, but who never even thought to GET an audit -- much less post it online. The software development community is much stronger for being able to see professional stuff like this posted.<p>Does anyone know how much these audits typically cost, if you're not being subsidized?
Here is our blog post about our audit of Cryptocat, which was also announced today: <a href="https://leastauthority.com/blog/" rel="nofollow">https://leastauthority.com/blog/</a>
Didn't realize how vulnerable even a simple NSLog was... I wonder how many websites have sensitive information they console.log but forgot to take out for production
Wow, remind me to never have an audit done by iSec. "Extremely thorough" would have been tough but appropriate, but "brutal" seems just gratuitously provocative. Was that what you were going for?<p>Edit: OK, apologies to iSec for my mistake. I thought he was still affiliated with them. In any case, it looks like a top-notch report, so it would have been a shame to detract from that accomplishment.
I for one think that Nadim and the Open Tech Fund are to be applauded for opening up their review to the public. I have to wonder how many other commercial and non-profit organisations would ever consider doing this? (Especially those which are in the field of communications and are relied on by people for their lives).<p>Many people on HN seem to be reading the review without actually looking at Nadim's response on the Cryptocat blog - which I urge everyone to read first before commenting.<p><a href="https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/" rel="nofollow">https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...</a><p>As far as I understand the username for Nadim (Kaeporan) was also blocked from HN last night so probably he isn't able to continue responding to the comments up here.
Huh, this was apparently submitted by Alex Stamos, a co-founder of iSec partners (who did this audit). And he editorialized the title, "Brutal Professional Audit of CryptoCat Published."<p>Your former company did an audit for a customer, then you posted it to HN calling it "Brutal"? Really?