From nobody Wed Dec 16 06:58:25 2020 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA34F3A0ECA for ; Wed, 16 Dec 2020 06:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 m3uJ-IIoTw_N for ; Wed, 16 Dec 2020 06:58:23 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 E5CA53A0EC8 for ; Wed, 16 Dec 2020 06:58:22 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id m12so49096495lfo.7 for ; Wed, 16 Dec 2020 06:58:22 -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=FHywuoNErtGW4kUtLplTibYZ9MrxoQnHC6tJsZhJGTY=; b=ANIcJV6CSWZr37mGeaizh2rEq8Br4zbvGi3wJdXE4/SN2erPZdPj5aduLDtCkOkufT 9Zhx99qe2+KU95m3a/O4rKNCMWR3dOPGx6o0vGjh3dKAtykzGpbRkb4UnrfBNus6OC6x OUu6ZU1SIXl++ILy+v4ePqjVxzZRYZtF9lAea2dR70opK5ReudfOcjDTUg8hsOGVdmzj oR0XanzsoNZLyi4Cqnt5+++BMXG7iQzMtHseybDkTFjfEaueQSOiL+mVPcGikVoOkuo6 tPyPUHmboLqi+vD+s6MqSWJrc0XoLqs9VHfHyLWpxjfJB1fC2nQC1l9qPi9qo7ioFbUz bD7Q== 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=FHywuoNErtGW4kUtLplTibYZ9MrxoQnHC6tJsZhJGTY=; b=se1nTMO4+vX4camwCO7l8yotZx+VTwTXJQYfqQ1OmNPXpnSAVgXZk/XQAop/rqsxDR Ggt4Lx25xjxAiQ/RjjH9k8Tqr6u6N8w3v0ySZRN3HPeEn9QTb6x0onlrSsGsi3BO1YUO naULA6rmC92w5iV+zQlUXADA6u1Vy2QB6GhTuc77fBPcPg4HgdaCC5eNpyBMWftHlnzu oyOO2/L3FF1tktPqy+3RjjoCkVi78qPgXWD+UxqWM/Tga7mgasSQPN9BadgijjZInYu4 jJeSysqoWJiYLZmE6xu0qAZnnwG9vB5wvhPXBAa8waXxG+TaKDf8a+87xxZH1NB3icGu U5Jg== X-Gm-Message-State: AOAM530+kd4Ep0nRMTcNWU8CaAoiAwPlcKUuuCe53Vrz78Gsj6JUZ0nr 6OzCOnheaWwb71vN7QICE7rBe6nwMMc7Hp7juJE= X-Google-Smtp-Source: ABdhPJyHqYpfwkICyxx6R5pFnX8sdkFAIl+UIHGVUnT/4L23IUwP+TSRoWogtms5NN+FruJeTfeTmEQ7zW6N9WIpiXs= X-Received: by 2002:a2e:b548:: with SMTP id a8mr14381831ljn.83.1608130700832; Wed, 16 Dec 2020 06:58:20 -0800 (PST) MIME-Version: 1.0 References: <20201216000229.GG64351@kduck.mit.edu> In-Reply-To: <20201216000229.GG64351@kduck.mit.edu> From: Jean-Philippe Aumasson Date: Wed, 16 Dec 2020 15:58:08 +0100 Message-ID: To: Benjamin Kaduk Cc: cfrg@ietf.org Content-Type: multipart/alternative; boundary="0000000000002cfc9305b6961b24" Archived-At: Subject: Re: [CFRG] SipHash recommendation? X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 14:58:25 -0000 --0000000000002cfc9305b6961b24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SipHash co-author here, that draft uses the 2-4 versions (like the Linux kernel, https://www.kernel.org/doc/html/latest/security/siphash.html), which has lower security margin than 4-8, but I=E2=80=99m not aware of any cryptanaly= sis result that would affect any of these in the context of this proposed application. On Wed 16 Dec 2020 at 01:03, Benjamin Kaduk wrote: > Hi all, > > We have a document (draft-ietf-dnsop-server-cookies) in front of the IESG > that proposes to use the SipHash-2-4 algorithm > (https://www.aumasson.jp/siphash/, > https://www.aumasson.jp/siphash/siphash.pdf) as a MAC over what is in som= e > sense a return-routability and freshness token, the "DNS cookie" original= ly > specified in RFC 7873. > > Unfortunately, the authors of this draft have not yet written down a clea= r > description of what properties they believe are needed from this MAC for > this usage, which makes it slightly hard to confirm that SipHash is a > suitable algorithm for this purpose, though that is certainly a question > that I am interested in. > > Regardless of that, I would also like to get the CFRG's input on whether > SipHash is a suitable algorithm for its stated goals (paraphrasing > slightly): a performant keyed (family of) PRF suitable for use as a MAC, > with the security goal for a MAC being considered to be that an attacker, > even after seeing tags for many messages (perhaps selected by the > attacker), is unable to guess tags for any other messages. > > In short: is SipHash fit for this purpose? > > There does seem to be a decent amount of literature analyzing SipHash, bu= t > I have not attempted to review it to any significant degree. > > Thanks, > > Ben > > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --0000000000002cfc9305b6961b24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SipHash co-author here, that draft uses the 2-4 versions = (like the Linux kernel,=C2=A0
https://www.kernel.org/doc/htm= l/latest/security/siphash.html), which has lower security margin than 4= -8, but I=E2=80=99m not aware of any cryptanalysis result that would affect= any of these in the context of this proposed application.



On Wed 16 Dec 2020 at 01:= 03, Benjamin Kaduk <kaduk@mit.edu&g= t; wrote:
Hi all,

We have a document (draft-ietf-dnsop-server-cookies) in front of the IESG that proposes to use the SipHash-2-4 algorithm
(https://www.aumasson.jp/siphash/,
https://www.aumasson.jp/siphash/siphash.pdf) as a MAC= over what is in some
sense a return-routability and freshness token, the "DNS cookie" = originally
specified in RFC 7873.

Unfortunately, the authors of this draft have not yet written down a clear<= br> description of what properties they believe are needed from this MAC for this usage, which makes it slightly hard to confirm that SipHash is a
suitable algorithm for this purpose, though that is certainly a question that I am interested in.

Regardless of that, I would also like to get the CFRG's input on whethe= r
SipHash is a suitable algorithm for its stated goals (paraphrasing
slightly): a performant keyed (family of) PRF suitable for use as a MAC, with the security goal for a MAC being considered to be that an attacker, even after seeing tags for many messages (perhaps selected by the
attacker), is unable to guess tags for any other messages.

In short: is SipHash fit for this purpose?

There does seem to be a decent amount of literature analyzing SipHash, but<= br> I have not attempted to review it to any significant degree.

Thanks,

Ben

_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--0000000000002cfc9305b6961b24--