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: Sun, 13 Apr 2014 01:32:02 -0400
From: Justin Cappos <>
To: discussions <>
Cc: santiago torres <>, Justin Quick <>
Subject: Re: [PHC] Do we need a common password hashing API?

Some of the arguments of PolyPassHash are not overly sensible outside the
context of this algorithm.   For example, the number of shares, whether an
account is thresholdless or a threshold account, etc.

I think for many of the other algorithms what you say makes sense though.


On Sat, Apr 12, 2014 at 7:53 PM, Bill Cox <> wrote:

> Now that I've got all the entries linking with the PHS API, I wonder if it
> would be useful to provide the world with a real one, something they could
> actually use in their applications.  If I were developing an application
> right now that needed to hash passwords, I'd like to future-proof my code
> by linking against an "official" API, which would allow me to select an
> established hashing algorithm now (like Bcrypt, Script, PBKDF2, or HKDF),
> and easily switch in the future, after PHC winners are announced.
> Such an API would need some more parameters than the PHS API, such as the
> hashing algorithm (like PBKDF2), a PRF (like SHA256), and a boolean flag
> saying whether it's OK for the algorithm to clear the password.  We might
> also want an additional data field, or maybe even a generic interface that
> would allow users to hash as much data as they like, similar to the
> init/update/final APIs.  Maybe it would be good to have something for
> dealing with salt and settings string generation, similar to what
> Pufferfish has.  The easier we can make life for users, the better.
> This would of course be in addition to the native APIs from the winning
> entries, but as a user, I would personally stick to the generic API if it
> met my needs.  If such an API were to be offered, the sooner the better,
> because we still have people totally winging it out there, who would much
> rather simplify and future-proof their code than hack it like they do now.
> What do you think?
> Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists