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
| ||
|
Date: 14 Feb 2015 16:40:47 -0000 From: "D. J. Bernstein" <djb@...yp.to> To: discussions@...sword-hashing.net Subject: Re: [PHC] PHC status report Stefan.Lucks@...-weimar.de writes: > CubeHash makes an nice example. The 1st-round submission of CubeHash was > both absurdly slow and broken by a preimage attack. Wrong on both counts. Regarding performance, CubeHash was and is a parametrized family of algorithms offering a wide range of choices between conservativism and speed. By the well-established metric of "fastest unbroken parameters", CubeHash was among the fastest SHA-3 submissions. More importantly, CubeHash is exceptionally _small_. Even if you don't appreciate microcontrollers etc., surely you appreciate the impact of cryptographic instructions in mass-market CPUs, and it's not hard to understand the importance of smallness in encouraging deployment of these instructions. NIST required a "recommended" set of parameters. I recommended a set of parameters that heavily prioritized conservativism over speed (while staying small---no annoying tradeoffs for the hardware designer), and I explained why I was making this choice. You're being ludicrously sloppy in confusing the speed of CubeHash with the speed of these particular CubeHash parameters. Regarding security, while the quest for meaningless security levels can be entertaining for academics, I explained in the CubeHash documentation that I was prioritizing things that actually matter, such as simplicity and small hardware. Of course, I made CubeHash as big as it had to be to comply with NIST's requirement of "approximately" 2^512 security: Collision resistance of approximately n/2 bits, Preimage resistance of approximately n bits, ... I understand that you would have liked "approximately" to be replaced by something more specific so as to retroactively declare CubeHash to be "broken", but your view was never part of the rules, and CubeHash was never broken. If you're going to accuse NIST of ignoring its own rules then you should focus on the rules that they actually published, not the rules that you wish they had published instead. ---Dan
Powered by blists - more mailing lists