When I wrote last week that I had implemented a J-PAKE demo someone rather churlishly commented, “not a demo till it runs on two machines, with a toy browser and toy server”.
So, this weekend I implemented J-PAKE as a proper OpenSSL module. Plus support in
s_client. You can test it like this:
openssl s_server -jpake secret
openssl s_client -jpake secret
If you want to use two different machines, as required by Mr. Churlish, then you’ll need to use the
-connect option to
If you want to use it yourself, you can find example code in
apps/apps.c. Look for the functions
Unless you are Red Hat, the answer is: about as much as eating lunch has to do with business models.
Whatever business you are in, you need your lunch, or you’re going to die. Likewise, but perhaps not quite so urgently, you need software. Open source is about getting the software you want for the minimum investment. It is cheaper and more efficient for those who need particular functionality to group together and provide it for themselves than it is to pay five different companies to not quite provide it in five different ways.
That’s all there is. End of.
So, when you read something like this: “Report: Pure Open Source No Longer a Viable Business Model”, what you are supposed to do is hit the keyboard violently and scream, “It never was, you morons! Get with the program!”
Selling support for software is a business model. Whether it is open source or not. That’s the business Red Hat is in. Not the “open source business”. There isn’t one.
Just for fun, I wrote a demo implementation of J-PAKE in C, using OpenSSL for the crypto, of course. I’ve pushed it into the OpenSSL CVS tree; you can find it in
demos/jpake. For your convenience, there’s also a copy here.
I’ve tried to write the code so the data structures reflect the way a real implementation would work, so there’s a structure representing what each end of the connection knows (
JPakeUser), one for the zero-knowledge proofs (
JPakeZKP) and one for each step of the protocol (
JPakeStep2). Normally there should be a third step, where each end proves knowledge of the shared key (for example, by Alice sending Bob H(H(K)) and Bob sending Alice H(K)), since differing secrets do not break any of the earlier steps, but because both ends are in the same code I just compare the resulting keys.
The code also implements the protocol steps in a modular way, except that communications happen by magic. This will get cleaned up when I implement J-PAKE as a proper OpenSSL library component.
The cryptographic implementation differs from the Java demo (which I used for inspiration) in a few ways. I think only one of them really matters: the calculation of the hash for the Schnorr signature used in the zero-knowledge proofs – the Java implementation simply concatenates a byte representation of the various parameters. This is a security flaw, as it can be subjected to a “moving goalposts” attack. That is, the attacker could use parameters that gave the same byte representation, but with different boundaries between the parameters. I avoid this attack by including a length before each parameter. Note that I do not claim this attack is feasible, but why gamble? It worked on PGP, after all.
The code and data structures are completely different, though. Also, because of the cryptographic difference, the two implementations would not interoperate.
Over the last few weeks, both Google and Yahoo! have released federated login usability studies.
Google’s proposes a flow very similar to login on Amazon, only changing “I’m a new customer” to “Help me log in” and “Do you have a foo.com account?” to “Do you have a foo.com password?”. Amazingly, this is enough for users to get themselves logged in without any training.
An interesting data point, though: users found their second login more confusing than the first. This is because they are used to having a password after the first login, whereas with a federated login, the experience is the same every time. Fortunately, although they’re not quite sure what’s going on, what they do ends up with them logged in anyway. My feeling is that if we start doing federated login widely this confusion will soon evaporate.
Yahoo!, on the other hand, focused on OpenID. This seems to have been a much less happy experience for users, which certainly comes as no surprise to me – it’s always been clear that the average user is not going to understand the idea of logging in with a URL. Plus, they’re damned unwieldy (i.e. big and hard to remember). So, their conclusion was one that doesn’t scale well: use per-IdP buttons.
This backs up my view that OpenID will never really work until it uses email addresses as user IDs.
I don’t normally post about my circumstances, but since I’ve been pretty silent for quite a while now, I’ll make an exception. I broke my wrist 5 weeks ago, which has significantly constrained my computer use. Things should gradually return to normal…