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
| ||
|
Message-ID: <op.xweqelesyldrnw@laptop-air> 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