Web Encryption Framework

Last year danigm, which is a good friend of mine told me about this new project he was going to undertake, that he will present to CUSL (Free Software University Contest). It’s GECO (Password Manager), which will allow you to store your passwords online so that you can sync them in different computers.

Of course, storing all your passwords must be done in a very secure way if you don’t like surprises. The connection with the server must be secure (SSL?) so that no one else can see your passwords. But what’s more, are you going to upload your passwords in clear? No way buddy, that’s too risky. I wouldn’t trust all my passwords not even to my best friend, and even if so, what if the server gets compromised?

So the thing is, GECO is designed to have both a web and desktop client. The problem here is that current web browsers like Firefox don’t provide a standard framework to cipher and decipher data on the client. You’ve got SSL, but that only ciphers communications with the server, and that doesn’t solve the problem.

So what did my friend danigm do? He will be using Slow AES, a free software implementation of AES both in Javascript and python. Because he not only needs to be able to cipher and decipher text in the client via Javascript, but he also needs to ensure that when he uses the gnome desktop client developed in python, exactly the same AES algorithm implementation is used, so that what is ciphered using the web client can be deciphered in the desktop client and vice-versa.

The penalty of this is that this AES implementation is, as it name shows, slow. That’s not much a problem for ciphering small text strings like passwords. But I’m using his project as an example of what I think is coming next in the future. Because web applications are becoming common in our daily Internet life. There’s Gmail for example, which is an astonishing piece of software, and I’m tempted of using it replacing the good old KMail, but there’s one big feature that I’m missing: GPG.

I’ve tried the GPG Firefox plugin for Gmail, but it doesn’t work very well and besides, it doesn’t in other web browsers, like our all times favourite Konqueror. I’ve even used sometimes the Gtalk chat Gmail’s feature, which connects via Jabber to my IM contacts but also with my email contacts that use Gmail, which is handy sometimes, but being me an avid user of Kopete’s OTR plugin, I miss the security it provides. Finally, there are also some web services which provide online data
storage, an online hard disk if you want to name it like that. Google itself seems to be playing with idea of launching the Google Drive. Storing more
and more data online will make yourself much more exposed to potential privacy loss risk unless they are stored encrypted.

As a consequence, I think SSL is not enough any-more as a way to protect your privacy online: we need a comprehensive, well-designed framework for encrypting and decrypting data in the web browser. The next question is, then, how should be such a framework?

I have some ideas about that too: it should use standard implementations of well-known algorithms, like GPG and RSA. Probably a Javacript binding of lybcrypto should be fine. But we need also a way to ensure users that the clear data is not going anywhere else, meaning that the Javascript code is not playing tricks like copying the clear data and sending it to the web server, and the web server will only get the ciphered data and not in clear.

Now, there’s no easy way to solve that. In order to accomplish that last point we need to isolate the part of the page that deals with the ciphered data from the part of the page which deals with the clear data, creating a software jail for the later. The idea is having special html tags or tags with special attributes, which:

  1. Can be stylized using css (remember? it’ not 1999 anymore)
  2. Ciphered data can be processed securely and transparently in the web browser without compromising its security.

So normal Javascript code would see this data ciphered, and would be able to communicate with the server via usual ways: either sending a form via POST/GET or using AJAX. In the other hand, the Javascript code that deals with the encrypted data would see the data in the clear, but would not be allowed to communicate
with anyone, to send the data anywhere. That code is in jail. And for various purposes like updating the encrypted data, some information would be allowed to flow from the normal Javascript code to the jailed Javascript code, but not in the opposite direction; information would flow only in one way: from insecure code to secure code, not compromising security.

Of course, if such framework gets developed, standardised and deployed in most web browsers, even then some sites won’t make use of it at least for a long time. It’s not in Google’s best interest to let you cipher easily your email and IM conversations if they want to be able to show contextual ads, for example. But other services like GECO, or other kind of services we can’t even think of yet, will surely make good use of such a framework, and that’s the idea. I think the potential use of a Web Encryption Framework (or WEF for friends) is not only in common-place web applications and web services, but also in business web applications where security is a must.

Don’t get me wrong, I haven’t thought the actual details of this proposal. What you see here is all I’ve got at the moment. This is only one idea that I wanted to write about so that you people tell me what do you think about it, so now it’s your turn.

11 Responses to “Web Encryption Framework”

  1. 1 Elias P. enero 23, 2009 de 12:17 am

    This framework seems to be exactly what I’ve been looking for since a long time!
    Thanks a lot!

    Regards, Elias P.

  2. 2 J. Félix Ontañón enero 23, 2009 de 12:24 am

    Doesn’t libnss and libnspr4 implement cryptographic functions for the mozilla/firefox/iceweasel/netscape(rip) browser?

    In my humble opinion, GECO implements a great concept: online-password-contaner! Let’s see what the future bring us.

  3. 3 danigm enero 23, 2009 de 12:36 am

    Know a lot of our data is in the web and we don’t care about who can read it, I think that’s is a great idea and today or tomorrow we must implement some like this.

    It’s great publish blog and public information, videos, photos, etc, but there are private data that we are “publishing” in others webs that we can’t control. It’s needed to cipher all private data because google mustn’t be able to read it.

  4. 4 edulix enero 23, 2009 de 12:46 am

    To Felix Ontañon: Gecko is not the web rendering engine out there, and of course as you can tell by the name of them, those two are only libraries and their use as you say is not a web standard (think of W3C). Also, they don’t provide any secure system like the “Javacript jail” to ensure that clear data is not being leaked as far as I can tell.

  5. 5 Nael M. enero 23, 2009 de 2:38 am

    Just as an FYI, but you forgot to close an HTML tag in this entry – now everything after your entry on Planet KDE is in italics!

  6. 6 PP enero 23, 2009 de 3:08 am

    Clipperz (www.clipperz.com) do have such a framework, and it’s AGPL v3.

  7. 7 Doesn't understand enero 23, 2009 de 4:33 am

    “There’s Gmail for example, which is an astonishing piece of software”

    Umm. First mass-produced webmail to use an AJAX interface. That’s about it. And the one-mailbox Labels paradigm becomes a right pain over time. Wait until you get >100,000 emails in your account.

  8. 8 Christoph enero 23, 2009 de 12:23 pm

    Please close the <em>

  9. 9 Marco Barulli enero 23, 2009 de 5:19 pm

    Hi all,

    this is what we have been building at Clipperz for 3 years!

    Clipperz is an online password manager, but also a Javascript library of cryptographic primitives (AES, SHA2, Fortuna PRNG, SRP, …). All the code is AGPL3 licensed. And everyone is welcome to join our efforts!

    You can read more about our crypto library here:

    or about our ambitious project of building a suite of zero-knowledge web apps:


  10. 10 What about a Java applet? enero 26, 2009 de 2:12 pm

    Just my 2 cents, but is it not possible to do something with a java applet?

    – Java includes all what you need to do cryptographic operations (AES, RSA, SHA1/SHA256/…, …) with good performances (certainly not as good as openssl as it doesn’t have any assembly optimisations, but faster by far than javascript)
    – applet can be signed
    – applet can communicate with javascript code in your HTML page. So you can have a applet which just do all the cryptographic computations and gives the result to your javascript code.
    – should be compatible with all recent browsers able to launch java applets.
    – and modern JVM (1.6+) start faster than before

    Well to me it may be a valid approach.

  1. 1 The Server in the middle problem and solution « Edulix Trackback en enero 8, 2012 de 5:25 pm


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: