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. 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 might be the only secure messaging app I feel that way about.įor 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). I feel very comfortable recommending TextSecure. Some things are too important to be left to experimentation by unqualified engineers. 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.Ĭrypto is not an amateur's game. The damage that you and other projects cause to public awareness and comprehension of crypto issues is potential staggering. 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. 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.
0 Comments
Leave a Reply. |