Thanks, Moxie, for clarifying a lot already. I have some more things to add as Cryptocat's lead developer: This is a very misinformed blog post that's been going around concerning Cryptocat's development roadmap that I need to address, simply because not only is the post so fundamentally incorrect on its technical assumptions, but it goes around being written in a surprisingly authoritative tone: The blog post suggests that becoming a local browser app means that Cryptocat no longer uses JavaScript cryptography. This is nonsense: JavaScript is a *language*, and since browser apps/plugins are written in an HTML5 framework, we will still be using JavaScript to implement cryptographic functions. The only thing that has changed is *the method of code delivery.* Cryptocat research, even with this change in code delivery, remains within the purview of JavaScript cryptography research, not abandoning it but improving it by suggesting a different method of code delivery. The articles that the blog post links to attack JS crypto code delivery methods, and we are answering those concerns: * We have NOT "Abandoned JS crypto" and "officially declared" that JavaScript crypto is "wrong." * We have NOT "declared that you cannot do serious crypto in pure JavaScript" * We HAVE simply changed the method of JS code delivery into a local browser plugin, in order to further advance the security of JS cryptography. I have absolutely no idea where the author pulled his conclusions from and I'm really surprised as to how certainly he posits them in his blog post. The author goes on to posit that a browser extension be used in order to provide a standard cryptographic API for browsers. This is redundant for two reasons: * The W3C is already working on a standard cryptographic API for browsers: http://www.w3.org/2012/webcrypto/ (Cryptocat is part of this working group.) * There exists a variety of vetted, very well-designed standard libraries for client-side browser crypto, such as http://crypto.stanford.edu/sjcl/and http://code.google.com/p/crypto-js/. When writing a blog posts that takes ideas as granted facts, please make sure you know what you're talking about. NK On Sat, Aug 4, 2012 at 12:58 PM, Moxie Marlinspike <moxie@thoughtcrime.org>wrote:

I've noticed that this discussion has a tendency to be framed in terms of the crypto primitives. The core problems, as I see them, are actually somewhat unrelated to whether it's possible to efficiently perform cryptographic operations in JavaScript or not. In my reading, this blog post seems to imply that the recent decisions CryptoCat has made are a result of that question, but my understanding is that they're actually fairly unrelated.

A W3C standardized Crypto API, or a browser extension that acts as a generic crypto provider, are a little too myopic to fully address the fundamental question of the interaction between dynamically loaded JS and the user's interface to their browser. The problem isn't so much whether JS can perform a cryptographic operation, but whether the user knows that it is, to what extent, to whom, and what *else* the JS is doing.

The questions that CryptoCat has brought up for me are:

1) How does one create a webapp that provides client-based cryptography, without the security of that app simply being reduced to the security of SSL? If every time I initiate a chat session, it's a JS app that I'm loading over SSL, any attacker who could intercept that SSL connection (a lot of people today) would be able to intercept the contents of that chat session simply by modifying the JS in transit (so that it sends the attacker a copy of the plaintext, etc). Doesn't matter whether the crypto primitives are good are not.

2) How does one create a webapp that provides client-based cryptography, without the security of that app simply being reduced to the security of server-based cryptography? If every time I go to encrypt something client-side, I have to ask the server for the JS to perform that encryption, it's reducible to trusting the server with my plaintext. The server could choose, at any time, to hand me JS that appears to be performing encrypted operations, but is also transmitting a copy of the plaintext as well. Again, this doesn't depend on the existence of solid crypto primitives.

3) Is there any value at all to "warnings" that are placed on tools for providing secure communication or privacy, and is there something we can do better or instead? These types of warnings are beginning to suffer from a "certificate warning" effect. Users are so accustomed to seeing them that they ignore them. Even Tor, which has been around for years, and is widely recommended for use in a number of dangerous situations, still comes with a warning about its beta nature. In some sense, it's possible that a "warning" is now almost an incentive for someone to use that tool in a hostile context: people who are serious about security put warnings on their tools, while charlatans wouldn't be so inclined.

4) How do we experiment with security/privacy solutions? If we don't have all the answers, but want to attempt to start a discussion or an effort in a specific direction, what do we do? If we do it in public, chance are that people might actually start using our solution (perhaps proportionate to the number of warnings we include!), or reporters might start writing articles with shamefully ridiculous headlines about it.

- moxie

-- http://www.thoughtcrime.org

On 08/04/2012 12:06 PM, Uncle Zzzen wrote:

...

https://crypto.cat will soon stop being a web-based service, and will only exist as a browser extension. The question is, what should future web-app developers do if they need crypto? Rewrite all crypto primitives from scratch [and hope there's enough interest in reviewing the code], then let users install yet another extension?

I believe there's a better solution. I've posted something about it. I hope some of you would find it interesting.

http://thedod.noblogs.org/post/2012/08/04/what-ive-learned-from-cryptocat/

...

Cheers, The Dod _______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click

above) next to "would you like to receive list mail batched in a daily digest?"

...

You will need the user name and password you receive from the list

moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

...

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

_______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

_______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE