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: 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