[curves] PAKE use cases

[Feng Hao]

Thanks Brian. That's quite useful info.

The extra work factor idea is very interesting and useful -- making brute-force arbitrarily more expensive at the server side without dramatically increasing the work load at the client side. As far as I know, no one has investigated this before in the past PAKE research. The problem does appear impossible at the first glance, but that makes it an interesting challenge from the research point of view. I need to think about it more.

On the related subject of PAKE user cases, the following is a case that may be of interest to some. The case should be new to many people (at least to me). It's about applying PAKE in a group setting for bootstrapping secure communication among a set of IoT devices. 

I'll present the paper in an ASIACCS workshop in April 2015.

It should be available on the IACR eprint soon, but here is a preprint copy:

http://homepages.cs.ncl.ac.uk/feng.hao/files/gpake-camera-ready.pdf

Any comments, suggestions and criticisms are of course very welcome.

Cheers,
Feng


>-----Original Message-----
>From: Curves [mailto:curves-bounces at moderncrypto.org] On Behalf Of Brian
>Warner
>Sent: 07 February 2015 02:57
>To: curves at moderncrypto.org
>Subject: Re: [curves] PAKE use cases
>
>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
>Curves at moderncrypto.org
>https://moderncrypto.org/mailman/listinfo/curves