30 August 2013

Worse than useless

Ever since we announced that we would be concentrating exclusively on Firestorm and ending work on Phoenix, back in 2011, there's been one group of users who have been complaining loud and long: users of the OTR instant message encryption facility. They've been demanding we port it to Firestorm ever since that day and refusing to migrate until we do.

There's one major problem: OTR, as implemented in Phoenix, is worse than useless. That's because there's a major flaw in how it handles the encryption key exchange: it does it in-band, over the same channel that's about to be encrypted. There's no reason to believe that LL didn't crack it within hours of it being released.

(There's another, smaller problem: The code itself is, to put it bluntly, unreadable crap. That can be cleaned up, though.)

Cryptography is incredibly hard to get right, and incredibly easy to almost get right. The difference is that almost right is worse than no encryption at all. It gives the users a false sense of security, so that they say things over the supposedly secured channel that they would not say if they knew it was insecure.

The OTR code in Phoenix is almost right. Because of the flaw in the way it handles the key exchange, anyone who can listen to the traffic can simply snag the key as it floats by and use it to decrypt the messages, undetectably.

There are well-designed protocols to handle key exchanges and the like, as well as well-designed cryptosystems that, when properly implemented, can provide reasonable security against real-time eavesdropping. Cinder Roxley is working on implementing such a system in Firestorm, to serve the folks who think they need to encrypt their messages. This is harder than it looks, because there are a couple of constraints that don't apply to the usual case. Not only do we need to make it work without using some sort of central service, but we also need to do it without revealing the user's IP address to his intended communication partner, which a direct key exchange would do. The problem's not insoluble, but it's not easy, either.

I don't know why people think they need to hide their IM traffic from LL. Really, now. If you don't trust LL, then why are you using SL in the first place? Use some other way of getting your messages through that don't involve a third party. Some folks argue that everyone should encrypt everything as a matter of course both to confound those who would look for encrypted traffic (usually, this is immediately followed by a rant against the surveillance state) and to remove the stigma associated with encryption. I'm not entirely unsympathetic to such an argument, but it smacks of paranoia.

Personally, I think the people complaining about a lack of OTR in Firestorm need to get a life, and assess the true risks of interception are, and the costs of having their traffic monitored by LL or others. Fundamentally, such an analysis would reveal a much simpler reason that neither LL nor anyone else is monitoring what they say: they just don't care. They've got much better things to do than listen in on your steamy gay furry BDSM scene. (And if that's truly what you're worried about, how about embracing it and being proud of it instead?)

We'll do OTR, or something secure, in Firestorm soon enough...but the kind of complaints we've been hearing are just simply out of proportion.


  1. "That's because there's a major flaw in how it handles the encryption key exchange: it does it in-band, over the same channel that's about to be encrypted."

    That would be true if OTR was a single-key based encryption system. If that was the case, I would certainly agree that it wouldn't be suitable for Second Life chat, or any other form of communication that goes over a 3rd party network.

    OTR however is a two-key, or public-key based encryption system. Every message requires one key to encrypt it, and a second, different key to decrypt it. These are known respectively as public and private keys. These two keys go hand and hand, and are generated at the same time. They may be generated seldomly and used over and over again (as is the case for SSL/TLS and PGP), or they may be generated frequently, every conversation (as is the case for OTR.) Private keys must be carefully guarded, but public keys can be freely sent across any communications medium, plastered onto billboards, printed on buisness cards... or sent through Second Life.

    For example: Jack decides he wants to send a message to Jill. Jack receives a public key from Jill. Jack encrypts his message with Jill's public key. Once this message is encrypted, the public key can NOT be used to decrypt it. Therefore it is of no consequence that this key may have been seen by someone else. Jack sends his encrypted message to Jill. Only then can Jill decode the message, with her private key that she never exposed to anyone else.

    Public-key cryptography is designed to be used safely over the same band that actual communication is taking place. There's no reason to believe LL could possibly crack it.

  2. Funnily enough, with what Ed Snowden has revealed, it seems that the GCHQ and the NSA have been monitoring our SL since the beginning. I'm inclined to think they really wanted to peep on exactly the kind of action you describe at the end of your post.