GSoC Finis: Advice on Implementing ESessions

(I've written about the non-technical aspect of my work this summer previously.)

It took me 3 or 4 weeks to get a basic, functioning XEP-0217 implementation. You can probably do this much faster; you have an existing implementation to look at*, and you don't have to write a general-purpose test suite at the same time.

* (the test suite is under the MIT license; if that's too restrictive for you, I'd be happy to release it under something else)

Follow XEP-0218

When I wrote my SoC application I spent a lot of time thinking about the proper order to implement things in. XEP-0218 answers that question for you, and gives a good overview of the various specs involved.

Choose a good crypto library

There's probably at least one for whatever language you're working in. The minimum needed to implement XEP-0217:

• a cryptographically strong pseudo-random number generator
• HMAC
• SHA256
• AES-128 (CTR mode)

Good documentation is always a plus.

XEP-0116's only mandatory difference from XEP-0217 is RSA public key signatures and verification. XEP-0116's Mandatory to Implement Technologies gives an overview of what other options are available.

I ended up using the Python Cryptography Toolkit. It doesn't support some of XEP-0116's options (the Twofish and Serpent ciphers and the Whirlpool hash algorithm), but I've been happy with it otherwise.

Sessions :(

Easily the trickiest part was getting XEP-0201 sessions working with Gajim's existing architecture. Sessions are an integral part of XMPP—<thread/> is one of the basic elements provided in the XMPP IM RFC—but there's little (if any) support for them.

My implementation isn't great; Gajim can only have one session between two Full JIDs at a time, and will silently drop an existing session if the remote client starts a new one. To do it any other way would have required a massive refactoring of Gajim's message handling.

This is a bug, it only works because no other clients (that I'm aware of) have any support for sessions, and it will probably poison the well and make it more difficult for other clients to implement sessions properly. I'm not proud of it, and I will fix it if I can manage the refactoring required to do it properly.

I have no advice here; if your client wasn't designed with client-to-client sessions from the beginning, they will probably cause you pain. Hack through it.

Use my test suite

I've found it very useful, as an autoresponding dummy to test the basics against, and as an actual test suite to verify compliance. Documentation is on the way.

Don't let the crypto scare you

You don't need to be a cryptography expert. The specs are very complete, and will guide you around most security pitfalls. As long as you have a general idea of how the whole thing works and what you need to avoid exposing, you'll be fine. It's fun stuff!