[curves] Use cases for PAKE?

[Brian Warner]

On 3/19/14 11:30 AM, Trevor Perrin wrote:

>  * There are smaller, more specialized uses of PAKE for protocols like
> online backups or device pairing. E.g. I think Chrome is (using?
> investigating?) SPAKE2 for "chromoting", whatever that is.

We used (past tense[1]) J-PAKE for device pairing in Firefox Sync (with
a boring old 2048-bit Zp group). The first device you set up would
create a random key and use it to encrypt your browser data (bookmarks,
passwords, etc) before sending the ciphertext to our servers. To
configure the second/3rd/etc device, the new device would show you a
short-ish code, which you'd copy into a box in one of the old devices.
They'd J-PAKE, establish a session key, then transfer the
data-encryption key through that secure channel.

The pairing code was 12 base32 characters (60 bits). We used 20 bits as
a "channel ID" to get the two browsers pointed at each other, then the
other 40 bits were the PAKE secret. The code was machine-generated, so
the channel-ID and PAKE-secret were safely independent.

The argument was (and still is) that this pairing scheme provides ideal
security against our servers (in addition to all the usual attackers),
and doesn't require users to manage any passwords.

In the upcoming FF29 (now in beta.. please help us test it!), we've
removed this mechanism in favor of a regular old email+password
(although we're still providing a significant measure of
host-proof-security[2]). Apart from mistakes we made in the
implementation and UI, the deeper issue was that pairing didn't satisfy
the significant use case of people with only one machine. For a while,
over half of Firefox Sync users only had one device, which obviously was
providing them with zero value.

We're hoping to bring pairing back later this year, but in some optional
or supplementary way, and with more UI testing this time. We'll probably
use J-PAKE again, since NSS still has the code, but I'd be more excited
about using J-PAKE or SPAKE2 over Ed25519.

> Anyways, it's not clear that there are strong-enough use cases to
> motivate a good discussion and keep it on track. Though I wish there
> were! PAKEs are cool, it seems like they should be useful somewhere.

Yeah, we don't strictly need EC here: message size isn't an issue, nor
is runtime. We'd like it to work well on slow low-end phones, but I
don't think we've observed the J-PAKE crypto being a bottleneck.

cheers,
 -Brian

[1]: I presented FF Sync at RealWorldCrypto this year: the slides aren't
     ideal without the text, but explain a bit about the confusion we
     observed with the pairing scheme, and describes our new protocol:

     http://people.mozilla.org/~bwarner/warner-rwc2014/

[2]: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol