The current state of play:

1. I've made curve25519-donna constant time, and, at the request of DJB, I'll be making it public domain too. I've been told that a group has it working in 165us and I just can't even get close to that. I spent a day rewriting the field multiplication using SSE2, but that didn't help at all. Nevermind, that group aren't releasing their source it seems so they don't count :)
2. I'm working on getting djbdns's client library in a useful state in order to integrate into Firefox. (did you know that libresolv doesn't parse DNS packets for you? How useless!) So I spent today reviewing 1000s of lines of DJB's code and adding comments.

The point of (2) is that my current plans are revolving around these ideas:

Keeping the server's public key in a TXT record for _obs_80.example.com. Why TXT? Because it's better supported. Thus clients will need a real resolver library, hence my work on DJB's code.

However, this presents some problems, mostly in the face of transproxies: If we were to connect and write a NUL (to escape HTTP) and then start with encrypting the usual HTTP stream, a transproxy will probably barf. But users can't get around them! (I need to test this with Squid tomorrow).

So one solution is for the TXT record to be able to indicate a separate port number. However, a separate port is a real pain for some sites to setup. So we might need something different. I think that might be encapsulation like:

HEAD / HTTP/1.1
Host: example.com
X-ObsReq: a4bfdz33456sdfFdsFA...
X-TransProxyDetect: flowers

The X-ObsReq carries the encrypted request, so that we don't burn a RTT on the probe. The hope is that transproxies will remove the header that they don't understand (again, have to test with Squid). The server recognises the headers and replies with an encrypted reply in the expected case. However, if a transproxy removed the header, it sends a normal reply. Thus the client can detect the proxy and back off (sadly, probably forever).

Also, is the TXT requirement too much for some? Do we need cross session state as well to get the server keys to the client? (The idea here being that a server can advertise it's keys in an unencrypted reply and the client caches the key, on disk, for some time.)

Again, it's much more messy furthur up the stack, although we don't need kernel changes.

Comments welcome. Email or comments on the post.

(updated: before I go to sleep, it strikes me that a series of POSTs with uncachable replies may work better)