phc-discussions - Re: [PHC] OMG we have benchmarks

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]

Date: Wed, 01 Apr 2015 02:38:35 -0700
From: "Jeremy Spilman" <jeremy@...link.co>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] OMG we have benchmarks

On Wed, 01 Apr 2015 02:24:34 -0700, Dmitry Khovratovich  
<khovratovich@...il.com> wrote:

> Just there must be proper parameter choice ... [to be] minimally secure  
> and recommended

I think the point of a consistent API should be that "proper" parameter  
choice is consistent across algorithms, and never possibly "wrong". If you  
have to special case your parameters for a given algorithm, or avoid  
certain inputs which are otherwise commonly used, then arguably that's a  
bug in the underlying algorithm.

Would not the "perfect" API take as its singular cost input a dollar value  
(bikeshedding aside), to then select the most effective algorithm, given  
the hardware at its disposal, to imbue said cost with the least amount of  
latency?

I don't mean that literally, but the goal of the API is to provide the  
necessary levers to efficiently imbue cost under the given hardware and  
latency constraints -- without allowing the operator to shoot themselves  
in the foot.

I think valid / "minimally secure" inputs MUST be consistently defined, or  
even further, all valid inputs MUST be "minimally secure".