Cryptography for the Masses

“The multiple human needs and desires that demand privacy among two or more people in the midst of social life must inevitably lead to cryptology wherever men thrive and wherever they write.” wrote David Kahn in his book “The Codebreakers”, chronicling the history of cryptography. The book was published in 1967. Almost 45 years later cryptography is seldom used to protect our privacy.

The information age spawned databases and networks capable of extracting and storing large amounts of private data. Those databases are often unknown to us and if we know of their existence we can not control them. They store personal information, communication and financial transactions. This gathering of private data happens against our will if we believe surveys that show that we actually do care about privacy. Skeptics and experts caution us but the majority of web users is forced to give in to the subtle but grave disintegration of privacy, pushed forward by industry and government. They are growing their databases steadily, expanding the records they keep on all of us.

Good question, image by Garrett Coakley

We can see the consequences of these uncontrollable, central databases today. In what is believed to be one of the largest data security breaches in history, attackers stole personally identifiable information of 77 million PlayStation Network users earlier this year.

Accidental exposure of personal data is another problem. It is very difficult to control who has access to which piece of information. People get fired for how they behave online because they confuse personal with public communication. The web does not forget. And ever since the uprisings in the Arab world it should be clear to everybody that what one posts online can have severe consequences, including imprisonment and torture.

There are a variety of interesting judicial and ethical approaches to cope with these issues. And there is cryptography – a technological means of preserving privacy. Cryptography enables anonymity, the concept of ‘publishing information while ones identity is publicly unknown’ as well as privacy, the ability to to ‘seclude oneself or information about oneself and reveal oneself selectively’.

But almost nobody uses cryptography. Asked if he encrypts his e-mail, Bruce Schneier, cryptographer and highly regarded computer security specialist answers “I do not, except for special circumstances”. He further argues that for more people to encrypt their communication, services like Gmail would have to do it by default. This will of course never happen, since those services draw their revenue from reading our messages.

It has to work out of the box

But the more important point Schneier makes is this: what has to happen to spread the use of cryptology? It has to work out of the box. No additional application should be required, no plug-in, no add-on and certainly no driver installation. There exists a concept that could potentially offer a transparent solution for everyone: browser based cryptography.

Browsers have evolved from being a mere presentation and navigation tool for the world wide web to a platform for collaboration and information sharing web applications. If browsers were able to do cryptography, every web users could potentially benefit from it. JavaScript engines have evolved rapidly to a point where they are efficient enough to handle the complex algorithms that cryptography entails. It is ironic that the same web applications that threaten our privacy are the main reason such powerful engines were developed in the first place.

The idea of browser based cryptography is simple: before users upload their personal data to application hosts they encrypt the data in the browser. The host only receives encrypted blobs of data and since users don’t share their key with the host the data is secure. If they decide to share their data with someone else they can provide them with means of decrypting the blobs. Users are in control at all times.

But JavaScript cryptography has many critics and there has been some discussion whether or not it is a viable solution. But the potential is vast and the issue of retaking privacy is too important to dismiss the technology right away. The discussion should not stop here. Solutions can be found to the given objections.

JavaScript Cryptography Criticism

The trust model certainly is a problem and seems inconsistent. The general assumption is that users don’t trust application providers with their data, thus the need for encryption. Modern web applications however download their code from the very same provider and consequently also download the code required for decryption and encryption. A contradiction: users don’t entrust providers with their data but they trust the provider to deliver the application and most importantly the correct cryptography code. Critics argue that users can decide to either trust or not trust whoever hosts an application. If they trust the host there is no need for encryption. If they don’t trust the host they should not share their data in the first place. If someone suspects a host has malicious intentions JavaScript cryptology is worthless.

The situation changes if the ‘honest-but-curious’ adversary model is taken as a basis. It assumes that the company providing a web services carries out the stated instructions and is not lying to the user. It is further assumed that it might do more than it promised such as storing the data for an unreasonably long time or even sharing data with third parties. In such a case JavaScript cryptography might be viable. Furthermore if the company is attacked and database dumps are stolen, the data is worthless. For an attacker to gain access to the data the web application source code has to be modified and users have to use the malicious application. To defeat such attacks, browsers would have to be able to validate web applications to make sure that they were not modified.

Dystopia 2, image by Hervé Girod

Today the browser is an environment not very well suited for cryptography. There is the threat of cross-site attacks: a web page loads content from many sources and all of those can potentially modify the cryptography code. Due to the dynamic nature of the JavaScript language, an attacker can replace correct code with a malicious version. Such an attack can only be discovered through tedious code analysis of all sources.

Critics also argue that browsers lack some crucial primitives important for cryptography such as a random number generation. Fortunately browser vendors see the need for such functions and are moving toward implementing them. Browsers further lack a secure key store, a crucial component in every crypto-system. It is also important to have the ability to securely erase secrets from memory once they are no longer needed. Since JavaScript engines employ garbage collection there is no way to control when objects are deleted and secrets are forgotten.

These issues are significant but they can all be addressed with care. Web developers, cryptographers and browser vendors will have to work together to find solutions to these shortcomings. Once this happens I expect to see secure JavaScript cryptography applications that satisfy even the skeptics. There is still a lot to be done but the potential is tremendous. So we should get to work.

Existing Implementations

Despite the criticism there are already some implementations that utilize JavaScript cryptography out there. They try to make do with the current state of browser support for de- and encryption. Some supplement browser capabilities with custom add-ons. This of course defeats the purpose of JavaScript cryptography but is a necessity at the moment since browser support is still in its infancy.

Aldo Cortesi’s is the most interesting project. It is an online list-manager that encrypts user data in the browser and sends only an encrypted blob to the host. It inspired people to think about what JavaScript cryptology can do and what it means to encrypt data in the browser. Encrypted user data is completely exposed as the application intentionally lacks authentication (except to prevent overwrites). Only the passphrase protects the data. Cortesi uses the expression ‘host-proof’ in his documentation of the project which is a dubious term, especially in the context of JavaScript cryptography. It was coined by Richard Schwartz and emphasizes that the host does not have to be trusted. This is a difficult claim. Users still have to trust the host because it grants the privilege of encrypting the data and it can revoke that privilege at any time. The ‘honest-but-curious’ adversary model again makes more sense.

More questionable applications are Lockify, Zero-Knowledge Box and Clipperz because they explicitly advertise the security of their products that is solely based on JavaScript cryptography. Critics argue that appearance of security is worse than no security at all. Their claim of increased security should indeed be taken with a grain of salt: data that otherwise would not be uploaded due to security considerations should not be stored with those hosts. Even so, the cryptology is a welcome addition to the security measures these companies take. It accomplishes the goal of preserving privacy.

Vintage Mail Boxes, image by Nathen Jantzen, all rights reserved

When asked to choose between a regular web application and a JavaScript cryptography enabled one, the latter is preferable due to privacy considerations since the user does not lose control of his data. Claiming that JavaScript cryptography enabled applications, with the current state of research and browser support, are more secure than others is debatable. We are not there yet.


There are a number of alternatives and especially the concept of storing encrypted data with a curious or even untrusted host is not new. Traditionally, host applications have been used to handle cryptographic operations. These tools must be installed and have to be properly set up by the user. Mobile platforms might be an ideal environment for these alternatives. Installing applications is hassle-free and very common on mobile devices. Due to the well defined platform, developers can keep user effort to configure these applications to a minimum.

Another promising alternative is a browser add-on called Cipherbox. Its developers recognize that it is unlikely that application providers will enable cryptography as well as the shortcomings of current JavaScript solutions. In their architecture they make a point of separating the interaction with the web content from the cryptology functionality. This could proof to be a significant security advantage over other solutions that give web content access to cryptology functions.

A colleague and I devised the idea of a cryptography enabled http proxy that is similar to the Cipherbox. The proxy is a trusted instance possibly hosted locally or connected via a VPN. All http traffic is sent through the proxy. It analyzes the traffic and encrypts and encrypts relevant parts like messages or images depending on its configuration. We implemented a prototype that is capable of transparently encrypting and decrypting Facebook messages using gpg. A proxy like this could run on a user’s FreedomBox and can in theory be extended to provide crypto-functionality for various platforms including for example Gmail.

A special form of cryptography called homomorphic encryption could enable users to take advantage of both cryptography and computing as a service at the same time. If encrypted data is sent to hosts, they usually can not process the data. If instead a homomorphic encryption scheme is in place, for certain algebraic functions on the plaintext, equivalent functions exist that can be applied to the ciphertext. Proponents of this technology argue that it could enable widespread use of cloud computing by ensuring the confidentiality of private data.


Controlling ones personal data is more difficult with every new database and network based innovation. At the same time privacy is more important than ever in a world that prepares to conglomerate health records, gathers and centralizes consumer behavior data and merges individual financial records into powerful profiles. Cryptography is an effective safeguard we must implement to prevent exploitation and discrimination based on our personal information. Every user must be enabled to use cryptology to control the data he wishes to share.

Browsers vendors must implement the building blocks required for cryptography including a secure key store that can be managed by the user. They should also include means of validating a running application against a checksum. Cryptographers and web developers must work together to implement correct and easy to use de- and encryption functionality for browser based applications.

More people must start thinking about this problem, more ideas are needed and should be carefully vetted by cryptographers and security experts. User interface specialists should work on making cryptography a transparent process. We need to get everyone involved and try to revert the damage that has already been done.


#1 Michiel de Jong wrote on October 12, 2011:

Great overview! just to add to this from my own experience i guess, i have been talking less and less about cryptography during the last year, for two reasons: first, where do you put the key store, in a way that is transparent to the user? i would not want my freedombox to be the only key to all my data – whenever it breaks i would lose everything. and second, using cryptography for security raises the potential damage one single bug can cause. so i wouldn’t use anything other than pgp, and even then, if you implement it wrong (e.g. accidentally signing your own key), then all data of all users would suddenly be public. even if that possibility is low, it is a downside of cryptography vs. simple passwords. That’s the two reasons why i don’t want to burn my fingers on it – but i do agree with you that we should keep experimenting with it. is the source code of your proxy available (just out of interest)?

#2 Sebastian Schaetz wrote on October 14, 2011:

Michiel, thank you for your comment. Your concerns are valid. We indeed introduce a single point of failure if we encrypt everything using the same scheme. It must not be your FreedomBox, it can be basically anything – actually the more diverse this is the less incentive there is for crackers to break it. Security is not an absolute.

I don’t see how self-signing is a problem and how it can reveal all data of all users. Care to clarify?

The proxy is a prototype in every sense of the word. I hope I have time soon to clean it up and to publish it. I definitely want to do that.

#3 David wrote on October 15, 2011:

A new browser API standard is in the works – a W3C working group is being formed now. Have a look at the DOMCrypt API:



#4 Sebastian Schaetz wrote on October 17, 2011:

Thanks for the link David, an keep up the good work!

#5 Michiel de Jong wrote on October 17, 2011:

It’s something like – if you sign your own public key with your own private key, then you’re revealing your RSA primes-pair. i think it corresponds to point 4 of but i can’t remember the exact maths and conditions right now.
Anyway, the lesson of that is, it’s easy to get crypto wrong – unless you think about the maths all the time, and are aware of security news and general knowledge, you should not attempt to program a crypto system, because it’s likely you’ll create a buggy one.

#6 Sebastian Schaetz wrote on October 17, 2011:

I did not know about this attack vector. But this is something for experts to discuss I guess.

But I could not agree more. The dirty internals of the crypto systems must be created by specialist cryptographers. They have to provide an interface that makes it difficult to use it in a wrong way. Or even better: we should not create new crypto-systems, we should use existing, proven ones. As you mentioned already, pgp is probably the way to go for many use cases.

Leave a comment