Security Informations about Browser Notebook

Private notes through encryption

Browser Notebook uses the Stanford JavaScript Crypto Library (SJCL),
but (unlike the SJCL standard) it uses The text is encrypted with AES in CCM mode (authenticated encryption to protect the integrity of the data).

Never Stores Cleartexts

The text is stored in encrypted form and only on your own disk.
The plaintext (cleartext) is only present in the memory (RAM) - even if you have entered the password.

In-Browser or Client-side Encryption with JavaScript

Many security engineers and cryptographers do not recommend encryption that is running in the browser of the client by JavaScript code. For example Tony Arcieri concludes in his article What’s wrong with in-browser cryptography? that browsers are not designed to create software that respects the user’s interests, not the web site provider’s. Nate Lawson claims in his article Final post on Javascript crypto that he never expects that any Javascript crypto is more secure than traditional implementation approaches. The scenario he describes, does not apply completely to Browser Notebook, because here the texts are stored locally and there is no need to store anything on server-side - especially not the key! But some objections also apply to Browser Notebook.

Although these articles are a several years old, most of the arguments still hold. One exception is probably, that there is now a approved JavaScript cryptographic library (SJCL), a project started 2009 by some well known cryptographers of the Stanford University. They also strengthened the pseudorandom number generator by user interactions (mouse movements), timing measurements and server-side authentication cookies and tested the entropy of the resulting PRNG.

Overall, I maintain that the criticism is justified, but the most serious criticisms do not apply to Browser Notebook, at least not to the offline version. Further objections still apply, so the question arises why client-side encryption at all.

There is one (perhaps only) great advantage for in-browser encryption: Web browsers are familiar to almost all people. There are many good encryption programs, but the problem is, that most of the people do not use them. Even relatively easy-to-use extensions like Enigmail for Thunderbird represent a very high hurdle for many people.

Criticisms applied to online and offline Browser Notebook:
  1. Browser is low-assurance environment
    (Nate Lawson)
  2. Side channel resistance is much more difficult if not impossible.
    (Nate Lawson)
  3. Too many platforms — IE, Firefox, Netscape, Opera, WebKit, Konqueror, and all versions of each. Crypto code tends to fail catastrophically in the face of platform bugs.
    (Nate Lawson)
  4. Javascript is many times slower than native code.
    If the performance ratio between attacker and legitimate users is too great, Javascript can’t be used for this purpose.
    (Nate Lawson)
  5. (I don't think, the poor PRNG is an objection since SJCL strengthened version, although /dev/urandom is of course better.)
Criticisms applied only to the online version of Browser Notebook:
  1. The code can change dynamically, controlled by the server, not the client. Malicious code can be loaded dynamically and any audit is impossible. Therefore a server can't provide a “Trust No One” service, instead you have to trust the server operators and can't check it.
  2. Nate Lawson wrote:
    An attacker can trojan the JS that is sent to the user. Any changes to the code immediately take effect for all active users.
    If you are using TSL (like Browser Notebook), I can't see how any others than the (maybe compromised) server can do this. You can also compromise a download server for other applications, so I don't think this is specific for JavaScript applications other than the objection above (you can't trust the server operators).