Posted
by
Unknown Lameron Sunday July 15, 2012 @12:33PM
from the meow-meow-encryption dept.

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.

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).

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.

And that's precisely the reason why encryption is not used. It's not as if there are no perfectly viable solutions out there.

What people don't want to do is manage the trust - if they even have enough clue about encryption. You could tell them their data is encrypted in the cloud and they wouldn't know the difference between somebody else enrypting it for them and them doing it themselves.

If encryption and the necessary trust mangement was easy, people would be doing it already.

If encryption and the necessary trust mangement was easy, people would be doing it already.

The problem is that traditional threat models are not appropriate for personal communications. Most people are not dealing with a determined, organized, and well-funded adversary. For personal communication, we need security against mass wiretapping systems, not security against targeted attacks (which is what banks need), and that threat is nothing close to the kind of threat that would lead most people to verify key fingerprints or use an email client with PGP support.

Cryptosystems need to be designed with these things in mind: people are going to do silly things with their secret keys (both in trying to synchronize keys between devices and in having lots of secret keys across their devices), people are not going to take the time to verify keys, and people are not going to refuse to communicate because a key was not verified. The cryptosystems of the future need to give people reliable security under those constraints. It needs to be better than Hushmail (one compromised server should not lead to a complete system compromise), even if it cannot protect against a targeted attack.

We also face a secondary problem: it is hard to get people to move to a new protocol. People are not going to stop using Facebook, Gchat, etc.; if we want to give people cryptography, we need to find a way to get it to piggyback on those systems without the cooperation of companies like Google and Facebook (because they have every reason not to cooperate).

Nobody says this is easy. These are big problems that need to be researched and solved.