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

[Bill Cox]

On Wed, Jun 10, 2015 at 4:53 AM, Hubert Kario <hkario at redhat.com> wrote:

> we'll soon get sha3-256 and sha3-512 (among others), "BLAKE2-256" (or to
> continue the lower case naming scheme - blake2-256) doesn't look bad
> compared
> to those
>


In that case, I prefer 2 new sets of hash functions:

    blake2-256/BLAKE2-256
    blake2-512/BLAKE2-512

based on BLAKE2s and BLAKE2b respectively.  For the basic BLAKE2
integration, I would leave the parallel versions out.

And that's it.  Nice and simple :-)  I'll offer to do the integration if no
one beats me to it.

...

However, as a separate proposal, should we discuss parallel hashing APIs?
Should it be on a different thread?  I'm commenting here for now:

First, I think Zooko's intuition is right.  Parallel hashing should be
offered by OpenSSL, simply because that will greatly increase it's use, and
there will be significant benefit to users.

As for implementation, I would like to see parallel APIs added for BLAKE2
and the SHA functions at a minimum.  The number of threads should be a
parameter rather than hard-coded, and it should be based on OpenMP.  Users
will need to understand that the resulting hash depends on the number of
threads used.

Before dealing with EVP extensions, there should be parallel APIs for the
standard hash functinos, such as:

int SHA256P_Init(SHA256P_CTX *c, unsigned int max_threads);
int SHA256P_Update(SHA256P_CTX *c, const void *data, size_t len);
int SHA256P_Final(unsigned char *md, SHA256P_CTX *c);
unsigned char *SHA256P(const unsigned char *d, size_t n, unsigned char *md,
unsigned int nax_threads);

and

int BLAKE2_256P_Init(BLAKE2_256P_CTX *c, unsigned int max_threads);
int BLAKE2_256P_Update(BLAKE2_256P_CTX *c, const void *data, size_t len);
int BLAKE2_256P_Final(unsigned char *md, BLAKE2_256P_CTX *c);
unsigned char *BLAKE2_256P(const unsigned char *d, size_t n, unsigned char
*md, unsigned int nax_threads);

I hate to recommend more macro-template madness for OpenSSL.  The ASN1
template macros in the 1.0.1 branch made me want to set my hair on fire (I
believe this has been cleaned up since).  Of the million-ish lines of
open-source code I've read over the years, this might win the prize for the
most obfuscated.  However, these parallel hash functions could easily be
generated with macros, or perhaps some more Perl madness.  The code
template is the same regardless of the hash used.  We could literally copy
the code from blake2sp.c to make the template.  Would it be better to just
copy+paste+edit the code for each hash function, and avoid more template
madness?

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/5e525001/attachment.html>