Esessions redux

I have quite a few projects that are still in a “pending” state that I’ve been thinking about. I’d like to get my project queue cleared so I can stop worrying about things that haven’t been done. That said, I’m going to throw out some comments/thoughts I’ve had about Esessions and hopefully get some discussion going. Note that I’ve enabled comments on this particular posting, so feedback is welcome.

One of the primary issues that has been conveyed to me on a number of occasions is that fact that Esessions does not support messages getting stored offline. Well, that’s by design, as I simply “Jabberized” the mechanisms and concepts in SSH, and SSH was never meant to be stored “offline”. Storing messages offline in a secure manner that does not require some level of server trust is either computationally more expensive than Esessions or, at the other extreme, very insecure.

One of the key values that Esession brings to the Jabber/XMPP world is that it minimizes the number of redundant patterns within the context of a session. It does this by using ZLib compression on messages prior to encrypting. Given the amount of redundant data in most Jabber messages (all those XML element names/attributes) this means a significant savings in overall encrypted packet size and a dramatic reduction of patterns, across the entire stream, suitable for key attacks by Mallory. The downside to using compression, of course, is that it requires both sides to have perfectly synchronized compression/decompression state machines. This means that messages which get stored offline will not be usable if the recipient’s client doesn’t have the correct decompression state machine. Herein lies one of the primary reasons that Esessions is simply not usable in conjunction with offline message storage.

Now, the obvious “answer” to the above problem is to remove the requirement for compression. It must be understood that taking this course of action will weaken the overall system from a cryptographic standpoint (since we’re now sending mass amounts of duplicate data across the stream) . In addition, removing compression would cause the Esession protocol to require significantly more bandwidth. As it stands now, my back-of-the-envelope calculations indicate that using Esessions would add no more than 5% overhead to a raw, unencrypted packet – removing compression could easily result in Esession adding 100-200% overhead to each packet!

Is having the ability to send someone encrypted offline messages worth that kind of overhead? I don’t know, but it sure does seem like the wrong way to go about providing end-to-end security.

In addition to bandwidth efficiency, Esessions (and SSH, for that matter) is also cryptographically/computationaly efficient, for the level of security that it provides, thanks to the fact that public/private key operations (the most expensive crypto ops) are only used when negotiating the intial Diffie-Hellman (DH) values. Once the DH values are derived, encryption/decryption uses a pure symmetric cipher (such as Blowfish or Rijandel/AES). This approach allows multiple messages between two users to reuse all the crypto context (i.e. DH negotiations, message integrity checks, etc.) for ongoing encryption. Compare this to your typical PGP/GPG encrypted message (ala JEP 27) where each message requires the client to generate new encryption keys, encrypt the keys with PKI, generate a signature for the overall message and ship the whole thing off to the other side. That’s a lot of work for each message!

562 Words

2004-06-23 00:00 +0000