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

Markus Stenberg <markus.stenberg@iki.fi> Fri, 30 November 2018 13:39 UTC

Return-Path: <fingon@kapsi.fi>
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 E71E11200B3 for <babel@ietfa.amsl.com>; Fri, 30 Nov 2018 05:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=kapsi.fi
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 qhDFQzPTc2B0 for <babel@ietfa.amsl.com>; Fri, 30 Nov 2018 05:39:45 -0800 (PST)
Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 25CF3123FFD for <babel@ietf.org>; Fri, 30 Nov 2018 05:39:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=NTpvfRipsk7kDtMEYcsXrNb40Grq744V3S4wiTgK72g=; b=nYxG8aRDWaEzG13R/w0yI4p6El wdOMlTgaW4647HuGdPp/fx3eIBxjeTpQNhY47c4UQ798YgFwpdO4OOTG1aFSmY4aB2B8TigzSg6+Z lQkKw7/SV778ZIjb2YBzbxnpvOsDO1BHb1ISptZSH8N3zSDrG1fIsJ3kWM4qRrOf9drNdTw8KNhLq CSYzblAK2HRyn/vINlgkQD2iej/QmFV6MIRcrAN1iQzv+N/4eX960/ZmVwHDMapoftHXvP8+uLSL9 slM7VvP2Ezd8xkZQjm1p1it6H1BAiDSGSWQ0HXmyRGmrAegG0Aq7aGVFoOznuOOBsLFi6viYJbIgz 1uvcVvMA==;
Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=yuri.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <markus.stenberg@iki.fi>) id 1gSj18-0006Ob-Va; Fri, 30 Nov 2018 15:39:39 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <87in0e6c6v.wl-jch@irif.fr>
Date: Fri, 30 Nov 2018 15:39:38 +0200
Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>, =?utf-8?Q?Dave_T=C3=A4ht?= <dave@taht.net>, Babel at IETF <babel@ietf.org>, babel-users <babel-users@lists.alioth.debian.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDC8196F-E623-4084-964D-9083D432C843@iki.fi>
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <CAPDSy+5QDu_kW-f=JWO1cPJJnDwDNpVwxwVC9SxfcE5+EOMpRg@mail.gmail.com> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> <87woouq24j.fsf@toke.dk> <87in0e6c6v.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.101.1)
X-SA-Exim-Connect-IP: 91.155.69.202
X-SA-Exim-Mail-From: markus.stenberg@iki.fi
X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/NyEzSvuNvZzWudFES5z2_9FMFRs>
Subject: Re: [babel] Blake2S, blake2B or neither? [was: rather than ripemd160...]
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: Fri, 30 Nov 2018 13:39:48 -0000

> On 30 Nov 2018, at 13.23, Juliusz Chroboczek <jch@irif.fr> 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:
> 
>  (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 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.
> 
> In either case, I'm planning to implement SHA256, Blake2B and Blake2S in
> the reference implementation.

I do not actually recommend 2B based on the numbers. By looking at them, you notice that the setup time for 2B is higher and even on 64bit platform the gain is not insane even on large operations (25%ish, perhaps). -2BP is what I have and will recommend for large bulk hashing (-P variant allows for paralllelization of hashing to multiple cores), but for smaller stuff it seems Blake2S is faster on both 32 and 64bit.

As they are all based on same cryptographic base, it is likely that if weakness is found in one, it is present in others. That said, as BLAKE algorithm was at the time of SHA-3 contest analyzed to be strictly superior to SHA-2 in some features, it seems unlikely. But you never know.

The above discussion cuts out options 3 and 4 for me.

I am mostly indifferent between 1 and 2; SHA256 (especially with hardware acceleration) is probably faster than Blake (even with just Intel optimized assembler it is 60-70% of Blake 2B), and if we’re talking millions of pps (acceleration present) it is entirely academic anyway for a routing protocol. The tinfoil hat argument for 2 is that it provides fallback if SHA256 breaks down somehow in the future. So I have SLIGHT preference for 2 but am happy enough with 1 as well.

Cheers,

-Markus