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

Dave Taht <dave.taht@gmail.com> Mon, 26 November 2018 13:46 UTC

Return-Path: <dave.taht@gmail.com>
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 E0874130DC9 for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 u9Yxzhxj2jS9 for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:46:49 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC8D126BED for <babel@ietf.org>; Mon, 26 Nov 2018 05:46:49 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id r14so17530838qtp.1 for <babel@ietf.org>; Mon, 26 Nov 2018 05:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=78vtr3Y6R4zIe6gzMk8WGCQJyn0I/F+UULX86TtXhh4=; b=GilmRJr/G+O56hnavqRshEFPRQtpQg1dIaXPF63kcf5J+pIaHYRQdIUZ5XLzve2t/U 7n5mn6LeDl7c2NeRZtHpCcSr459Q4zpgUq9gbSoTsTixIMAFhQ14IbS1G1LWNi96cwxC i908Rcpge2kUQ7CGVLeQDl23Ax75srg1P3GUHXfwRxczDC01SqL3Ml5FxzxwM0CrdZPI Yt3jF34aL+j6vtSV9KS9AbkchkvDV3lm3FtPSBLDR8DTkcpqMcksY8icSQCzf4eB7ZCJ cCMRjpGu4EmGIM/kGrECbTtr5PpYXv+M3fXQi/8v2rUZWFoOzcxHkinLhkP7puUI1tlv v73A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=78vtr3Y6R4zIe6gzMk8WGCQJyn0I/F+UULX86TtXhh4=; b=adb6uAuDKcu5LKyr1O+bNoN557SpFzRxQkI5ynUP24Mvo1w4Bz4KapJkegSn1eTBC3 mefyV0pfc11Zolm9sPvc4JAdhNpDbx8pModGFBoW0OAwvpz7fKbkLrTi55JL+UDxFW84 XAREv/75s2vjTZvVSvpig+zFPdUvB59xuoE/x0fUH3zMbvAjYB6D21O3SCZCoBaInASS j+ucTAHOBLs+vRkSkQoeCY4Sfwq6Zv4NgHkSFGitlOsa1PV/ok52Ilf5MKUaiMuF4YEe 4qE4XRefnsrUiAB9hhVxMQy4pQ2vKUBuSQz5M0GFfRXy0/0IbYebMDaH2yOtSrZSJ9TH rWlA==
X-Gm-Message-State: AGRZ1gJSaKu5lrWQT+YdNzx6+CrixEvcBiDmhh4HgHtf+BSuIZaJtLJJ 7jKkB04Jd9qBU0grQXJecm54Pv/4gHdSVToTn1EA1PSV
X-Google-Smtp-Source: AJdET5e1qdkA7gG5yMKOcPTRw5d3QIuCpgnpNI3XNmXtQcZQpM0CHFSmYCwPDPDMFQBGom95QG7mwm43GpXuaI7muBk=
X-Received: by 2002:ac8:326a:: with SMTP id y39mr26322282qta.175.1543240008261; Mon, 26 Nov 2018 05:46:48 -0800 (PST)
MIME-Version: 1.0
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk>
In-Reply-To: <87in0kx98o.fsf@toke.dk>
From: Dave Taht <dave.taht@gmail.com>
Date: Mon, 26 Nov 2018 05:46:36 -0800
Message-ID: <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>
Cc: Juliusz Chroboczek <jch@irif.fr>, babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/_vI_35OX5p1F8qbLfwliTvmCoOA>
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:46:52 -0000

On Mon, Nov 26, 2018 at 5:24 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> 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.

Well, I'd like to benchmark blake2b some also. The trendline IS
towards 64bits and mips is dying...

What's their definition of "low powered"? While blake2s is claimed to
work on 8 bit boxes, I don't see any of those on the internet. I
certainly see (as examples)
the esp32 (https://en.wikipedia.org/wiki/ESP32) as something that
would be cool to run babel on. (that one claims sha2 accelleration
also).

>
> I'm not sure if we *can* make it MTI in the spec as well (does it need

I'd like two hmacs to be MTI. As for the default... benchmarks on
cheap hardware are needed.

> to be defined by a standards track RFC for us to do that?), but if we
> can, I think we should seriously consider it...

I like having a backup plan so that in the rubble of civilization for
sha256's breakage, we can at least route packets.

https://tools.ietf.org/html/rfc7693 is informational. Is that good enough?



>
> -Toke



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740