phc-discussions - Re: [PHC] PHC status report

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]

Message-ID: <20150214164047.23825.qmail@cr.yp.to>
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