phc-discussions - Re: A rubric for choosing cost parameters

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] [day] [month] [year] [list]

Message-ID: <CAJm83bAy2UhP3W2MYPRx9BeSX552pz5dMLNjv9hLxts16WvEPg@mail.gmail.com>
Date: Tue, 19 Feb 2013 21:34:58 -0500
From: Daniel Franke <dfoxfranke@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: A rubric for choosing cost parameters

On Tue, Feb 19, 2013 at 9:20 PM, I <dfoxfranke@...il.com> wrote:

> From the perspective of the administrator of a online service which is
> required to keep up with a queue of incoming authentication requests,
> the selection of cost parameters in a password-hashing scheme can be
> considered as a trade-off between the following five factors:
>
> 1. m: the amount of memory that may be allocated toward the
> password-hashing scheme. (smaller is better)
>
> 2. r: the number of authentication requests that can be processed per
> unit time. (larger is better)
>
> 3-4. (l,\epsilon): except with probability \epsilon, the latency in
> processing a given request does not exceed l. (smaller is better)
>
> 5. c: the security level of the scheme, in terms of the expected
> monetary cost to the attacker of cracking a password within some fixed
> time period. (larger is better)
>
> Assume that the number of incoming requests during a unit time
> interval follows a Poisson distribution with \lambda=r.
>
> I think an appropriate way to guide the user through selecting
> appropriate cost parameters is to allow the user to supply
> worst-acceptable values for four of these five factors, and then
> recommend cost parameters that optimize the fifth factor within
> those constraints.
>
> This suggestion, obviously, has in mind sophisticated users doing
> capacity-planning for large-scale applications. For grandma's blog,
> the Right Thing is to just automatically pick something reasonable and
> get on with it.

For some reason, as I was writing this I was thinking of CPU capacity as
being fixed. For capacity-planning purposes obviously doesn't make sense.
So, there's a sixth factor:

6. p: The maximum of CPU cores occupied with password-hashing (smaller
is better).