lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jan 2014 20:45:25 +0400
From: Solar Designer <>
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On Mon, Jan 20, 2014 at 03:05:38PM +0000, Peter Maxwell wrote:
> On 20 January 2014 11:19, Solar Designer <> wrote:
> > On Mon, Jan 20, 2014 at 02:13:20AM +0000, Peter Maxwell wrote:
> > > [...] if we're going to go
> > > to the bother of replacing the authentication mechanism on various
> > > services, surely we can do better than client-side password hashing.
> >
> > I agree, which is a reason why I think a PHC candidate's builtin "server
> > relief" support (if present) should be usable for some more advanced
> > than "pass-the-hash" authentication mechanisms.  Ideally, it should fit
> > some pre-existing ones.
> So if we're moving towards a PBKDF that is suitable for, say, SRP then the
> "server relief" part of the PBKDF is pretty much redundant, is it not?

If it'd have to exactly match a PBKDF defined as part of e.g. SRP, then
indeed it won't be a new PBKDF and thus not relevant to PHC.  What I
meant is that we could have a new PBKDF that would otherwise fit an
existing authentication mechanism, either because that mechanism was
defined for arbitrary PBKDFs to be substituted into it, or with this
being the only deviation from its existing definition.

> Have we had a discussion on the PHC candidates in reference to password
> auth'd key exchange mechanisms as yet?

I think not yet, but I think they should just fit in.


Powered by blists - more mailing lists