Security and privacy

Clipperz is a host-proof web app

In order to avoid storing readable data on the server a host-proof web application encrypts and decrypts the data inside the browser. The keys for all encryption processes are derived from a passphrase that never gets sent to the server.

The server is limited to persisting and retrieving whatever encrypted data the browser sends it, and never actually accesses the sensitive data in its plain form. All encryption and decryption takes place inside the browser itself.

Simply said, host-proof web apps are online services that ideally should know nothing about their users. They look and behave like regular web apps, but they hide a strong Javascript cryptographic engine that runs right in the browser.

Building on this idea, we have been designing and implementing a more general architecture for “privacy aware” web applications that we like to call zero-knowledge web apps. The basic idea is to create “no trust needed” services, where users can inspect and verify anything running in the browser, where attention is drifted away from the entity providing the service to the code the application runs.

Clipperz is probably the most radical example of a host-proof web application. It even ignore usernames!

Clipperz is a single page app

The whole Clipperz application is retrieved with a single page load. HTML, JavaScript, CSS, encoded images, … are loaded into the memory of the browser before credentials are entered in the signin/signup form. Clipperz does not automatically reload during user interaction with the application, nor does transfer control to another page. This kind of web apps is usually called single page app (SPA).

“An SPA moves logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural shift has, in some circles, been coined “Thin Server Architecture” to highlight that complexity has been moved from the server to the client.”
- Wikipedia

There is a very good reason to design Clipperz as a single page app: if additional chunks of source code were downloaded from the server after the login phase, the user wouldn’t have any chance to verify the security of a web application. Therefore in Clipperz not a single line of Javascript is moved to the browser after a successful user authentication.

Clipperz uses proven cryptographic algorithms

Clipperz is built upon proven and trusted cryptographic algorithms: AES, SHA2, [Fortuna][fortuna, SRP, …

A thorough implementation of core algorithms is essential for building the Javascript crypto engine that powers any host-proof web app. In 2005 we had no choice but coding all of these primitives from scratch. No robust alternatives were available at that time. We packed them into the Clipperz Javascript Crypto Library and we are still using it since then. The library is, of course, available under a very liberal open source license.
However we are open to integrate or replace our homegrown library with other tools, a good candidate being the Stanford Crypto Library.

Cryptographic algorithms evolve over time. If necessary Clipperz can upgrade its cryptographic foundations by replacing some of the primitives (e.g.: moving to SHA3 if and when SHA2 will show exploitable weaknesses). This will happen without the user noticing it and without changes in the overall user experience.

Clipperz has a 128-bit security level

Clipperz is a cryptographic system with a 128-bit security level. This means that to be successfully attacked it will require the attacker to perform at least 2128 “steps” of some kind of work. It’s a vague definition since each step could be as simple as a table lookup or as complex as performing an involved computation task. But it’s good enough to design a strong cryptographic system.

Cryptographers agree that a 128-bit security level will be sufficient against brute-force attacks into the foreseeable future. But, of course, no aspect of a system design should be overlooked, from the choice of algorithms to usage policies.

Don’t be confused by our use of AES-256 or SHA-256. There is not a one-to-one relationship between the security level and the main parameter of a cryptographic primitive (e.g.: key size for ciphers, output size for hash functions, …). Read more about this subject..


We are not here to reinvent cryptography, we couldn’t. Nonetheless we want to shift the balance of power between web app users and web app providers in favor of the former.
We want to build web apps that brings state-of-the-art cryptography to the average user. Host-proof web apps lower the barrier to cryptography, empowering users.

“Encryption is a powerful defensive weapon for free people. It offers a technical guarantee of privacy, regardless of who is running the government … It is hard to think of a more powerful, less dangerous tool for liberty.”
– Ester Dyson

Today you can edit documents, store files, send messages and accomplish many other tasks right from the browser. Keeping your data in the cloud is just great, but what about privacy, security and ultimately freedom? It’s still your data! And you should have exclusive ownership and control! Unfortunately today you have no choice, but trust web application providers and hope they act properly.

Web cryptography could revolutionize the web ecosystem by leveraging the power of crypto code running in your browser. This approach can be applied in countless fields (OTR web chats, EMR web services, provably fair online games, …).

We want to keep contributing to web cryptography advancement, we want to help growing a a larger community of users, developers and security experts. We want to make web cryptography a valuable, flexible and secure technology for protecting data and people on the Internet.

“We realize that the web stack is never perfect, but it always catches up, and it has the broadest reach.”
Brendan Eich

That approach combined with building standards moved the web far along during the last years and we hope it will continue and it will expand to include web cryptography as well. Also because when we talk security the “broadest reach” is a crucial factor …