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

ianG iang at iang.org
Sun Mar 23 14:52:22 EDT 2014


On 23/03/2014 06:16 am, dj at deadhat.com wrote:

> 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 

:)

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

that's a red flag to me, why not?

> #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.


Indeed, see DJB's scathing blog post on DSA.

http://blog.cr.yp.to/20140323-ecdsa.html

There appear to be two ways to interpret this state of affairs:  either
the private sector cryptographers have caught up with NSA/NSA, or the
thing was set up to fail in the first place.  It's not out of court that
we see some very embarrassing revelations about DSA in the future, on
par with the Dual_EC story.


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


Do you really care if it's your fault?  Or theirs?  What difference does
it really make, in the long run?

To my mind, people who chose NIST because it's NIST have already done
the damage.  This suggests they haven't done the work themselves, they
haven't understood the risks, and they're not prepared to carry them.
Doesn't speak well of the process.

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


This is our long running thread.  How do we figure this out in the
future?  NIST?  IETF WG?  Competition?  Conference?  Voting?  National
standards?  And, does it really matter that much?


> 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'.


What I find curious is that this logic is good and common and
defensible, but the focus is on the algorithm, the basic building block
or the black box.

Whereas, there isn't nearly as much attention on the protocol, which
IMHO is far more important.  People will obsess about the choice of hash
algorithm far more than they will over whether the protocol is this or
that, or properly implemented or whatever.

The protocol should tell you how much of a hash you need. E.g., seen in
link above:

   "Use half-size H output. Given that we don't need collision
    resistance (see above), do we really need a 256-bit hash?"

In practice, you could choose any of the finalists and be fine, actually
you'd likely be over-engineered (Pareto-secure I once called it).

OTOH, if you were careful, SHA1 would likely work as well for most
protocol purposes.  And that's what I don't see -- I don't see people
carefully designing the protocol such that each of the components work
to a balanced whole.  E.g., do you have a collision problem?



iang


More information about the cryptography mailing list