8 ms·

Hi, I'm the lead developer for Cryptocat. I strongly urge you all to please read our blog post regarding this audit: https://blog.crypto.cat/2014/04/recent-audi

Hi, I'm the lead developer for Cryptocat. I strongly urge you all to please read our blog post regarding this audit: https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/ https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp... 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. 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. https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/ https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp... 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.

deleted 13y ago
[deleted]
- kaeporan 13y ago
  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.
  - 115515 13y ago
    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-service-cryptocat-for-iphone-rejected-by-apple http://www.theverge.com/2013/12/27/5249402/encrypted-chat-se...
    - kaeporan 13y ago
      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.
- pygy_ 13y ago
  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
  - deleted 13y ago
    [deleted]
erikano 13y ago
Upvoted your comment, flagged OP post. Don't think I've flagged anything on HN before, but I think this warrants that.
teacup50 13y ago
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.
- smcgregor 13y ago
  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.
  - teacup50 13y ago
    > 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-chrome-extensions-to-send-adware-filled-updates/ 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.
tptacek 13y ago
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.
- napoleond 13y ago
  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.)
  - tptacek 13y ago
    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. :)
  - dfc 13y ago
    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.
  - nikcub 13y ago
    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.
to3m 13y ago
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)
anologwintermut 13y ago
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 notiﬁcation. 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 ﬁngerprint. 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 suﬀer 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."
zz1 13y ago
Rest assured of my utmost respect and support, Nadim.
sneak 13y ago
> 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.

deleted 13y ago

[deleted]

kaeporan 13y ago
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.
- 115515 13y ago
  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-service-cryptocat-for-iphone-rejected-by-apple http://www.theverge.com/2013/12/27/5249402/encrypted-chat-se...
  - kaeporan 13y ago
    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.
pygy_ 13y ago
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
- deleted 13y ago
  [deleted]

erikano 13y ago

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

teacup50 13y ago

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.

smcgregor 13y ago
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.
- teacup50 13y ago
  > 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-chrome-extensions-to-send-adware-filled-updates/ 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.

tptacek 13y ago

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.

napoleond 13y ago
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.)
- tptacek 13y ago
  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. :)
- dfc 13y ago
  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.
- nikcub 13y ago
  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.

to3m 13y ago

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)

anologwintermut 13y ago

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 notiﬁcation. 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 ﬁngerprint. 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 suﬀer 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."

zz1 13y ago

Rest assured of my utmost respect and support, Nadim.

sneak 13y ago

> 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.