8 ms·

Cryptocat: webchat with client-side encryption features

24 points by magikarp 15y ago

gojomo 15y ago
Made a test room, 'hn' (https://crypto.cat/?c=hn https://crypto.cat/?c=hn). Set a key, 'password'. Will leave it open in background and peek in occasionally if others want to try.
u48998 15y ago
Seems useful.
- Breefield 15y ago
  Why not just have users type in a room name and password on creation...no need to set the salt after the fact.
- mtogo 15y ago
  Except that the encryption is handled with javascript (obviously). I wouldn't use this for anything serious.
  - magikarp 15y ago
    Why not? AES has been implemented in javascript half a dozen times.
    - tptacek 15y ago
      And? What is that evidence of?
      - sorbus 15y ago
        That the implementation of an encryption library in Javascript is not a reason to mistrust services which use that library?
        tptacek 15y ago
        It isn't evidence of that. Implementation in browser JS is in fact a reason to distrust a cryptosystem.
    - mtogo 15y ago
      Okay..? What difference does that make?
      - cranklin 15y ago
        because... the server might send a broken .js therefore forcing your chat client into sending plain text.
        mtogo 15y ago
        Exactly, that's the point. Or a browser extension. Or various other fun things, see tptacek's conversation above.
dekz 15y ago
Took me a little while to realise you set the password in the blue box above the text entry. Interesting concept though. For those interested it uses crypto-js (http://code.google.com/p/crypto-js/ http://code.google.com/p/crypto-js/). Might want to increase the random entropy source, from what I can see it's just DateTime. Also I'd use a better hashing algorithm than SHA1 with AES-256. I understand the need for PBDKF2, but I'm not so sure about using the password as the key and salt.
- tptacek 15y ago
  They aren't using SHA1; they're using HMAC-SHA1. Not the same thing. That said: this is an idiosyncratic (rekeying AES every 500ms?) and not particularly resilient cryptosystem. As a commenter said below: don't use this for anything serious. You're equally well off with a server that simply sends "plaintext" messages over TLS.
  - magikarp 15y ago
    AFAIK, the server does not rekey AES every 500ms - and your suggestion to use a server over TLS opens you up to the problem of the server itself being able to read all plaintext.
    - tptacek 15y ago
      The server can read all the plaintext anyways.
      - magikarp 15y ago
        Right...
      - magikarp 15y ago
        No it can't, that's the whole point! Are you trolling?
        tptacek 15y ago
deleted 15y ago
[deleted]
cranklin 15y ago
I was thinking of building something similar. The benefits of client-side encryption is that the message is entirely encrypted until it reaches the destination. Even if the cryptocat server was compromised, the message is still "safe".
- tptacek 15y ago
  No, if the server is compromised, you are thoroughly boned. In fact, there are very common vulnerabilities that don't come close to compromising the server that still destroy the security of this scheme. Javascript cryptography is almost always a terrible idea.
  - magikarp 15y ago
    "If the server is compromised [insert disastrous result here]" applies more so to many other servers serving you crypto - I feel there's the advantage of being able to verify the .js files yourself in your browser here:   <script type="text/javascript" src="js/crypto.js"></script>
    - tptacek 15y ago
      You can't just verify the .js file! You have to verify every line of JS code that ever hits the JS interpreter, whether it's specified directly in the source code that the author told you about or eval'd later in some random event handler. That code could come from an explicit <script> tag in the original DOM source; it could come from an event handler specified in the DOM, or set later by any other piece of JS; it could come from an Ajax request handler; in many browsers, it can even come from CSS. It can easily hide itself after it does its job, and it isn't going to look like "". The browser JS runtime does not provide the tools you need to verify the integrity of a cryptosystem. Full stop. Actually, browser JS runtimes don't even provide the tools you need to safely run a cryptosystem. How do you know what intermediate values are cached by any given JS? How do you know if any given crypto function is leaving footprints in browser memory? You don't; nobody does; nobody has published the exhaustive analysis of any browser JS to support an argument either way. Not that that matters for crypto.cat; they don't seem to care much about side channel stuff; for instance, their HMAC compare is the JS string "!=" operator. As for "applies to so many other servers": I don't know what you're saying. You made a claim about the security properties of this application. That claim was wrong. It doesn't become right when you point out some other app that has the same flaw.

24 points by magikarp 15y ago

Made a test room, 'hn' (https://crypto.cat/?c=hn https://crypto.cat/?c=hn). Set a key, 'password'. Will leave it open in background and peek in occasionally if others want to try.

u48998 15y ago

Seems useful.

Breefield 15y ago
Why not just have users type in a room name and password on creation...no need to set the salt after the fact.
mtogo 15y ago
Except that the encryption is handled with javascript (obviously). I wouldn't use this for anything serious.
- magikarp 15y ago
  Why not? AES has been implemented in javascript half a dozen times.
  - tptacek 15y ago
    And? What is that evidence of?
    - sorbus 15y ago
      That the implementation of an encryption library in Javascript is not a reason to mistrust services which use that library?
      - tptacek 15y ago
        It isn't evidence of that. Implementation in browser JS is in fact a reason to distrust a cryptosystem.
  - mtogo 15y ago
    Okay..? What difference does that make?
    - cranklin 15y ago
      because... the server might send a broken .js therefore forcing your chat client into sending plain text.
      - mtogo 15y ago
        Exactly, that's the point. Or a browser extension. Or various other fun things, see tptacek's conversation above.

dekz 15y ago

Took me a little while to realise you set the password in the blue box above the text entry. Interesting concept though. For those interested it uses crypto-js (http://code.google.com/p/crypto-js/ http://code.google.com/p/crypto-js/). Might want to increase the random entropy source, from what I can see it's just DateTime. Also I'd use a better hashing algorithm than SHA1 with AES-256. I understand the need for PBDKF2, but I'm not so sure about using the password as the key and salt.

tptacek 15y ago
They aren't using SHA1; they're using HMAC-SHA1. Not the same thing. That said: this is an idiosyncratic (rekeying AES every 500ms?) and not particularly resilient cryptosystem. As a commenter said below: don't use this for anything serious. You're equally well off with a server that simply sends "plaintext" messages over TLS.
- magikarp 15y ago
  AFAIK, the server does not rekey AES every 500ms - and your suggestion to use a server over TLS opens you up to the problem of the server itself being able to read all plaintext.
  - tptacek 15y ago
    The server can read all the plaintext anyways.
    - magikarp 15y ago
      Right...
    - magikarp 15y ago
      No it can't, that's the whole point! Are you trolling?
      - tptacek 15y ago

deleted 15y ago

[deleted]

cranklin 15y ago

I was thinking of building something similar. The benefits of client-side encryption is that the message is entirely encrypted until it reaches the destination. Even if the cryptocat server was compromised, the message is still "safe".

tptacek 15y ago
No, if the server is compromised, you are thoroughly boned. In fact, there are very common vulnerabilities that don't come close to compromising the server that still destroy the security of this scheme. Javascript cryptography is almost always a terrible idea.
- magikarp 15y ago
  "If the server is compromised [insert disastrous result here]" applies more so to many other servers serving you crypto - I feel there's the advantage of being able to verify the .js files yourself in your browser here:   <script type="text/javascript" src="js/crypto.js"></script>
  - tptacek 15y ago
    You can't just verify the .js file! You have to verify every line of JS code that ever hits the JS interpreter, whether it's specified directly in the source code that the author told you about or eval'd later in some random event handler. That code could come from an explicit <script> tag in the original DOM source; it could come from an event handler specified in the DOM, or set later by any other piece of JS; it could come from an Ajax request handler; in many browsers, it can even come from CSS. It can easily hide itself after it does its job, and it isn't going to look like "". The browser JS runtime does not provide the tools you need to verify the integrity of a cryptosystem. Full stop. Actually, browser JS runtimes don't even provide the tools you need to safely run a cryptosystem. How do you know what intermediate values are cached by any given JS? How do you know if any given crypto function is leaving footprints in browser memory? You don't; nobody does; nobody has published the exhaustive analysis of any browser JS to support an argument either way. Not that that matters for crypto.cat; they don't seem to care much about side channel stuff; for instance, their HMAC compare is the JS string "!=" operator. As for "applies to so many other servers": I don't know what you're saying. You made a claim about the security properties of this application. That claim was wrong. It doesn't become right when you point out some other app that has the same flaw.