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

Valery Smyslov <valery@smyslov.net> Wed, 18 November 2020 12:44 UTC

Return-Path: <valery@smyslov.net>
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 0C7203A1861 for <babel@ietfa.amsl.com>; Wed, 18 Nov 2020 04:44:27 -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=smyslov.net
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 xl3m0dlOApSb for <babel@ietfa.amsl.com>; Wed, 18 Nov 2020 04:44:25 -0800 (PST)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 B185B3A1831 for <babel@ietf.org>; Wed, 18 Nov 2020 04:44:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RCFTRErtUlSFVjZTjFAHLWO97Iu1aJJp+Vz9/dmMXsM=; b=QFPRlEDFHScOEOFvC3ZE/BOAR+ pcXTURhx+sxaIhNWSGNjhoAVLskIN2X+T6nKfFBLvs/lyhB5L//8Rq8wWcQTE6xNTG6fmm4qNtEtq wr7IAdgLnPm/NoOifbi/az9GqHb62zX+bcQHjAaDcCA6+k0cuwh0Lc5BVoYo0HyHBuyEk7SmWFK8r HF510vv8Qoe8AMLjFKlJE+Xifa08vb2Itawij4SBhDqZ5I7Y+vYXbjhMAxtw3QMjhP/cO7x1wes5D ylS3xonlUcTy6F/LIufBLR5Y+3knkcKeTc6gvDCY/nVY0ld9SNcz8+mdZ3/QtlPY13zcHKd7f5Wbi 67xJNdIQ==;
Received: from [93.188.44.203] (port=51715 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <valery@smyslov.net>) id 1kfMot-0004jP-Ke; Wed, 18 Nov 2020 07:44:20 -0500
From: "Valery Smyslov" <valery@smyslov.net>
To: "'Juliusz Chroboczek'" <jch@irif.fr>, =?iso-8859-1?Q?'Toke_H=F8iland-J=F8rgensen'?= <toke@toke.dk>
Cc: <babel@ietf.org>
References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr>
In-Reply-To: <878sazh7ge.wl-jch@irif.fr>
Date: Wed, 18 Nov 2020 15:44:18 +0300
Message-ID: <081e01d6bda8$8acc0470$a0640d50$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIBt3/S0skzJeVSyc6nHEpVtErVDwIUTv9yAdDdeJgBRMbiFQKRzd0zqTn78hA=
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/0sC7dRi6-LBvxSoTBIQdF1z0if0>
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: Wed, 18 Nov 2020 12:44:27 -0000

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