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.

Comments

OTR is as easy to use as HTTPS

[betterunixthanunix]

I see OTR from plenty of Adium users (most of whom has no idea what it is or that they are even using it), and it is installed by default in some GNU/Linux distributions. The biggest issue with OTR is that it still lacks group chat, and SILC is far more annoying to use (distributing a shared key to everyone, or else getting your key from the server?). It would also be nice if OTR displayed a warning if a person's key fingerprint changed; not everyone is willing to take the time to verify keys (this has the downside of annoying people who use multiple devices, but we do not have any good / easy way to synchronize keys).

Encryption via web apps is always a problem. It makes Hushmail insecure, and it makes cryptocat insecure.

Re:OTR is as easy to use as HTTPS

[Anonymous Coward]

I think nowadays OTR will say "contacting you from a new computer" instead of just "unverified" if a fingerprint changes.

And yes, OTR is a good example of opportunistic, transparent encryption.

Re:OTR is as easy to use as HTTPS

[Anonymous Coward]

The problem I've had with OTR is reliability. It seems like 90%, maybe 95% of the messages get through, but the remainder just disappear with no indication whatsoever that they didn't work. Disabling OTR makes the problem go away.

I'm not the only one with that problem. I've recommended OTR to friends who've had the same experience. Until that is sorted it's hard to keep recommending OTR to people.

My preferred form of data protection:

[kheldan]

An air-gap between the data and any Internet-connected device.

Re:My preferred form of data protection:

[MobileTatsu-NJG]

So... wifi?

Re:My preferred form of data protection:

[kheldan]

Actually I print it all out onto paper tape which then gets sealed in an environmentally-controlled container which is then stored in an underground bunker with a nuclear auto-destruct mechanism against any possible intrusion.

Re:My preferred form of data protection:

[lennier]

Actually I print it all out onto paper tape which then gets sealed in an environmentally-controlled container which is then stored in an underground bunker with a nuclear auto-destruct mechanism against any possible intrusion.

I've seen that movie. It turned out well.

It won't last...

[Anonymous Coward]

Remember, with technologies such as practical quantum cryptography on the horizon, any data you store encrypted in "the cloud" won't stay that way encrypted forever.

It might take 10 years, it might take 20 years, but eventually what you thought was safe from prying eyes is likely to be revealed for all to see (or at least to those who can afford the new encryption-cracking tech).

Re:It won't last...

[Anonymous Coward]

"Remember, with technologies such as practical quantum cryptography on the horizon, any data you store encrypted in "the cloud" won't stay that way encrypted forever.

It might take 10 years, it might take 20 years, but eventually what you thought was safe from prying eyes is likely to be revealed for all to see (or at least to those who can afford the new encryption-cracking tech)."

It also pays to remember that any data you store in or even send to the cloud is not deletable. There really is no delete button for cloud-storage.

The service providers, those who subpeona, wiretap, or steal from them are likely to have backups and archives that could last for decades, and which could be subject to cryptanalysis at their leisure.

Once your data is out there, encrypted or not, it's out of your control probably for good. And sooner or later, it will likely be cracked.

Re:It won't last...

[betterunixthanunix]

Remember, with technologies such as practical quantum cryptography on the horizon, any data you store encrypted in "the cloud" won't stay that way encrypted forever.

1. Quantum computing is the problem for crypto
2. Quantum computers are a thread to certain assymetric algorithms like RSA and ElGamal, not symmetric algorithms (aside from halving the key length, but that is solved by doubling the key length).
3. We have assymetric algorithms that resist quantum computer attacks; McEliece, Regev, etc.
4. Quantum computers are about as "on the horizon" as cold fusion. People keep talking about incremental breakthroughs, but there are big problems standing in the way.

Re:It won't last...

[PurpleAlien]

Time is always a factor in choosing the right algorithm. Security is a function of time: depending on how long you want to keep stuff secure, the price, complexity and key size increases to anticipate faster computing resources and advancements in cryptanalysis. There are various cryptographic algorithms already which will still be secure even if we have a practical quantum computer tomorrow.

Re:It won't last...

[aaaaaaargh!]

Quantum computing is the problem for crypto

Quantum computers are a thread to certain assymetric algorithms like RSA and ElGamal, not symmetric algorithms (aside from halving the key length, but that is solved by doubling the key length).

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.

We have assymetric algorithms that resist quantum computer attacks; McEliece, Regev, etc.

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

Quantum computers are about as "on the horizon" as cold fusion.

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.

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.

However, I think the real problem is the opposite, If you put your data into the cloud now, there is a good chance that you will loose it within the next ten years, because at least half of the cloud companies will go bankrupt. I still remember very well my totally free and life-long USA.NET address, which lasted about a year until the company disappeared.

Re:It won't last...

[Anonymous Coward]

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.

Re:It won't last...

[DerUberTroll]

Remember, with technologies such as practical quantum cryptography on the horizon, any data you store encrypted in "the cloud" won't stay that way encrypted forever.

It might take 10 years, it might take 20 years, but eventually what you thought was safe from prying eyes is likely to be revealed for all to see (or at least to those who can afford the new encryption-cracking tech).

Why store your stuff in the cloud? Hard drives are so inexpensive. Crypt them. Why even take a chance?

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

Re:It won't last...

[Anonymous Coward]

And by then we'll also have more powerful encryption. Quantum computing isn't magical, either.

Re:It won't last...

[Anonymous Coward]

Depends on how the data was encrypted. If it was encrypted with RSA, then quantum computers (using Shor's algorithm) will make it worthless. If it was encrypted with a 256 bit symmetric cipher like AES, then such algorithms will do nothing but cut the complexity down to 128 bits. Grover's algorithm decreases the complexity of block ciphers by the square root of the key size, (e.g. 2^n/2). 128 bits is still well beyond any technology for the foreseeable future (barring some sort of huge breakthrough in cryptanalysis).

My biggest concern with apps like CryptoCat is they are not designed by cryptographers but rather by software developers. Any app such as that needs extensive peer review by experts before it should be trusted. And using Javascript makes me nervous.

Re:It won't last...

[Anonymous Coward]

Not entirely true, algorithms like AES do not have a high enough security margin.

Who told you that?

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.

It depends on what changes are made. Schneier has suggested increasing the number of rounds of AES, as he says it is a simple change that will increase its security right now *without* having to subject it to years of new analysis. And if we're going to subject it to years of new study, we may as well just scrap it and use a new design from scratch.

But keep in mind that he is being very conservative. He admits that AES is almost certainly 100% secure when implemented properly. It's just the "security margin" isn't as high as everyone thought back in 2000 and this makes extremely paranoid people a bit nervous. Rijndael skimped on the number of rounds compared to a lot of the other finalists (like Serpent which has 32 rounds compared to Rijndael's 14 at 256 bits). But increasing the number of rounds is a way to cheaply and easily increase the security of most block ciphers without having to redesign the whole thing. The only problem is that increasing the number of rounds makes it that much slower, which is the entire reason the Rijndael designers settled on their variable round structure (10, 12, 14) depending on key size. It makes it "secure enough" but also makes it much faster than the competition. Speed and security is always a trade-off.

But if you're worried about key-size, you shouldn't be. Most every modern block cipher allows 256 bit keylengths, which is way overkill. The problem isn't the key-size but weaknesses in the cipher itself (found by cryptanalysis). You can have a crappy cipher with 800 bit keys that will be a lot more insecure than a well designed cipher with 256 bit keys. Key-size is the least of your worries.

AES has been studied more than any publicly known block cipher in history and it still is nowhere close to being *practically* broken. The best attacks have reduced AES-128 to AES-126. A great result for the mathematicians, but means very little in real life.

"privacy is often sacrificed for convenience."

[TCM]

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.

Re:"privacy is often sacrificed for convenience."

[betterunixthanunix]

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.

Re:"privacy is often sacrificed for convenience."

[Anonymous Coward]

For GChat, I feel like Adium is in a good place along that spectrum: it's the most popular stand-alone chat client for OS X (which, admittedly, still means it's not all that popular as most people who use IM use web and/or phone clients), and it has OTR built-in, so two Adium users or a Pidgin-OTR and Adium user will automatically encrypt their messages by default. Of course, the encryption could be MITM'd if the users don't take the extra step of verifying the keys... but at least now it takes an active attack instead of a passive one.

I think that seems like a good standard. Software can automatically encrypt, but it can't automatically verify (although key verification could be worked into other workflows like maybe it could be part of accepting a friend request). If some people do do the effort of verifying then MITM is risky because you might happen to do it between two users who did verify and will catch you.

Also over the past few years IM and e-mail have moved from usually being unencrypted between the server and client to usually being encrypted between the server and client. It doesn't help if you don't trust the server (and you shouldn't; they're probably setup to give information to the government) but it does reduce the attack surface.

Re:"privacy is often sacrificed for convenience."

[JoeMerchant]

If drop-dead transparent convenience isn't an issue, then you can run all manner of client-side en/decryption software.

It's not hard to do, really, if you care. Thing is, most people don't.

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.

Some existing solutions:

[Anonymous Coward]

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.

Must read article

[Anonymous Coward]

I think before even starting to approach the subject of browser cryptography, let alone comment on it, first read this article:
Javascript Cryptography Considered Harmful
It's an excellent summary of all the pitfalls, and (in my opinion) a good argument why people trying to design cryptography libraries for use in browsers should just give up and approach the problem they're trying to solve from a different angle.

The Cloud is Dead

[Anonymous Coward]

July 12--After decades of using outside contractors to manage its information
technology work, General Motors intends to bring 90% of the work in-house,

http://www.bloomberg.com/news/2012-07-12/gm-to-bring-most-information-technology-work-in-house-1-.html

As goes GM, so goes America.

This is cool, but where is the article?

[hellop2]

Where is the article where he "shared his problems developing cryptocat"?

BTW, cryptocat.com is not the correct website, but it's interesting. Does anyone know of a Linux router firmware software package that does similar automatic decryption?

Could just bring it back in house

[Drunkulus]

And thus was paved the road from the Cloud back to Earth.

I went some way towards this a couple of years ago

[akc]

I wrote a chat program for fun that addresses the problems. See https://github.com/akc42/MBChat. The software originated as a non secure chat for a fan club (www.melindasbackups.com) that I an the IT director for, but I tried to add security to it as part of a proof of concept for use where people were trying to intercept the comms.

The assumption I made is that all communication between client and server needed to be secure and that there could always be a man in the middle trying to intercept your communication. Since the initial program is downloaded from the server, it is not possible to send the keys needed to encrypt things with the program.

My solution to this was to calculate a RSA key pair on the fly in the browser as the program starts up - and then send the public key to the server and ask it to encypt the key used for communication using this public key. The client then decrypts it using his private key.

Because RSA key pair generation is quite compute intensive - I had to develop a mechanism (which I borrowed from elsewhere) to allow the browser to perform long running calculations without timing out. It does this by breaking things down into small steps and returning to browser for a "tick".

I also spent some time trying to have the server also prove it was the correct server. I came to the conclusion that the only completely foolproof way required each human client to know the "Standard message of the day" and to be able to see it after its been decrypted for the server comms to be sure the server is who you think he is.

I open sourced it when I developed it about two years ago now - but I don't think anyone has cloned it or taken a look.