It’s been a while (I’ve been busy on another project, more on that soon, I hope), but finally…
I’ve updated the protocol slightly to correct a subtle bug in the secret splitting specification. You can find the latest versions and diffs here.
I’ve also finally got around to tidying the code up some (though there’s still plenty more to do), you can find an appspot server, a command line client and various libraries, all in Python, at nigori.googlecode.com. As always, patches are welcome!
The code does not fully reflect the draft protocol yet – in particular, it still uses a Schnorr signature where the draft calls for DSA.
If you want to play with the command-line client, I already have a server running on appspot. Here’s how … from the
client directory, run
$ ./client.sh nigori-server.appspot.com 80 register name password
$ ./client.sh nigori-server.appspot.com 80 authenticate name password
Replaying: this should fail
$ ./client.sh nigori-server.appspot.com 80 add user password name secret
/usr/local/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken
Status: 200 OK
Content-Type: text/html; charset=utf-8
Expires: Fri, 01 Jan 1990 00:00:00 GMT
$ ./client.sh nigori-server.appspot.com 80 get user password name
0 at 1277559350.600000: secret
Not the most elegant interface in the world. Note that the server is experimental, I may break it, delete all the data, etc. Of course, you can run your own.
Note also that the whole protocol is experimental at this point, I wouldn’t rely on it to store your vital passwords just yet!
I don’t often mention the FreeBMD project on this blog, perhaps I should. Anyway, we (the trustees of FreeBMD) have decided that it’s time to hire an Executive Director. It occurred to me that some of my readers might be interested, or might know someone who is.
Comments Off on FreeBMD Seeks An Executive Director
It’s been 7 months since the TLS renegotiation problem went public and Opera’s security group have a couple of interesting articles about it. The first is about adoption of patched versions and the verdict is not good, as this graph shows…
At this rate it will be two years before the fix is widely adopted!
The second is about version intolerance – scarily, nearly 90% of patched servers will not work when a future version of TLS bumps the major version number to 4 (it is currently 3). This is pretty astonishingly crap, and is likely to cause us problems in the future, so I’m glad the Opera guys are working hard to track down the culprits.
By the way, at least according to Opera, OpenSSL does not have this problem.
Note that I am not speaking for my employer in this post.
I’ve been following the debate around XAuth with interest. Whilst the debate about whether centralisation is an acceptable stepping stone to an in-browser service is interesting, I am concerned about the functionality of either solution.
As it stands, XAuth reveals to each relying party all of my identity providers, so that it can then present UI to allow me to choose one of them to authenticate to the RP. Why? What business of the RP is it where I have accounts? All that should be revealed is the IdP I choose to reveal (if any). This seems easy enough to accomplish, even in the existing centralised version: all that has to happen is for the script that xauth.org serves is to include the UI for IdP choice.
This is not just privacy religion (or theatre): as the EFF vividly illustrated with their Panopticlick experiment, it is surprisingly easy to uniquely identify people from signals you would have thought were not at all identifying, such as browser version and configuration information. Indeed, a mere 33 IdPs would provide enough information (if evenly distributed) to uniquely identify every person in the world. Meebo had no difficulty at all coming up with 15 of them for page one of many in their introductory blog post…