phc-discussions - Re: [PHC] "Why I Don't Recommend Scrypt"

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAOLP8p6=f+dieK7cR0KVK=xr+3vuOSHaOTNzCD2vvhsKNv-6hA@mail.gmail.com>
Date: Fri, 14 Mar 2014 06:37:26 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] "Why I Don't Recommend Scrypt"

On Thu, Mar 13, 2014 at 7:20 PM, Thomas Pornin <pornin@...et.org> 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
doing.

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

Bill