Re: [babel] [Babel-users] rather than ripemd160...

Toke Høiland-Jørgensen <toke@toke.dk> Mon, 26 November 2018 13:24 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 68EFE130DEC for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LFKGAG85mvhs for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:24:10 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD1412D4ED for <babel@ietf.org>; Mon, 26 Nov 2018 05:24:09 -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=1543238647; bh=/XFf+65ztvuNCiKelkImrBo0u5VtSkkMWsNDlqzke78=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JyTdl9d2wolp2l91DL/ynGHQUXJxOZBYAZIMrBHnawVd3YDS+BCp/hrqMoBflA5iJ sDQXQzYVJrPgmN8AyL4w1Irq6jzLBMvT5QDoI9TYsKD6IdhDibvCNKIj1S3nT2NvWj lW+8XWXOGTe+JqJzBxrU2jLueiFRPbzsIp8przLOrkZ4z3iEh6p/xalgqRMt7CLKVd 002SCM4vciDcgr6BhANuUhZH6ZqvPy583aQsWGoSydg76SQ1LQEDvZAn4JuvwFDFBn Kvo2iAyAAtQV+QvqI0cszWAT8dKHWn4dDlbhRrKQztE6ZWvqhfz8QLFQcp02ow/Tqd /w12Yep4S5rlw==
To: Juliusz Chroboczek <jch@irif.fr>, Dave Taht <dave.taht@gmail.com>
Cc: babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
In-Reply-To: <87in0koun6.wl-jch@irif.fr>
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr>
Date: Mon, 26 Nov 2018 14:24:07 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87in0kx98o.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/f0ASGrR9kF17iSSU5OZS2G3DiAo>
Subject: Re: [babel] [Babel-users] 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: Mon, 26 Nov 2018 13:24:13 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

>> Anyway, the default hash function is sha256 in the hmac-challenge
>> branch. I approve, there's hardware support for it, and if someone
>> breaks it, civilization collapses, so an alternate hmac is a "good to
>> have", and what's in that branch... is ripemd160.
>
> From a standardisation point of view:
>
>   - HMAC-SHA256 is Mandatory to Implement;
>   - implementation may implement other MAC algorithms, and since no
>     algorithm identifier is carried on the wire, doing that requires no
>     further standardisation action.
>
> From the point of view of the implementation, we need to clean up this
> code to remove the dependency on OpenSSL.  When we do that, we'll probably
> remove the HMAC-RIPEMD160 code, and leave just SHA256.  (Don't hold your
> breath, though -- it's exam season for both the girls and myself.)
>
> If we add another HMAC algorithm, we'll want to do it in agreement
> with Toke, so that both implementations implement the same set of HMAC
> algorithms.

Bird already supports HMAC using MD5, SHA1, SHA256, SHA384 and SHA512,
which is inherited by the Babel implementation. I am planning to add
blake2s to that when I get around to revising the HMAC patch (see
below).

>> Both blake and siphash seem like a superior choice for an alternate hmac
>> function to ripemd160. In particular blake is subject of its own RFC,
>> and comes in several clean highly optimized versions for x86 and arm
>> architectures.
>
> I hold no opinion on that at the current time, I'd need to consult my
> colleagues.

I happen to share Dave's concern about sha256. And basically all the
crypto people I've been talking to have been of the opinion that blake2s
is the way to go for low-powered devices. So I am definitely planning to
add an implementation of that to Bird, and may even make it the default
for Babel.

I'm not sure if we *can* make it MTI in the spec as well (does it need
to be defined by a standards track RFC for us to do that?), but if we
can, I think we should seriously consider it...

-Toke