Artificial truth

archives | latest | homepage | atom/rss/twitter

The more you see, the less you believe.

Why you should not use MyCryptoChat
Thu 16 January 2014 — download

A lot of people are talking about the php version of MyCryptoChat, which is a web application that provides a chat, ciphered client side in Javascript. How could this possibly go wrong ?

Since it seems that the author has absolutely no clue about how to design and use cryptography, nor how to establish a threat model.

The obvious

First, an XSS:


This allows an attacker to steal your keys/data.


As you can see, he fixed the XSS issue. Unfortunately, this does not fix anything, my PoC is still working.

Implementation issues

Like almost every amateur cryptography software, it claims to use AES256, but does not say anything about the mode, or the integrity. Fortunately, it seems that the default one for sjcl (The cryptography Javascript library used) is CCM, which (luckily) provides authentication. This should be documented!


This is the user id generation routine:

function getHashForIp() {
    return substr(md5($_SERVER['REMOTE_ADDR'] . SEED), 0, 16);

The seed is of course hardcoded. You can impersonate people that are using the same IP than you.

Key generation issues

This is the key generation routine:

function generateRandomKey() {
  var text = "";
  var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

 for (var i = 0; i < 30; i++) {
      text += possible.charAt(Math.floor(Math.random() * possible.length));

 return text;

Math.random is not a PRNG suitable for cryptography, using it as one is utterly stupid.

Javascript is not crypto-compliant

Cryptography in Javascript is fundamentally broken, for several reasons:

  1. You have no control on the cache. This mean that you can not be sure about the environment in which your code is executed.
  2. You can not run things in a constant time, since the browser tries to go as fast as possible, which opens the way to many side channels attacks.
  3. Javascript allows environment changes at runtime, like for example, overwriting functions. You can not check if the functions that you are running are not overridden, neither can you ensure that some externals functions won't take a look at some of your cryptographic data (like you key for example).
  4. There is no secure erasement, since Javascript is garbage collected. Your keys and data may stay longer in memory than you though.
  5. Javascript runs on a wide range of platforms. How can you be sure about their behavior and respects of standards ?

This is what the authors of SJCL are saying:

We believe that SJCL provides the best security which is practically
available in Javascript. (Unfortunately, this is not as great as in desktop 
applications because it is not feasible to completely protect against code
injection, malicious servers and side-channel attacks.)

Even the authors are saying that their library is not good for doing cryptography in a secure manner.

SJCL is cross-browser. We hope.

I prefer correct cross-platform implementation than hope.

You could argue that for client-side web cryptography, you are stuck with Javascript. This does not mean that it is ok to use it to do cryptography. This means that you should not do client-side web cryptography.

Threat model issue

  • There is no documentation (Not even a readme!) about what kind of crypto is used, how you should deploy it, or implementation choices. Nor is there a threat model explaining to design goal, limitations, concerns, ...
  • You have to trust the server to delivers you cryptographic-compliant Javascript. The example instance runs on
  • There is no convenient way to verify that the Javascript received is the one given by the author. Even if there was some hashes or cryptographic signatures, no one will ever check them.
  • Like said, the page must not call any external resources, because what if an external website, like the one you may use for tracking or whatever wants to change your encrypt function or to take a look at your key?
  • There is no authentication at all. How can you be sure that you are talking to the one you think you are talking to? (Hint: you can't) Stating that this is because the application is meant to be KISS and should require no registration is not a valid argument. How about shared secrets ?

Various remarks

  • The application is young. I mean, if security-related concerns are still found in GNUPG (Started in 1990) or OpenSSL (Most used SSL/TLS library in the world), what are the odds that you'll found plenty of them in a young, unaudited, hobby programmer side project developed library ?
  • The developer's demo is available only on http.


  • Broken implementation
  • Broken cryptography
  • No documentation/threat model
  • No peer review

You should never use this kind of software, but rather strong and proofread implementations of solid cryptography, like OTR or GPG.

Related links: