From nobody Fri Nov 6 17:53:07 2020 Return-Path: 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 2A16D3A0EC6 for ; Fri, 6 Nov 2020 17:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 VCSILz2-oCek for ; Fri, 6 Nov 2020 17:53:04 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 717DB3A0EC7 for ; Fri, 6 Nov 2020 17:53:04 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id o11so3408913ioo.11 for ; Fri, 06 Nov 2020 17:53:04 -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; bh=hq03YuQLWRl1Wq/IeIE8kuyHdpbPOTDArdYRLiY9O9M=; b=K7Wb5knRnzNBmu8Su5X47DPdV2wHnEbaIdEDdDVLT/KBsd1WacFDJrxKh/iOjjGjmE MvKwDYKJ/5D7LCSYNuPjn3QeNFrjCSb9LvLq3np8eNJlSQk1Wn+nZrRmoj2UXfH14ldo SqDt9ft7I2wCq1Rw8+1VABFe0v6a9Fo+aY8UMJ/vNtx8qkR0Jr2Q3NHwq+N+zw0qL+Es z3SRSzn1S+mHOVhXiSXfAD/yOr+vOHKqpwVweDpkMvP2/7BNx5pDjsPkvNUKyEhiLYEm Oo6LXLVdBGV3cxyGiVW1YzYB+UVUAV1U10HlXgC6kNzzk7KagcygbA3Z8maHNTixIjCf EC1Q== 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; bh=hq03YuQLWRl1Wq/IeIE8kuyHdpbPOTDArdYRLiY9O9M=; b=leNSFTmx+TLlkboS5eCiPBOEPjtvh+GcFMNSehlRd1sXrqHtId5HPqTushhRU+DIES IiMi3WJoLw191Qhwu2Gca6TpjwRqsODSdyaF197o5BioUwA278n7cddP/bC+Q0LDuL6q uZMJorM5sxbEMWzDAv2zYXAVvIM2jUjiqZJahgPeP4TagmiwqBe2mBPHcHTuvffpKtYp XHffbhhyLS/Tx2NNcuWhmLVhoBCLugOO2qfKnPQLYrST3RB9BGEScjn2/Mf6WVHlEuqW 0cbLgdrc3wgmqPGusIp71OkM+8pfKysxEqQKCgt8HRhri9E0qmI4md4RaR/9ugRtpQTG W0NQ== X-Gm-Message-State: AOAM532DUbWACkKJA5cjMo6jbUvnxEcO8QhOtpcIoaxi7/hTYGmk3W0P xYYPkl9xxM761u5NAlBAUcMLyB/FzFa5FHM0M5I= X-Google-Smtp-Source: ABdhPJw2nIcORq4QCgkjnKdYRdaZDK7UUio/r+Xm8LjwZnhi2VofYEAZl2q97Up40RyAbKGTZmf/d4pse/prlCqSw0Q= X-Received: by 2002:a02:b06:: with SMTP id 6mr4157354jad.115.1604713983458; Fri, 06 Nov 2020 17:53:03 -0800 (PST) MIME-Version: 1.0 References: <87h7q2f6a2.fsf@toke.dk> In-Reply-To: From: Donald Eastlake Date: Fri, 6 Nov 2020 20:52:52 -0500 Message-ID: To: David Schinazi Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Juliusz Chroboczek , Babel at IETF , Valery Smyslov , Barbara Stark Content-Type: multipart/alternative; boundary="000000000000f3417305b37a96f5" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 01:53:06 -0000 --000000000000f3417305b37a96f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess AUTH48 is probably the right time to do this. Speaking as a WG member, although my opinion is not very strong, I would suggest - SHOULD implement BLAKE2s with 32-octet hashes Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Nov 6, 2020 at 7:14 PM David Schinazi wrote: > Random thought: the draft mentions that the MAC algorithm > is configured alongside the key for it. Perhaps we should > add an explicit sentence such as "For MAC algorithms that > support multiple digest sizes (such as BLAKE2s), the digest > size needs to be communicated alongside the MAC algorithm.". > > I agree that the "SHOULD implement BLAKE2s" should > mention a key length, but I have no preference between: > - SHOULD implement BLAKE2s with 16-octet hashes > - SHOULD implement BLAKE2s with 32-octet hashes > - SHOULD implement BLAKE2s with both 16 and 32-octet hashes > > David > > On Fri, Nov 6, 2020 at 3:09 PM Antonin D=C3=A9cimo > wrote: > >> > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any si= ze >> > > between 1 and 32 octets (8 and 256 bits). However, both >> implementations >> > > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. >> > >> > Okay, something seemed off about this when I read it just now, so I ju= st >> > double checked: And in fact both implementations use 32-byte Blake2s >> > digest sizes... >> >> That also seemed off to me. To be fair regarding babeld, the "old" >> hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2= =80=99re >> using the reference blake2s implementation, and I changed 16 to the >> provided BLAKE2S_OUTBYTES =3D 32 constant. >> >> > I still support making the change and specifying the size, but to >> > correspond to current implementation practice the change would need to >> > be "with 256-bit (32 octet) hashes". >> >> Me too. I an exchange earlier this year, Donald and Juliusz explained >> to me that the size of the output hash is considered part of the >> hashing algorithm, so yes, I support making that explicit for blake2s. >> >> >> -- Antonin >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> > --000000000000f3417305b37a96f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess AUTH48 is probably the right time to do this.
=
Speaking as a WG member, although my opinion is not very str= ong, I would suggest
=C2=A0- SHOULD implement=C2=A0BLAKE2s with 3= 2-octet hashes

Thanks,
Donald
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2= =A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Fri, Nov 6, 2020 at 7:14 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Random = thought: the draft mentions that the MAC algorithm
is configured alongs= ide the key for it. Perhaps we should
add an explicit sentence su= ch as "For MAC algorithms that
support multiple digest sizes= (such as BLAKE2s), the digest
size needs to be communicated alon= gside the MAC algorithm.".

I agree that the &= quot;SHOULD implement BLAKE2s" should
mention a key length, = but I have no preference between:
- SHOULD implement=C2=A0BLAKE2s= with 16-octet hashes
- SHOULD implement=C2=A0BLAKE2s with 32-oct= et hashes
- SHOULD implement=C2=A0BLAKE2s with both 16 and 32= -octet hashes

David

On Fri, Nov 6, 2020 = at 3:09 PM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
> > As Valery Smyslov n= oted, BLAKE2s is able to produce hashes of any size
> > between 1 and 32 octets (8 and 256 bits).=C2=A0 However, both imp= lementations
> > of Babel-MAC only ever produce 16-octet BLAKE2s hashes.
>
> Okay, something seemed off about this when I read it just now, so I ju= st
> double checked: And in fact both implementations use 32-byte Blake2s > digest sizes...

That also seemed off to me. To be fair regarding babeld, the "old"= ;
hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2=80= =99re
using the reference blake2s implementation, and I changed 16 to the
provided BLAKE2S_OUTBYTES =3D 32 constant.

> I still support making the change and specifying the size, but to
> correspond to current implementation practice the change would need to=
> be "with 256-bit (32 octet) hashes".

Me too. I an exchange earlier this year, Donald and Juliusz explained
to me that the size of the output hash is considered part of the
hashing algorithm, so yes, I support making that explicit for blake2s.


-- Antonin

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000f3417305b37a96f5--