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  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".

Powered by blists - more mailing lists