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

[Zooko Wilcox-OHearn]

On Tue, Jun 9, 2015 at 10:00 PM, Bill Cox <waywardgeek at google.com> wrote:
>>
>> I would suggest that we move ahead with the last option — the
>> reference implementation of BLAKE2sp.

> I have trouble agreeing with this.  First, BLAKE2sp is more than 10X slower
> than BLAKE2s for 256 bit inputs on my machine.

Wow! I didn't measure that. What implementation of BLAKE2sp did you
try? What kind of machine is yours?

>  Small input hashing happens frequently, in places such as PBKDF2, Merkel hash trees, MACs, and such.

Agreed.

> One of Blake2's main strengths is performance across the board, in pretty
> much every application, big or small.

Agreed.

>  On my machine, BLAKE2sp only wins for data sizes over 1 KiB.

Hm, yeah, I'm mostly driven by the "b2sum" use case here, which almost
never gets used on inputs as small as 1 KiB, and often gets used on
inputs 3 or even 6 orders of magnitude bigger!

I agree with you that the short-input use case is really important. I
wonder how well we could do with an optimized, single-threaded
implementation of BLAKE2sp. Could you do an experiment of the
single-threaded implementation of BLAKE2sp with floodyberry's
optimized implementation: https://github.com/floodyberry/blake2b-opt ?


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

That sounds like a good idea!


Regards,

Zooko