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, 9 Sep 2013 19:33:40 +0000
From: Marsh Ray <>
To: "" <>
Subject: RE: [PHC] Terminology goals

When I do a web search for 'slowest hash function', I get a mixture of results. Some are recommending bcrypt and scrypt, some are benchmarks comparing MD5, SHA-1, and SHA-2, etc.

Speaking as a guy who was a corporate developer in a past life, making a living writing data entry dialog boxes for databases:

One of the best gifts our project could give to the community is a new term which unambiguously embodies the security properties needed for the storage and verification of password-based credentials. A developer can write this term on a napkin, search for it when he gets back to his desk, and have the best chance of finding an implementation for his platform that lets him succeed in doing the right thing.

The simpler, the less ambiguous, and the more widely-accepted this term becomes, the more applications will store their passwords-based credentials securely.

- Marsh

> -----Original Message-----
> From: Solar Designer []
> Sent: Saturday, September 7, 2013 7:26 AM
> To:
> Subject: Re: [PHC] Terminology goals
> On Fri, Sep 06, 2013 at 10:42:40PM -0700, Tony Arcieri wrote:
> > What about calling them slow hashes?
> FWIW, this is what we've been calling them in John the Ripper development
> and usage context for a few years now, because we needed to differentiate
> "fast" and "slow" hashes (of the hash types that JtR
> supports) when talking about program structure, optimizations, usage
> instructions (need to bother avoiding occasional duplicate candidate
> passwords or not, etc).
> A "slow" hash might not include a builtin salting mechanism (although in
> practice they almost always do), whereas for PHC this is a requirement.
> Yet I am fine with the "slow hashes" term.
> That said, in PHC context, we've already started using "PHS", so perhaps we
> should stick with that.
> Alexander

Powered by blists - more mailing lists