[Cryptography] BLAKE2: "Harder, Better, Faster, Stronger" Than MD5

[dj at deadhat.com]

> "We hypothesized that offering engineers a hash function that was both
> faster and more secure than their beloved MD5 or SHA-1 might be more
> effective than haranguing them to upgrade to an alternative that is
> more secure but slower."
>
> I guess that makes me just like all the other geeks who care about
> speed!  Actually, if anything, there aren't enough of us anymore.
> Blake2 rocks.  It pains me to switch to slower, more secure systems
> when the old one has not yet been broken (I hung onto ARC4-DROP(N)
> longer than most).  I think people forget that in many cases,
> increased speed results in increased security.
>

Count me as one of the engineers who have to pick a hash function to
implement. I have that problem right now.

#1. I do not care about speed because I implement my stuff in hardware and
regardless of the efficiency of the algorithm I can throw the necessary
number of gates at the problem to make it run at whatever speed is
required.

#2. I do care about security. Shipping insecure crypto is not an option.

#3. I do care about being able to publicly and honestly justify the
reasons for whatever selection is made.

So
#1 is easy.
#2 is something of a judgement call for all algorithms not currently known
to be broken, so I lean on the advice of good cryptographers.
#3 is the killer. The justification of a couple of years ago "We use NIST
SP800-xx because that's the standard" doesn't really fly today because
NIST lacks the trustworthy angle. But there is no obvious consensus body
that we can point to for sound algorithm selection. If I select Blake2,
put it in a substantial fraction of the CPUs out there and it's
subsequently broken, that's my fault. If I select SHA3 for the same chips
and it's subsequently broken, that's NIST's fault but still by problem.
ANSI X9 isn't much help, it's written by the same people that write NIST
SPs.

I don't know what the right justification might be given what we learn in
the next few years, but for now, it would be great if a proper consensus
driven standards body will sufficient attention from cryptographers could
provide the kind of algorithm certification that is trustworthy and we can
use as justification for selecting any particular crypto algorithm. I
don't have high hopes for this happening.

I would personally be happy with the 'any DJB algorithm is fine' approach,
but I don't think I could use that as the kind of justification I could
put in chip documentation. SHA3 may win by default unless it's made easy
to justify better alternatives for well defined meanings of the word
'better'.