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

Antonin Décimo <> Fri, 06 November 2020 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11CFB3A0E23 for <>; Fri, 6 Nov 2020 15:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xYUWscTHn7j1 for <>; Fri, 6 Nov 2020 15:09:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F1593A0E22 for <>; Fri, 6 Nov 2020 15:09:27 -0800 (PST)
Received: by with SMTP id v5so2964730wmh.1 for <>; Fri, 06 Nov 2020 15:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:content-transfer-encoding:cc:subject:from:to:date :message-id:in-reply-to; bh=F2S318ofziTiDZu/pYTLTnqu+Wz7YDJ3ggnPisW7Z2o=; b=DlkSWVkR3y0yZf57JBT4EPxD6+YsXEU/zB8O63l2gPcFA7lPePnijBOirVfjCtqleY SNVdsIe+2j/rMxo/v4Lgm5/Y7wbckHeGc44xodmMNCsuzZqFLXHG6o/paxlA7v4a4wN/ wJYWPeUdPSSQeXJS1wvFS9YXeekEAtS00ZkdiZwXci4U32DGnbTWaMNDhSX75OOZS3vZ HLalV3QowBJwmilbY+SuD9LMn6meHiK+60zS0cKeOE5qnFytsVk2GKJmdGNpmmm5NYS4 ZWu24SYm5XMoWuP8HfeDGZQUx5vriOvFsQVA/s6+Y51rwKodvJC4Uuw58KK+QZbKTIZ0 w2qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:cc :subject:from:to:date:message-id:in-reply-to; bh=F2S318ofziTiDZu/pYTLTnqu+Wz7YDJ3ggnPisW7Z2o=; b=gzkd6538vRDkJYEVNiJo4gN2c9c23ivvJZF0eUfrTXUmW2VdIoVoHoBn06O86sTbnx dCUSy9zrSYwYzrjiuykXbB5HUm3pA+un5+tEWQl2hXirUULq0WTZA0duxj7jA+mV9MeG JJNGthWuG5ygwdU8YnKemipsqWKSWrkCErp2q/cFFtEF4z7r3dZwEmY3myEkWxxcBcGn XZQvDX5mQOm+waPLXfpqdGFxtmGKxr0Z0XHvsiI+yTO3Ixa3enyLhxt42j2PU/EPaU1R J29pbcTuAWuC7Wkn2MdoJF1VLO+t01GrcYDfin/UCtqZ9HBwd90/xhIZ79wdTZl+mfTV 58Ug==
X-Gm-Message-State: AOAM5334Pvewy9E8wk5hzhCqJSPM7Gq7pn28QQhtIw0qET5tZlQE3daw b7PCMrOYiF48QP41x0sAH8k=
X-Google-Smtp-Source: ABdhPJw+Nsc8na1Z1nm7QjLC5D3Ovo4XtRsK8vOU0iVrjfj2E+G8s2aRyvyOZTVsWZrE9VmyzPbLIw==
X-Received: by 2002:a1c:2108:: with SMTP id h8mr1858627wmh.63.1604704165869; Fri, 06 Nov 2020 15:09:25 -0800 (PST)
Received: from localhost ( []) by with ESMTPSA id a17sm4365601wra.61.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Nov 2020 15:09:25 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Cc: "Donald Eastlake" <>, "Valery Smyslov" <>, "Barbara Stark" <>
From: =?utf-8?q?Antonin_D=C3=A9cimo?= <>
To: =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <>, "Juliusz Chroboczek" <>, <>
Date: Fri, 06 Nov 2020 23:53:54 +0100
Message-Id: <C6WJTKSPAQRR.2P5VECMV63MAQ@kobain>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Nov 2020 23:09:34 -0000

> > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size
> > between 1 and 32 octets (8 and 256 bits).  However, both implementations
> > of Babel-MAC only ever produce 16-octet BLAKE2s hashes.
> Okay, something seemed off about this when I read it just now, so I just
> double checked: And in fact both implementations use 32-byte Blake2s
> digest sizes...

That also seemed off to me. To be fair regarding babeld, the "old"
hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We’re
using the reference blake2s implementation, and I changed 16 to the
provided BLAKE2S_OUTBYTES = 32 constant.

> I still support making the change and specifying the size, but to
> correspond to current implementation practice the change would need to
> be "with 256-bit (32 octet) hashes".

Me too. I an exchange earlier this year, Donald and Juliusz explained
to me that the size of the output hash is considered part of the
hashing algorithm, so yes, I support making that explicit for blake2s.

-- Antonin