[liberationtech] What I've learned from Cryptocat

[Moxie Marlinspike]

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