Report from HOPE: Cryptocat And Encryption in the Cloud 29
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.
Some existing solutions: (Score:2, Informative)
Anyone interested in "secure cloud storage" should check out Tahoe-LAFS. First and foremost, its a redundant "grid" storage system - files split into redundant, error-correction-coded shares, encrypted on the peer end, and then uploaded to one or more other peers. So depending on how redundant you want your data to be, an individual file can survive one or more shares being inaccessible. The files are also secured with capabilities, determined and encoded on the originating peer's end. Destination peers have no way to know what a share contains unless some gave the peer operator a capability.
It works nicely. Only bad part is that all peers intermediate through an "introducer" so it is a central failure point. But switching to a different introducer is possible and doesn't affect retrieval of shares.
Another thing that can be done: rent a Linux VPS, run iSCSI Enterprise Target on it, and use your operating system's iSCSI client to mount it as a SCSI device. Then encrypt it on YOUR end with Truecrypt. VPS never sees unencrypted data.
Re:It won't last... (Score:2, Informative)
gosh people that don't know one bit of what they're talking about love to give negative advice, as if that's not equally as negligent. honestly looking at these comments, i'm thinking the mass of smug uncritically-thinking naysayers are part of the reason crypto adoption is so far behind. sorry to burst your bubble, but by eschewing cryptography and keeping all your "important stuff" safe through other (read: onerous) means (mind-masturbating about air-gaps and "unbreakable" one-time-pads), you're shooting yourself in the foot and greatly reducing the scope of what you're keeping safe.
1. quantum cryptography, which has nothing to do with quantum computing, is marketing garbage. at best it only replaces a D-H key exchange. if you're willing to invest in capital infrastructure, why don't you just *courier* a physical key between sites *once*!?
2. quantum computing is not known to break all NP problems in polynomnial time. Shor's algorithm (and its DLOG analog) rely heavily on the fact that these problems have structure (they are *not* NP-complete) by using a quantum fourier transform. and note that this is just a break of the two widely used *public* key algorothms and has nothing to do with private key ciphers.
sigh.