CubeHash: a simple hash function |
|
CubeHash submissionIn October 2008, I proposed CubeHash8/1–224, CubeHash8/1–256, CubeHash8/1–384, and CubeHash8/1–512 as SHA-3 candidates. My submission to NIST includes
I think that CubeHash8/1 is much, much, much more conservative than necessary. My justification for recommending CubeHash8/1 is that, for most applications of hash functions, speed simply doesn't matter. High-volume network protection with HMAC is sometimes cited as an exception, but anyone who really cares about speed shouldn't be using HMAC anyway; other MACs are faster and inspire more confidence. What about the occasional applications where hashing speed does matter? If, after third-party cryptanalysis, the community is convinced that much faster CubeHashr/b choices are perfectly safe, then I expect those choices to be considered in speed-oriented applications. For the same reason, I expect NIST to scientifically compare the speeds of different hash-function families by comparing the speeds of the fastest unbroken members of those families—rather than biasing the comparison according to the speculative initial recommendations of the hash-function designers. John Kelsey has commented that "fastest unbroken" is less confidence-inspiring for a complicated hash function than for a simple hash function. Taking this into account would reward simple hash functions such as CubeHash (assuming that they remain unbroken), but I haven't heard of any scientific ways to take it into account. In July 2009, responding to NIST clarifications of speed criteria and security criteria, I proposed a different selection of CubeHash parameters:
In September 2009, I sent NIST an updated
VersionThis is version 2009.09.15 of the submission.html web page. |