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 _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
