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

[Bill Frantz]

On 3/23/14 at 11:16 PM, dj at deadhat.com wrote:

>#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 am of the opinion that crypto algorithms (and most other 
software) are like wine, best aged a bit. It takes a while for 
the community to beat on an algorithm before one can have any 
degree of trust in it. (I originally wrote "faith" instead of 
"trust" and perhaps faith is the right word.) After a while, the 
issues are better known. The really good news is that the 
analysis techniques continue to be refined and people know about 
more things to examine. (But I still expect that algorithms will 
continue to fall to new insights.)

Consider for example DES. It has been closely studied since its 
publication in 1977, over 35 years ago. Yes it has problems: 
weak keys, 56 bit key length, slow in software, etc., but they 
are known problems with known fixes, such as 3DES. I really 
don't expect new surprises with DES, but see above about new insights.

Because of the improvement in analysis techniques and the number 
of people who can use them, AES may be close to DES in its 
degree of maturity even though it is a lot newer.

In the area of hashes, I feel less confidence. I'm not convinced 
that the analysis techniques are as mature, and I'm not sure we 
even have a good handle on the right questions to ask. When AES 
was selected, some people suggested that the really paranoid 
could used super encryption with each of the five finalists, 
each with its own key. I haven't heard of anyone actually using 
this suggestion -- even in hardware there would be many gate 
delays before the first block came out of the pipeline, but the 
combination is probably at least as secure as the strongest of 
the five.

Now a similar approach might work for hashes. (N.B. I am not a 
cryptographer!). Take two (or more) of the SHA3 finalists, use 
them in parallel, and XOR the results. Pick two that are built 
on significantly different principles to minimize the risk of 
common mode failure. The result should be at least as strong as 
the stronger of the two. (Warning: this idea may be seriously wrong.)

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032