Re: [babel] rather than ripemd160...

Juliusz Chroboczek <jch@irif.fr> Mon, 26 November 2018 13:06 UTC

Return-Path: <jch@irif.fr>
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 8EE6A12D4EA for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sE8v5q3r3Vef for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 05:06:45 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 EFF48124408 for <babel@ietf.org>; Mon, 26 Nov 2018 05:06:44 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wAQD6a7v002580; Mon, 26 Nov 2018 14:06:36 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7FB5063A1C; Mon, 26 Nov 2018 14:06:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id e_JgaCUzQHbq; Mon, 26 Nov 2018 14:06:37 +0100 (CET)
Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 67E1963A10; Mon, 26 Nov 2018 14:06:37 +0100 (CET)
Date: Mon, 26 Nov 2018 14:06:37 +0100
Message-ID: <87in0koun6.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Dave Taht <dave.taht@gmail.com>
Cc: babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
In-Reply-To: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com>
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 26 Nov 2018 14:06:36 +0100 (CET)
X-Miltered: at korolev with ID 5BFBEFDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5BFBEFDC.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5BFBEFDC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/bavDr38_jcu3k6J-Ne-o6XI6heA>
Subject: Re: [babel] 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:06:48 -0000

> 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.

> 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.

-- Juliusz