Image of the glider from the Game of Life by John Conway
Skip to content

Setting The Standards Bar

One of the things that I hate about instant messaging clients is the lack of adherence to standards. In fact, the specification that I think should be adhered to the most, isn't. I've blogged about this before, so I apologize to the planets that I am syndicated to in advance for duplicating content. However, due to the recent poll about which IM client you use, I've setup another.

In the last poll
, the top 5 Linux clients that are currently in operation are, as a result of my poll, in order from most used to least:

  1. Gaim
  2. Kopete
  3. Gajim
  4. Gossip
  5. aMSN

I look at those clients, and recognize that there isn't a single standard between any two of them for encrypting your messages. There are just too many options:

  • gaim-encryption: Only works with Gaim, or clients implementing the Gaim code.
  • otr: a good alternative, working with Gaim, Adium for Mac and Trillian for Windows, but not available for other clients.
  • otr-proxy: probably a better alternative than it's parent, allowing any IM client that can utilize a proxy access. However, at the moment, it only works for AIM and ICQ protocols, alienating many users.
  • GnuPG: In my opinion, the best alternative using your personal GnuPG keypair, but, only implemented in Gajim and Psi.

I'm sure there are other options, but I think the point is made. I should be able to choose any IM client, and encrypt my traffic with a standard spec that is implemented across the table, regardless of which client my friends choose.

As mentioned, I personally favor using my private and public GnuPG keypair. To me, that just makes sense. Why keep track of two keys, one for IM, and the other for everything else? But, I would be willing to see otr or otr-proxy as the standard as well. The point is just setting the standard, then implementing it across clients.

As such, here is another poll. Should an encryption standard be set, regardless of IM client or protocol, given the information that I outlined here?

I should mention that I use Jabber as my means of IM communication. Jabber, by default, implements SSL/TLS. So, my traffic is already incrypted on the wire with my friends. However, can I trust that the Jabber server I or my friends connect to are not decrypting and logging the chat sessions? Something to think about.

Should there be a starndard encryption process among IM clients?
View Results

{ 14 } Comments

  1. textshell | February 21, 2007 at 8:25 am | Permalink

    I think it's wrong to have a encryption standard that ignores the used protocol. At least in jabber encryption should work at the xml stream level, that's something that the closed protocols just can't do properly.
    I think what is really needed to have clients that support the agreed upon encryption of the protocol in use. If there is no such thing the relevant client authors should get together and do a specification for it. For jabber the XMPP Standards Foundation has at least on protocol specified (gnupg based) and it's will be possible to get OTR usage in jabber and things like that properly done too.
    For the rest of the protocols it might be better to just define a common crypto over simple messages protocol by the thirdparty client authors. they might be similar enough to share a standard.

  2. Steve | February 21, 2007 at 8:31 am | Permalink

    I know Kopete has a plug-in for GPG encryption, but I'm not I've used it. I have done encrypted Jabber between a pair of Psi clients. Unfortunately there does not be a way to check if the person at the other end will be able to decode the message. You may have their public key, but they may not have encryption set up on their IM client.

  3. Hans | February 21, 2007 at 9:26 am | Permalink

    Encryption definitely should be done in the framework of the protocol. But that doesn't mean there can't be an umbrella standard that is implemented in a protocol-aware way for each protocol.

    I agree that gpg would be ideal, but I'm perfectly happy with the way OTR works too. Any public/private key thing works, the primary advantage to GPG is sharing the web of trust.

  4. David | February 21, 2007 at 9:36 am | Permalink

    Rather than standardize the encryption, doesn't it make more sense to have a standard way for IM's (and possibly other programs) to share (multiple encryption plugins? That way the plugins and the IM's can develop indpendently with only a common API that everyone needs to write to. Something very simple that is fed a block of clear text and returns crypt and vice versa. IM people don't have the think crypto, crypto people don't have to think IM and anyone who wants to is free to think about both together...

  5. Aaron | February 21, 2007 at 11:11 am | Permalink

    textshell- The only problem is the servers decrypting and storing your chat sessions. This is a problem with Gmail.

    Steve- I think this is the #1 reason why the Gaim devs have not implemented PGP/GPG into their client. It is difficult to know whether or not they are who they say they are, and with generating keys just for IM, this could pose a problem. But, I think the majority of us know who we are chatting with, and there is something to be said for common sense.

    Hans- Rather than in the protocol, the spec needs to be implemented in the client, keeping servers from decrypting and logging your chats.

    David- This is a good point. Standardizing the plugin capability makes sense. However, each plugin creates and utilizes keys differently, so a standard would need to be set to make the keys the same and behave properly, and this brings us to either GnuPG or using a common plugin, rather than several.

  6. astrophoenix | February 21, 2007 at 11:54 am | Permalink

    I routinely use gpg in kopete to encrypt IM over a jabber server. unfortunately, it doesn't seem to work reliably over google's jabber server. but it works fine on the jabber server we run at work.

  7. Kyle Brantley | February 21, 2007 at 12:35 pm | Permalink

    Kopete has a plugin that ships with it which does just that: GPG keyring encryption, based on who you're sending it to.

    The biggest problem with using this is how many times larger the ciphertext is than the plain text, and not many servers enjoy passing a few KB/sec between two people.

  8. Aaron | February 21, 2007 at 12:40 pm | Permalink

    Kyle- Yeah. I just came aware of Kopete and the GnuPG encryption capability that they have built in.

    Pretty cool.

    This means, as far as I know, Gajim, Psi and Kopete can interoperate securely with GnuPG.

    As far as the servers handling the few extra bytes, big deal. We're talking a couple extra grains of sand on the beach.

  9. Peter Saint-Andre | February 21, 2007 at 12:44 pm | Permalink

    PGP is great for geeks but not for Aunt Tillie, who doesn't have a public key and never will. OTR is great for Aunt Tillie (if presented in a friendly way) because it uses opportunistic encryption, but it encrypts only the message body. In the Jabber world we'd like to encrypt the complete packet, not just the message body, so we can do things like encrypt the packets we use to set up voice calls (you don't want your IP address exposed, do you?). We have an emerging XMPP standard for end-to-end encryption (similar to OTR but it encrypts the entire packet) and we will be putting a lot of effort into that over the next year or so. It won't work for AIM/MSN/Yahoo but then if they would just use XMPP instead of their own proprietary technologies, all would be well...

  10. Aaron | February 21, 2007 at 12:58 pm | Permalink

    Peter- I agree and I don't agree. First, I agree that Aunt Tillie will most likely use OTR or some other 3rd-party plugin that will be easy to install.

    But I don't agree that Aunt Tillie won't implement PGP/GPG. If she is using IM, and is concerned about her security, and even knows about encryption, it's a non-issue for her generating a keypair.

    Also, about encrypting the whole packet, I agree. Just the text is not enough. I would much rather see the whole packet encrypted. However, we need options for more than just Jabber users. This is a start.

  11. Peter Saint-Andre | February 21, 2007 at 1:08 pm | Permalink

    Does anyone have an aunt who uses OpenPGP? Most IETF standards weenies don't even use it (or S/MIME), and they are the geekiest of the geeky. As far as I can see, OpenPGP is a non-starter for regular end users. I wish it weren't so.

    And if you'll excuse me, now I need to write my talk about Jabber security to be presented on Sunday at FOSDEM 2007 in Brussels... 🙂

  12. Aaron | February 21, 2007 at 1:13 pm | Permalink

    Peter- I don't even have an aunt that uses IM, let alone, concerned about her security.

    From my experience, the #1 reason no one uses it, is they are caught unaware with what they can do with it. If it's not that, then they are too lazy to take the 5 minutes time to set it up. I have no tolerance for laziness. Just do it.

    Good luck on your presentation.

  13. textshell | February 21, 2007 at 1:40 pm | Permalink

    In jabber you always know if the other person will be able to decode it, because proper gnupg usage in jabber includes signing the presence. I think the newer session based encryption standard as comparable assurance. (yes, that's all xmpp specific)

    @Hans, David
    puting a layer of abstraction and/or a plugin system between the instant messanger part and the crypto part could be done. But i think you can't thread all system equally, because there are a lot of differences, like jabber supports signed presence and announcing capabilities in the presence.

    there are 2 ways encryption can be specified in standards. xmpp has both client-to-server (that's where the server can decrypt the session) and client-to-client crypto support. if a client/user uses client-to-client encryption there is nothing the server can do to decrypt the chat session. I can only log encrypted "garbage".
    So "in the protocol" only means specified in an protocol specific way, it doesn't mean it's something server side.

  14. Aaron | February 21, 2007 at 2:04 pm | Permalink

    Peter- However, I should mention that if the end-to-end encryption spec is realized, that will be good news for Jabber. Seeing as though it's the only protocol that I use for my encryption, then it'll be the exact "standard" that I'm looking for. I'm eager to see it's progress.

Post a Comment

Your email is never published nor shared.