

#Cryptocat ios review update#
None of the technical (off-server code signing) or social (review of update notices) tools available in non-web distribution methods are available. 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. Given this remarkably self-serving and ill-conceived stance, it's difficult to imagine how your crypto could ever be considered trustworthy. You're seriously misleading users regarding the security of crypto - the web is an environment that has ZERO controls on code updates. Even the Cryptocat network itself can't read your messages. > Everything is encrypted before it leaves your computer. You're doing crypto in the browser, while claiming on your home page: Therefore, unlike the desktop version, Cryptocat for iPhone was never affected by this issue." Thanks to these audits, this issue was caught in Cryptocat for iPhone before it was released. This is a problem that can be exploited in some real-world scenarios and needs to be addressed with appropriate authentication warnings. Group multi-party discussions do not seem to suffer from the same vulnerability." (emphasis mine) This permits the attacker to decrypt all messages that follow, and no user would have reason to suspect the compromise. 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. "CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notification. 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." 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. 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. Read what we're doing to improve the security of accessible encryption and our reasoning for publishing these audits. 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.
#Cryptocat ios review how to#
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. I'd appreciate it if you could please upvote this comment and help me contextualize this audit. It's very unfortunate that this audit is being taken out of context like this and used to attack our effort. 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. 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. This audit was commissioned by us and concerns a pre-release version of Cryptocat for iPhone. This audit document alone does not give enough context. I strongly urge you all to please read our blog post regarding this audit. Hi, I'm the lead developer for Cryptocat.
