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: Fri, 14 Mar 2014 06:37:26 -0400
From: Bill Cox <>
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On Thu, Mar 13, 2014 at 7:20 PM, Thomas Pornin <> wrote:
> Another point is that I don't actually believe in tunable parameters. At least not many. If we take 100 sysadmins, and give them a password hashing function with a single tunable parameter, we can expect that about 80 or 90 of them will do at least token effort at setting that parameter to a right value for their problem at hand. With two parameters, that proportion will drop; since measuring performance is actually hard (or, at least, much too rarely done, for some reason), two or more tunable parameters imply a lot of combinations which won't be explored correctly, or at all.

Good point.  I'm simplifying my API to conform to this notion.  The
"default" API will simply take password, salt, memory size, and an
option we all should support: clearPassword.

I'm making my old "default" API the "full" API for users who want
control over both runtime and memory size, and the bare metal
interface will be the "extended" API for those who know what they're

I don't think that having more extensive APIs is a bad thing, so long
as the default is reasonably basic.


Powered by blists - more mailing lists