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

[Bill Cox]

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/dfbc38ec/attachment-0001.html>