[curves] PAKE use cases

[Brian Warner]

On 10/8/14 5:08 PM, Trevor Perrin wrote:

> If anyone knows other protocols where PAKE would be useful, that would
> also be helpful.

I've been working on PAKE recently, so I thought I'd resurrect this
four-month-old thread to mention the use-cases that I've cared about at
various times in the last several years:

Firefox Sync (1):

 The original design used J-PAKE to transfer long-term encryption keys
 (for bookmarks/history/etc) from one user's browser to another. (see my
 RWC2014 slides: http://www.lothar.com/presentations/fxa-rwc2014/, or
 https://www.youtube.com/watch?v=G16rOGmpBUc for why we stopped). The
 human transcribed a short random code from one browser to the other,
 then the browsers performed PAKE to build a session key for the
 credential transfer, without giving any special trust to a server. So
 the desired properties are:

  * balanced is fine, no need for augmented
  * named sides are ok (we know which side is which, one side displays
    code, the other accepts it), no need for a fully symmetric protocol


Firefox Sync (2):

 A later, abandoned design (also mentioned in that RWC presentation)
 used SRP to prove knowledge of the user's password (to a server), and
 to protect transfer of a wrapped long-term encryption key from the
 server back to the client. The client would feed the user's password
 through scrypt(), use the stretched form as input to SRP, use the SRP
 session key to protect delivery of a stored wrapped key, then the
 client would use a different scrypt() derivative to unwrap that key. An
 attacker who steals the backend database would get a dictionary attack
 on the user's password limited by the scrypt() step, but a mere MitM
 would only get a single guess, and a passive eavesdropper would get
 nothing.

  * augmented is necessary
  * we really wanted extra-augmented: a work factor more than a single
    group exponentiation. As discussed elsewhere, this is maybe
    impossible


Petmail/Pond/Panda:

 Clients are introduced to each other by means of a short "invitation
 code", transcribed by humans or cut-and-pasted over pre-existing
 channels like email or IM. Clients then find a way to rendezvous and
 exchange messages, and PAKE is used through that channel to protect
 exchange of long-term identity and encryption keys (including the
 initial set of keys for a DH ratchet).

 * balanced is fine
 * named sides are a nuisance: there's no obvious difference between the
   two sides, and asking users to remember arbitrary labels would hurt
   usability


cheers,
 -Brian