Subject: [Cfrg] FYI: "The BLAKE2 Cryptographic Hash and MAC" draft-saarinen-blake2

From: Markku-Juhani Olavi Saarinen <[email-masked]>
Date: Sun, 1 Feb 2015 23:56:35 +0100

Hi,

Just out: M-J. Saarinen (ed.) and J-P. Aumasson,
"The BLAKE2 Cryptographic Hash and MAC"
draft-saarinen-blake2-01

Abstract

   This document describes the cryptographic hash function BLAKE2,
   making the algorithm specification and C source code conveniently
   available to the Internet community.  BLAKE2 comes in two main
   flavors: BLAKE2b is optimized for 64-bit platforms, and BLAKE2s for
   smaller architectures.  BLAKE2 can be directly keyed, making it
   functionally equivalent to a Message Authentication Code (MAC).

http://tools.ietf.org/html/draft-saarinen-blake2-01

Rationale for submission:

BLAKE2 is an improved version of the SHA3 finalist algorithm BLAKE. As
such it has received a significant amount of public scrutiny over last
7 years. We opine that IETF security protocols and applications will
benefit from availability of an alternative, fast, current-generation
cryptographic hash and message authentication function which has been
designed independently from SHA algorithms. It is also faster than any
of the SHA algorithms (even faster than MD5).

This is basically an "informational RFC in the pipeline and we have
running code" submission so no consensus action is required from the
members of this mailing list. Of course bug reports are welcome.

The reference code is also at available at:
https://github.com/mjosaarinen/blake2_mjosref

Much more BLAKE2 info is available at https://blake2.net/
(BUY THE BOOK)

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[email-masked]>

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 1 Feb 2015 15:09:35 -0800

I support BLAKE2 specifically for its performance when implemented in
software, most notably the performance of BLAKE2b on 64-bit platforms.

I would love to see it adopted for use in e.g. TLS.

-- 
Tony Arcieri

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 02 Feb 2015 07:37:00 +0000

On 01/02/2015 22:56, Markku-Juhani Olavi Saarinen wrote:

> <https://tools.ietf.org/html/draft-saarinen-blake2-01>

Draft could use some test vectors.

Other than that, seems fine to me on a short read!

Great work. BLAKE2's *really* fast in software - not bad in hardware
either!

> This is basically an "informational RFC in the pipeline and we
> have running code" submission so no consensus action is required
> from the members of this mailing list.

Good call. ;-)

- -- 
/akr

---

From: David Leon Gil <[email-masked]>
Date: Sat, 14 Feb 2015 21:04:12 -0800

On Sun, Feb 1, 2015 at 2:56 PM, Markku-Juhani Olavi Saarinen
<[email-masked]> wrote:
> BLAKE2 is an improved version of the SHA3 finalist algorithm BLAKE.

Improved in speed, not in security.

It would be nice to see more cryptanalysis of Blake2 prior to its use
in internet protocols. Especially as the changes from Blake->Blake2
are rather significant:

- changed rotations,
- increased attacker degrees of freedom in the initial state,
- and a significant round reduction (b: 16->12, s: 14->10).

See https://blake2.net/#cr for the two papers which are the summa
totalis of published cryptanalysis on Blake2.

I'm reasonably happy with Blake2b/12 in applications in which the
parameter block is fixed. But even in applications where the cost of
hashing dominates, a hypothetical Blake2b/16 would be faster than
SHA1: http://bench.cr.yp.to/results-hash.html

---

From: Jean-Philippe Aumasson <[email-masked]>
Date: Sun, 15 Feb 2015 07:30:25 +0100

Most cryptanalysis done on BLAKE during SHA3 in 2008-12 applies in
principle to BLAKE2 as well. BLAKE2 like BLAKE is unlikely to have
significant security defects.

On Sunday, February 15, 2015, David Leon Gil <[email-masked]> wrote:

> <[email-masked] <javascript:;>> wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked] <javascript:;>
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Feb 2015 11:52:51 +0200

Hi.

Finally found the time to read this. Thanks for posting this.

I agree with the need for some test vectors. Links to cryptanalysis can be in or out of the draft, I don’t care much either way.

What IMO is missing from the draft is motivation. Not your motivation for writing this, but our motivation to adopt it in TLS, IPsec, SSH, whatever.

Copying the data from SUPERCOP for 2-4 target platforms, representing servers, PCs, mobile phones and “things” would go a long way. Blake2b/blake2s should be compared with the “incumbent” SHA-256 and the other “contender” Keccak.   I guess the relevant platforms are Xeon E3-1275 (server), Core i7-4770 (desktop), and Cortex-A9+NEON (phone). The comparison with SHA-256 is impressive. The comparison with Keccak, almost as impressive. The draft should reflect that.

Looking at those numbers, I can also see that blake2b is significantly faster on 64-bit platforms, while blake2s is only somewhat faster on 32-bit platforms. I think it’s questionable whether the IETF protocols should adopt both.

One more comment. In terms of what IETF protocols need, this draft defines two algorithms: a hash and a MAC. I can figure out from the draft that the “right” way to obtain the hash function is to feed the MAC function a zero-length key, rather than say, a 128-bit all-zero key. I think it would be better if the draft said so explicitly.

Thanks

Yoav

---

From: Samuel Neves <[email-masked]>
Date: Sun, 15 Feb 2015 22:43:32 +0000

> Looking at those numbers, I can also see that blake2b is significantly faster on 64-bit platforms, while blake2s is only somewhat faster on 32-bit platforms. I think it’s questionable whether the I…

Cortex-A9 + NEON is not really a good example of a 32-bit platform, since NEON can work natively on 64-bit integers;
this still favors BLAKE2b. A better example of a 'real' 32-bit platform would be h2tegra, a Cortex-A9 derivative without
NEON: http://bench.cr.yp.to/results-sha3.html#armeabi-h2tegra

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Feb 2015 01:53:55 +0200

> On Feb 16, 2015, at 12:43 AM, Samuel Neves <[email-masked]> wrote:
> 

That’s nearly thrice the performance. Yeah, I guess we need both. Although, most newer phones and tablets (and practically all PCs) are now 64 bit. So 32-bit is fast becoming the domain of embedded platforms.

Yoav

---

From: Zooko Wilcox-OHearn <[email-masked]>
Date: Tue, 17 Feb 2015 06:14:03 +0000

On Sun, Feb 15, 2015 at 6:30 AM, Jean-Philippe Aumasson
<[email-masked]> wrote:
> Most cryptanalysis done on BLAKE during SHA3 in 2008-12 applies in principle
> to BLAKE2 as well. BLAKE2 like BLAKE is unlikely to have significant
> security defects.

I'd like to respond to David Leon Gil pointing out that cryptanalysis
is important for an algorithm like this. I agree.

I'm one of the authors of BLAKE2, but back when the SHA-3 competition
was underway, I was merely an enthusiastic outside observer (I had
nothing to do with BLAKE).

My observations about the results of the SHA-3 competition were:

NIST evaluated BLAKE as having had an even greater degree of security
analysis than Keccak. The final report on SHA-3 from NIST states
“Keccak received a significant amount of cryptanalysis, although not
quite the depth of analysis applied to BLAKE.”.

Why then did NIST not choose BLAKE to be SHA-3? NIST gave two main
reasons for choosing Keccak over BLAKE.

One was that Keccak was especially well suited to high performance
implementation in hardware (about which Adam Langley subsequently
wrote https://www.imperialviolet.org/2012/10/21/nist.html ).

The other was that BLAKE was similar to SHA-2. The final report from
NIST states “desire for SHA-3 to complement the existing SHA-2
algorithms … BLAKE is rather similar to SHA-2.”.

At the time, it made sense for similarity to SHA-2 to be regarded as a
potential problem in a candidate. The SHA-3 project was launched eight
years ago because of widespread panic that SHA-2 might be revealed to
be weak, and if so there would be no strong hash functions left. So it
made sense that SHA-3, as an alternative to SHA-2, would be better if
it were more different from SHA-2.

However in 2015, with the benefit of more years of experience, it
appears that SHA-2 is actually quite strong — it is one of
longest-serving hash functions in all of history, and has revealed no
serious cryptographic flaws.

So today, similarity to SHA-2 no longer appears to be a weakness and
might even be considered a strength.

All of the above is my response to David Leon Gil's point that we need
good cryptanalysis. If you accept (as I do) Jean-Philippe Aumasson's
claim that most of the cryptanalysis of BLAKE applies to BLAKE2, then
BLAKE2 has a very good pedigree in terms of cryptanalysis.

Here are my slides from ACNS 2013 summarizing the above argument and
giving other reasons that BLAKE2 is needed:

https://blake2.net/acns/slides.html

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com — “Freedom matters.”
http://theoatmeal.com/comics/email_monster

---

From: David Leon Gil <[email-masked]>
Date: Tue, 17 Feb 2015 23:54:06 -0800

On Mon, Feb 16, 2015 at 10:14 PM, Zooko Wilcox-OHearn
<[email-masked]> wrote:
> . . . If you accept (as I do) Jean-Philippe Aumasson's

I am disinclined to accept claims without some justification.

It is, no doubt, boring work to sort through old cryptanalysis, but it
is boring work that is unlikely to be done in public unless one of the
BLAKE2 authors does it.

---

From: Jean-Philippe Aumasson <[email-masked]>
Date: Wed, 18 Feb 2015 10:12:48 +0100

> is boring work that is unlikely to be done in public unless one of the

You'll find some justification in 4.1 and 4.2 of
https://blake2.net/blake2_20130129.pdf.