[curves] PAKE use cases & requirements

Watson Ladd watsonbladd at gmail.com
Mon Oct 20 20:04:02 PDT 2014

On Mon, Oct 20, 2014 at 6:18 PM, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 20 Oct 2014, Watson Ladd wrote:
>> Based on that it seems that the Secret Millionaire Protocol is a
>> possibility, but could load the server more than necessary. SPAKE2 is
>> also worthy of consideration.
> AFAIK none of these solve:
>> > 3. Can work with hashed passwords.
>> >
>> > I.e. the server stores some H=F(password, salt) but the client gets
>> > to use the password directly. Disclosure of H yields no more to the
>> > attacker than disclosure of a password file that has been sensibly
>> > hashed today (e.g. with bcrypt).
>> >
>> > The password hash should probably reuse one of the good current
>> > ones (bcrypt or scrypt). E.g. by storing something like
>> > G^{BCRYPT(pw,salt) mod P}
> My somewhat clumsy experimental JPAKE implementation for OpenSSH
> didn't either - it used the password hash as the shared secret to be
> authenticated against and therefore would allow logins (via JPAKE) to an
> attacker with access to the password hashes alone.

Okay, here is a protocol that solves that problem, but you are not
going to like it:

Let G_1xG_2->G_T be a bilinear group, g_1, g_2 generators of G_1 and
G_2. Let the server store BCRYPT(pw, salt)g_2. Then when a client
authenticates the server sends rg_1, the client responds with
BCRYPT(pw, salt)rg_1, and the server checks that
e(BCRYPT(pw,salt)rg_1, g_2)=e(rg_1, BCRYPT(pw_salt)g_2). This is an
instance of the Computational Co-Diffie Hellman Problem.

Watson Ladd
> -d

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

More information about the Curves mailing list