Re: [babel] Blake2S, blake2B or neither? [was: rather than ripemd160...]

[Markus Stenberg <[e-mail]>]

> On 30 Nov 2018, at 13.23, Juliusz Chroboczek <[e-mail]> wrote:
>>> With these numbers, I withdraw my support of including anything else
>>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes
>>> sense (mostly for crypto robustness reasons for having alternative
>>> that is specified) but making it MAY-SHOULD seems sensible to me.
>> I can probably live with that :)
> 
> Excellent, it looks like we're converging.  Thanks to both of you for the
> informative and kind discussion.
> 
> At this stage, I see four possibilities:
> 
>  (1) leave the document as it is;
>  (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD);
>  (3) add a mention that implementation of Blake2B is RECOMMENDED;
>  (4) add a mention that implementation of both 2B and 2S is RECOMMENDED.
> 
> I am in favour of (1), since I am convinced that SHA256 is fast enough for
> all reasonable devices.  (2) makes sense to me, and I won't oppose it.
> I'll need some convincing in order to do (3) or (4), since Blake2B does
> not appear bring any significant speed advantage over SHA256.
> 
> In either case, I'm planning to implement SHA256, Blake2B and Blake2S in
> the reference implementation.

I do not actually recommend 2B based on the numbers. By looking at them, you notice that the setup time for 2B is higher and even on 64bit platform the gain is not insane even on large operations (25%ish, perhaps). -2BP is what I have and will recommend for large bulk hashing (-P variant allows for paralllelization of hashing to multiple cores), but for smaller stuff it seems Blake2S is faster on both 32 and 64bit.

As they are all based on same cryptographic base, it is likely that if weakness is found in one, it is present in others. That said, as BLAKE algorithm was at the time of SHA-3 contest analyzed to be strictly superior to SHA-2 in some features, it seems unlikely. But you never know.

The above discussion cuts out options 3 and 4 for me.

I am mostly indifferent between 1 and 2; SHA256 (especially with hardware acceleration) is probably faster than Blake (even with just Intel optimized assembler it is 60-70% of Blake 2B), and if we’re talking millions of pps (acceleration present) it is entirely academic anyway for a routing protocol. The tinfoil hat argument for 2 is that it provides fallback if SHA256 breaks down somehow in the future. So I have SLIGHT preference for 2 but am happy enough with 1 as well.

Cheers,

-Markus