[openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

[Blumenthal, Uri - 0553 - MITLL]

Bill, I agree.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Bill Cox
Sent: Tuesday, June 9, 2015 18:00
To: openssl-dev at openssl.org
Reply To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Tue, Jun 9, 2015 at 11:13 AM, Zooko Wilcox-OHearn <zooko at leastauthority.com> wrote:
> All of these are good options in my opinion:
>
> BLAKE2b — widely used, very efficient on modern 64-bit Intel CPUs and
> on ARM chips with NEON, simpler than the "p" versions
>
> BLAKE2s — more efficient on 32-bit chips (e.g. ARMs) which do *not* have NEON
>
> BLAKE2sp, multithreaded — fastest option on my laptop today
>
> BLAKE2sp, singlethreaded — simpler than multithreading and compatible
> with faster implementations

I would suggest that we move ahead with the last option — the
reference implementation of BLAKE2sp. Reasons to choose that option:

1. Then we don't need to mess with compiling in the ASM code, adding
OpenMP support, or anything else for now.

2. It is compatible with faster versions in other tools or in future
versions of openssl.

3. BLAKE2sp (the OpenMP multithreaded version) is the fastest version
on my laptop today).

4. My crystal ball tells me that BLAKE2sp is going to turn out to be
the most efficient version for most uses in the long run, over the
coming decade, because it works well on tiny cheap devices and it also
works well on multicore systems. My crystal ball says that both of
those kinds of things are going to proliferate like locusts after the
rain.

I have trouble agreeing with this.  First, BLAKE2sp is more than 10X slower than BLAKE2s for 256 bit inputs on my machine.  Small input hashing happens frequently, in places such as PBKDF2, Merkel hash trees, MACs, and such.  One of Blake2's main strengths is performance across the board, in pretty much every application, big or small.  On my machine, BLAKE2sp only wins for data sizes over 1 KiB.  Also, OpenSSL should provide the SIMD version anyway, so we'll need to deal with that regardless.  Finally, BLAKE2sp is a simple OpenMP wrapper around BLAKE2s.  It can be rewritten in an generic way that allows it to apply to any hash, such as SHA256.  I think this parallel wrapper would be a valuable library routine.  In this way, we could have sha256sump, and blake256sump, for the parallel versions, which are faster.

I agree the future looks likely to have a ton of Blake2 everywhere.  It also should have parallel hashing everywhere.  I just see these as two independent upgrades.

Bill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/f1ccf607/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/f1ccf607/attachment.bin>