Report from HOPE: Cryptocat And Encryption in the Cloud

In a world increasingly dominated by the cloud, privacy is often sacrificed for convenience. Imagine a world where you could use cloud services without allowing the provider to read your data. Author of Cryptocat (a browser-based secure chat system) Nadim Kobeissi shared the problems he faced developing Cryptocat, his solutions, and future of client-side cryptography. Read on for more.

Update: 07/18 03:48 GMT by U L : Slides (PDF) from and video of the talk are now online.

Despite giving workshops on Off- the-Record messaging to Middle Eastern Activists, Kobeissi found that adoption was low because of the complexity of installing new chat software, plugins, generating keys, verifying your friends, etc. Especially when the person on the other end had not been taught how to use OTR. At the end of the talk he gave some reasons why North American users may find it easier: we develop this software and export it so we have a community of developers available for support, whereas in the Middle East this is foreign software lacking context.

Since he was interested in client-side cryptography and there was a clear problem getting people to securely communicate, he set out to experiment with the former while solving the latter. He identified several problems thwarting success:

• Code delivery is insecure (will it be intercepted and modified? Can you trust the original server?). Compounding this, code in browsers is ephemeral, making it nigh impossible to trust.
• The JavaScript random number generator, while fine for most uses, is not good enough for encryption (its only seed is the current time, making it vulnerable to attack).
• There are no standardized primitives for working with cryptography algorithms in JavaScript, and libraries available at the time were not very good.
• Browser sandboxing was often incomplete and exploitable (a situation which has improved, but new bugs are still occasionally found). If the sandbox breaks, all bets are off.

To each problem there is a solution. For code delivery, Chrome apps proved ideal. There are interesting client side security features, bundles can be signed, sandboxing is effective (aside from the occasional convoluted exploit), and you only have to verify the source once. For encryption, he developed his own implementation of the Fortuna CSPRNG and several cryptography primitives in JavaScript, using keypress timing, mouse movement, window position, etc. for entropy (on mobile devices, the accelerometer has proven useful). Chrome later added their own implementation (which has access to the system entropy source) with Firefox support coming soon.

But where to go from here?

We need an API for transparent encryption: it should be as enforceable and easy as https. We need a full crypto toolkit in the browser, protected key storage (the author suggested protected JavaScript variables), OpenSSL compatibility (certificate formats, not the horrendous C API). And we need secure communications usable by mere mortals.

The W3C formed a web cryptography working group six months ago, with a specification due in 18 months.

Working with the Guardian project, the Cryptocat developers hope to introduce AweSoMe (always secure messaging), which aims to build a suite of utilities for easy and secure messaging (guaranteed message delivery, verifiable end-to-end encryption, and control over logging).

Development of Cryptocat2 is in progress, using XMPP rather than their experimental protocol, and mpOTR which extends OTR with group chat features and newer ciphers. The specification is half complete, and contributions were encouraged.

Although secure chat for the masses is being worked on, there is still much work to be done on securely storing data in the cloud. Luckily, the lessons learned developing Cryptocat will apply to future projects.

This is what my final career project was about

[Edulix]

The problem is that web is server centric. You always connect to a server. It's not just that someone might be listening your conversations (i.e. potential man in the middle); it's that the server is ALWAYS there. That's what I call the "server in the middle" problem, whose solution is of course end-to-end encryption, and that's what my final career CS project was about. I implemented a simple extension for HTML5 in KHTML that allowed you to use your GPG keyring to sign, encrypt and decrypt message, with full support implemented in the browser. This was done two years ago and I also did a small presentation about this at Google office in Spain, though they were not very interested on it (their business model is to be the server in the middle, so no surprise here). Of course you cannot trust the Javascript code given by the server, because that breaks the security chain. You cannot trust the server in the middle for anything. You should trust only the browser (otherwise you're fucked anyway, which you well might be). Every bit of security should be implemented in the browser and not in Javascript, even the presentation layer (this is what I did, albeit only for very simple text messages). But then that would limit the possibilities: that can work for very simple text applications, but if you want to show smileys, rich text, images, jquery sugar, etc then.. you can't do that. If you want to implement an end-to-end "google spreadsheet" you won't be able to do that with presentation done completely by the browser, you need to trust the code of the web page. Of course google chrome plugins signed by google would work, but then you're trusting google (and not Fedora for example) and you're not using just standards on the web, you're requiring one specific web browser. We could go for an end-to-end security basic extensible standard with an increasing list of extensions supported more or less by mainstream browsers. That's one of the possible solutions, but I'm sure there will be better proposals.

Re:It won't last...

[betterunixthanunix]

Not entirely true, algorithms like AES do not have a high enough security margin. Also, you cannot just change the key length, even if the algorithm specification would allow that (like e.g. Blowfish does), because whatever change you make needs to be cryptanalyzed first. The same for other changes like multiple encryption, etc.

Sure, but a 256 bit keys is high enough margin for many decades even if scalable quantum computers became feasible. AES256 has problems, but we have alternatives; as far as I know, 256 bit Serpent does not have the same problems as AES256. In any case, this is a minor problem to solve: use Serpent or Twofish or some other algorithm before uploading your data. It is not as though we need to fundamentally alter how we approach cryptography.

So how many "cloud" service providers use them? Answer: Zero.

It's worse than that: we are not even taking steps toward deploying these algorithms. One issue is that Regev's system (and related) require much larger keys, which would increase the load on many systems, and we are currently trying to decrease the expense of crypto deployment. I remember seeing a presentation at CRYPTO last year that showed that McEliece could be as efficient as some EC algorithms, but I do not recall the specifics.

More troubling is that the OpenPGP standard is not being amended to include McEliece or Regev, despite having recently been amended to include EC algorithms. There is no need to panic here, though, as quantum computing is still an extremely remote and highly speculative threat.

Only insofar as the the public sector is concerned. It not unreasonable to assume that intelligence agencies of larger countries are 10-20 years ahead.

I do not think QC is 10-20 years away; I would place it at 100 years away, barring some unprecedented sequence of breakthroughs in science and engineering. Even if intelligence agencies have scalable quantum computers, the likelihood that such expensive resources would be used for a mass wiretapping program or for anything less than spying on other intelligence agencies is pretty low. There are plenty of other attack vectors that can be used: bad RNGs, bad opsec (e.g. someone forgetting to encrypt a message that quotes an encrypted message), side channels, traffic analysis, undercover agents, etc.

Sorry, I don't want to be fear-mongering, but there is a point to the claim that if you put your data into the cloud now, it might be decryptable in ten years from now.

Ten years is pretty short for something like AES128. Thirty years is reasonable, or if you are optimistic, fifty years. Even in thirty years, the resources that will be required to perform a ciphertext-only attack on AES128 will be immense, so I doubt most people will face such an attack. Even the most tyrannical, authoritarian government would be hard-pressed to use an AES-breaking system for anything other than a targeted attack thirty years from now -- there are too many messages to attack them all in any useful timeframe.

It's not that I mean to say that some healthy paranoia is a bad thing -- this is crypto, we should assume our adversary is powerful. We do need to assign at least some bounds to the adversary's power, though, or else we are never going to get anything better than a one time pad. You can argue that there is a possibility that any key size will be insecure in 30 years, but then what will you do if you need to send a message that needs to be secret 30 years from now? One time pads have limited real-world utility, especially for personal communications (it is also unclear if 30 year security is even needed there, or what sort of threat model personal communications should have).