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

Toke Høiland-Jørgensen <toke@toke.dk> Mon, 16 November 2020 13:51 UTC

Return-Path: <toke@toke.dk>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1753A0FF7 for <babel@ietfa.amsl.com>; Mon, 16 Nov 2020 05:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm3hOw6MZPxb for <babel@ietfa.amsl.com>; Mon, 16 Nov 2020 05:51:29 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1FA3A0FF2 for <babel@ietf.org>; Mon, 16 Nov 2020 05:51:28 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1605534685; bh=7xc9YXg8dW1+4ss8GzTF+XVioePh254ADlFXs7qGTJE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=xGmWwuN0T7abWGXn/t7DUqKhScaY06BxwPqKAnnco4lfQGMvy5kXMNYN0U2mbMIry G1tdn6mQeye7CzrEZpqtE/hdZQpD4C91rI1iUwAumeBE1RlLF2Cxm3mysSwepp/sJt 0o5w29/nenz+hb7FQKOWFiBB9QAb4LJuyT+VRTrrVTO3JCUUneoSpgsE4Oe5B/6Nki 9ehuwLGy72g3/xeRkqxJGowCyBd7FTGEceL+J5h2ow1Srkk9MPn3rRiJmkdFv4I7z/ TvDxh2hvjVaQaojdBjVLDMhculADzunHn6++ESbrnfRSEV32+4LMLEA/fyKtW0/mRh ReX6MJMnr2J1g==
To: Juliusz Chroboczek <jch@irif.fr>, babel@ietf.org
Cc: Valery Smyslov <valery@smyslov.net>
In-Reply-To: <87o8jya4jz.wl-jch@irif.fr>
References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr>
Date: Mon, 16 Nov 2020 14:51:25 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87wnyl4dgi.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/MWkSRZCROWePsksqd7DXaMI0Sa8>
Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 13:51:32 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

> After reading your replies, and thinking it over carefully, I disagree
> with the apparent consensus.  I think Blake2s in Babel-MAC should use
> 128-bit keys, as in the initial implementation.  Please hear me out.
>
> Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two
> reasons:
>
>   - it is more computationally lightweight on platforms that don't
>     implement SHA-256 in hardware;
>   - it may serve as a fallback if SHA2 is ever broken.
>
> While I am still not quite convinced by these arguments, I've agreed to
> add the SHOULD Blake2s and to implement Blake2s for the following reasons:
>
>   - it serves as a good example of adding a new algorithm to Babel-MAC;
>   - with 128-bit signatures, it is useful on low-rate networks, which
>     Babel is commonly used with.
>
> For these reasons, we implemented Blake2s with 128-bit signatures.
> Unfortunately, some confusion ensued, Toke implemented Blake2s with
> 256-bit signatures, Antonin changed our implementation to interoperate
> with Toke's (without discussing the issue with me beforehand), hence the
> current situation.

Note sure that I quite agree with your history here, but that doesn't
really matter; 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.

(Note that the way blake2s implements this is just by truncating the
output to whatever size you specify, the rest of the algorithm is
exactly the same).

> If Blake2s uses 256-bit signatures, then I see little convincing reason to
> keep it around in addition to SHA-256.  For this reason, I recommend the
> following course of action:
>
>   1. Toke agrees to switch to 128-bit Blake2s signatures;

I think what would happen is that Bird would support both. It already
supports a whole bunch of other signature schemes (some of which, like
MD5, should probably not be used), and my patch adds support for both
blake2s and blake2b. I'll think about what the best UI for this is, and
ask the Bird devs as well I suppose.

-Toke