On Tue, Jun 9, 2015 at 10:00 PM, Bill Cox <[email protected]> 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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
