HTML is extremely high profile, and everybody knows enough about it to have an opinion. HTML5 is the world’s biggest bikeshed.

I’m staying far away.

Summer of Code is over. It’s been a great experience, and beats the pants off of most jobs I can imagine. I’ve met lots of interesting people and learned far more about crypto and XMPP than I would have in my spare time.

(Update: I’ve published a more technical overview.)

My Encrypted Sessions implementation is now part of Gajim’s svn trunk. What I’ve completed to date is still just a proof-of-concept. There are three areas in which my implementation is not production-ready:

• Pseudo-random number generation. I’m using Python’s os.urandom; the documentation says it “should be unpredictable enough for cryptographic applications”, but I’m not 100% certain about that.
• Identity verification interface. The dialog I’m using right now assumes that the user has done the verification, and does not prompt again during future negotiations. If you’re using public keys, they’re not verified at all.
• Shared secret storage. Retained secrets are not encrypted. This requires asking the user for a password before they can negotiate an encrypted session.

I left these things to last because they require time-consuming research. In particular, I still haven’t dealt with Gajim’s GUI much. I intend to finish this work and stick around the XMPP community—there are all kinds of interesting things left to be done with this protocol.

I did not complete everything I set out in my application. In particular, “test all MUST and SHOULD level requirements” was unrealistic (to say the least). This is the first programming project I’ve been on with a real deadline, so I was unaccustomed to making these kind of long-term estimates. I erred on the side of making my application look impressive, which was a mistake—I don’t want to be the kind of person who makes claims he can’t back up.

That said, I think the test suite is very useful in its current state, and hope that it will help pave the way for further implementations of Encrypted Sessions. I’ll publish more details about it (and technical details about implementing XEP-0116 and friends) once I’ve finished moving.

On a tangential note, blogging on a regular basis is much harder than it looks. Still, SoC has given this blog a nice PageRank boost, and it actually has some subscribers now.

Nothing exciting this week. I’ve been working on the test suite and laying the groundwork for the three-message negotiation specified in XEP-0116.

I neglected to write about my progress last week, so I’ll stick it in here. I implemented SRS (Shared Retained Secrets). The idea is that when two clients finish negotiating an encrypted session, they store a value which they can later use next time to verify that they’re talking to the same client. This is best used in conjunction with SAS, so that the remote client’s identity only needs to be verified once.

This week I fixed up my test suite enough to make it public. It doesn’t do very much right now, but I wouldn’t have been able to bootstrap my XEP-0217 implementation without it.

You can get it from my darcs repository, or you can use the copy I’m running on this server. Existing tests are (in roughly the order that I wrote and used them):

• xep201@testsuite.necronomicorp.com
• xep155@testsuite.necronomicorp.com
• xep200@testsuite.necronomicorp.com
• xep217@testsuite.necronomicorp.com

Sending one of those a chat message reading ‘help’ should give you a rough idea of how to interact with it.

These reports keep slipping further and further into the week—I need to fix that.

Major bugfixes this week, mostly improving error handling and patching up presence leaks. The one visible change is that I’ve completed SAS support, as can be seen in the screenshot. (yes, the dialog is… verbose. if you have any suggestions for cleaning it up, please share them.)

SAS (short authentication strings) serve the same purpose as a PGP or SSL fingerprint. They all allow you to confirm that you’re communicating directly with the person or computer that you think you are.

The first time you connect to an SSH server you get something very similar. You’re supposed to check with the server’s administrator and make sure the fingerprint you see matches the one ey’s got—few people do this. It’s hard to blame them, it’s a gigantic hexadecimal number.

The difference with a SAS is that it’s, well, short. The version specified in XEP-0116 is only 5 characters long. Hopefully this will encourage people to verify it, rather than just ignoring it.

I’m not sure whether I find it funny or depressing that people think AI is more realistic than the Semantic Web in the near future.

I’m back on track this week. I’ve implemented some of the more negotiate-y parts of XEPs 0155 and 0217, specifically message logging.

Some people want their encrypted sessions logged, others (I would wager most) don’t. XEP-155 provides a way of expressing your preference and letting both parties negotiate an acceptable situation. It’s important that we both agree, because your logs can potentially incriminate me (and vice versa).

I’ve implemented it like this: an option in Gajim’s Advanced Configuration Editor (which is very similar to Firefox’s about:config) lets you select whether or not you want encrypted sessions logged. When negotiating a session, Gajim will automatically select your preference if the other party offers it as an option; otherwise it will prompt you with a message like the one in the screenshot. This means that when negotiating a session between two Gajims, either the responder (as opposed to the initiator) gets his way or the session is cancelled. The alternative is to prompt the responder if the initiator expresses a preference other than the responder’s; I think my way makes for a minimum of user hassle, but I’m not entirely sure. We’ll see how it works in practice.

With this done I’ve implemented most of XEP-0217. This week: there are still a few bugs to fix, and then I’d best make an interface for SAS, figure out how to securely store SRSs, beef up the quality of my PRNG and start getting the test suite ready for release.

After getting the basic things working in week three, I rested on my laurels. More than I should have, I’m afraid; I spent most of this week learning Haskell instead of working on GSoC.

I’m still on schedule so I’m not worried; by the end of the month I should have a pretty complete XEP-0217 implementation.

My branch of Gajim has got a functioning XEP-0217 implementation. That is, one client can initiate an encrypted session with another.

I don’t recommend plotting to overthrow any governments just yet; I’m using a weak PRNG, it will still log encrypted messages, I haven’t implemented SAS so there’s no guarantee you’re talking to who you think you are, etc.

And of course I still need to clean up and release the test suite and then get to work on XEP-0116. Things are coming along, though.

I spent more time than I should have hacking away at Gajim to make it allow multiple chat windows per user, only to revert it all back when I realised just how big a task it was. I’ve gone the route of one session per contact; if someone starts a new session, the old one is quietly forgotten about. This is far from ideal, but should be sufficient for now. My philosophy on this project is to get something working as soon as possible, and fill out the details later.

Spent quite a while looking for Python libraries that might implement AES:

• PyAES: dead, replaced by CryptKit
• CryptKit: appears to be dead.
• alo-aes: appears to be dead. no documentation.
• pyopenssl: Gajim already uses this if it’s available, so it would be ideal; unfortunately it doesn’t seem to expose any of OpenSSL’s cipher functions.
• PyCrypto: I went with this because it was the first thing I found that works and has documentation.

I ran across M2Crypto after I’d gotten started; it’s another wrapper for OpenSSL. It might make sense to rewrite the current OpenSSL stuff and use this for everything.

As for interesting things, my branch of Gajim can send and receive encrypted messages - take a look at the screenshot I’ve included. It’s not actually very useful because keys and counters have to be hard-coded, but once I get XEP-0217 up and running (hopefully sometime in week three), that should no longer be an issue.

My lack of cryptographic experience is beginning to show. My mentor (Ian Paterson) has been very helpful in pointing me in the right direction. I’ve also discovered that the Handbook of Applied Cryptography is available online; it’s filling me in on the basics and looks like a good reference.