<div dir="ltr">The parallel versions are mostly beneficial when hashing long (say, 1k+) messages and when faster hashing is noticeable. Not sure it's the case here. </div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 4:55 AM Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 1, 2017 at 7:54 PM, Jason A. Donenfeld <<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>> wrote:<br>
><br>
> I was looking at Samuel's (CC'd) AVX2 optimized implementations of<br>
> Blake2 [1] and noticed there wasn't any implementation for Blake2s.<br>
> Samuel explained to me that blake2s and blake2b don't naturally<br>
> parallelize, which is why the blake2sp and blake2bp variants exist;<br>
> these nicely parallelize, so fast implementations are possible. Given<br>
> that Noise is pretty hash-heavy, we have good reason to be interested<br>
> in fast hash functions.<br>
<br>
<br>
Is it, really? ("hash-heavy").  The hash is just used during the<br>
handshake, where's there's all the public-key ops.<br>
<br>
Noise does lots of small-message hashing (including HMAC and HKDF),<br>
plus hashing the "e" and "s" tokens, where I imagine this wouldn't<br>
help much or at all.  And I assume it's more complex and less widely<br>
available.<br>
<br>
It's easy to just do it if you use the "BLAKE2sp" name, but at first<br>
glance I'm skeptical this would be a good recommendation for the core<br>
spec.<br>
<br>
Trevor<br>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div>