Re: [babel] Babel-MAC: Blake2s is 128-bits by default

[Valery Smyslov <[e-mail]>]

Hi Juliusz,

> >> Toke and Dave originally suggested adding Blake2s to Babel-HMAC [...]
> 
> > Note sure that I quite agree with your history here,
> 
> It's quite likely I got it wrong, sorry if that's the case.
> 
> > I'm not actually opposed to 128-bit signatures per se, although I would
> > be more comfortable if someone with a crypto background could weigh in
> > with an opinion on this.
> 
> Valery, perhaps you could help?

I'll try to help, but [full disclaimer] I'm not a cryptographer, just a user of crypto :-)

I'm not very familiar with blake2s, but I assume that it's a strong cryptographic MAC function,
so the best possible attack is brute force. So 128 bits for MAC size generally looks OK if the key length
is also at least 128 bits and has enough entropy.

That said, I have two concerns with these figures. First, from my understanding of how
MAC is used in babel, it seems that the keys are long lived, so you potentially protect
very large number of packets using one key. That gives an attacker much more opportunities
to attack algorithm itself. For example, the CFRG has a draft draft-irtf-cfrg-aead-limits 
discussing limits of data to be safely protected with one key (well it's for AEAD ciphers,
but the same concerns applies for any crypto algorithm). I'd feel more comfortable to use 
longer MACs for long-lived keys, but, on the other hand, from my understanding 
routing protocols send relatively little data, so probably 128 bits is OK for babel.

My second concern is mostly theoretical one for now - it's quantum computers.
It is known that for any symmetric crypto quantum computers would reduce 
the effective key size by half (using Grover's algorithm). I'm not quite sure,
but that might apply to forging MACs too (finding second preimage). 

Anyway, this is my personal opinion and I think that CFRG should be asked 
if you want to get more authoritative answer. 

Regards,
Valery.

> >> 1. Toke agrees to switch to 128-bit Blake2s signatures;
> 
> > I think what would happen is that Bird would support both.
> 
> Ok.
> 
> You didn't address the most important question: do you agree with modifying
> the RFC-to-be so that the SHOULD applies to 128-bit signatures, and
> clarifying the information model that the "Blake2s" algorithm implies
> 128-bit signatures?
> 
> -- Juliusz