On Mon, Oct 20, 2014 at 6:18 PM, Damien Miller <[email protected]> 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. Sincerely, Watson Ladd > > -d -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
