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

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 01 Dec 2018 12:15:51 +0100

>> (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'm in favour of (2).

Where is Blake2S-based HMAC defined?  RFC 7693 merely says:

   BLAKE2 does not require
   a special "HMAC" (Hashed Message Authentication Code) construction
   for keyed message authentication as it has a built-in keying
   mechanism.

but it does not appear to clearly define the HMAC construction.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sat, 01 Dec 2018 20:09:59 +0100

> but it does not appear to clearly define the HMAC construction.

Section 3.3 simply says:

   If a secret key is used (kk > 0), it is padded with zero bytes and
   set as d[0].  Otherwise, d[0] is the first data block.  The final
   data block d[dd-1] is also padded with zero to "bb" bytes (16 words).

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 01 Dec 2018 20:47:53 +0100

>> Where is Blake2S-based HMAC defined?  RFC 7693 merely says

>    data block d[dd-1] is also padded with zero to "bb" bytes (16 words).

Thanks, that was the bit I'm missing.

With that info, I have no objection to making Blake2S RECOMMENDED in
Babel-HMAC.  I'm still waiting for more opinions before I make up my mind.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sat, 1 Dec 2018 17:07:18 -0800

On Fri, Nov 30, 2018 at 5:23 AM Toke Høiland-Jørgensen <[email-masked]> 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:
> >
> > 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.
>
> I'm in favour of (2).

2 is fine. Would still prefer MUST. Would also like an arm32 + neon
blake benchmark.

>
> > In either case, I'm planning to implement SHA256, Blake2B and Blake2S in
> > the reference implementation.
>
> Cool. I'll do the same in Bird, then :)
>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Dec 2018 23:18:45 +0100

> FWIW, for homenet the thought was to use HNCP to distribute keys amongst
> routers.

HNCP is not a good choice for symmetric key distribution, since it floods
all information across the HNCP domain.  It's impossible to use HNCP to
distribute a key to some routers only while keeping it secret from others.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Dec 2018 23:19:46 +0100

> Setting that aside for the moment, having a standardized file format
> for babel keys would be a boon and boost interoperability between
> bird/babel and other possible implementations.

Have you looked at RFC 7210?

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Tue, 4 Dec 2018 09:48:34 -0800

> Have you looked at RFC 7210?

https://xkcd.com/927/

It is evident (now!) that my conception of these conceptions was
different than the homenet starting point. I envisioned lots and lots
of keys interconnecting a multitude of networks, where the design as
stands is oriented towards securing a single domain.

further, I've learned now, dtls would be a better interconnect, and
considering how to do that well might factor in the above standard.

I would still rather like to be able to test key rollover by christmas!

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 4 Dec 2018 20:33:39 +0200

For interconnected domains and whatever, I would rather just use DTLS with relatively shortlived and auto-renewed certs (real-time revocation is hard to do if you are authenticating routing - chicken 'n' egg problem; one alternative is of course some sort of manual blacklisting if you want to go with long-lived certs).  

If HNCP is in picture, DNCP trust based consensus model is also an option - with it, (self-signed) certificates can have long lifetime as their usefulness is determined by consensus of nodes -> as long as there's only few compromised nodes, you can blacklist them in real time if you control the rest of the nodes.

Cheers,

-Markus