From nobody Thu Feb 6 22:50:18 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436F51201AA for ; Thu, 6 Feb 2020 22:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 yJkqzDHpz4Vp for ; Thu, 6 Feb 2020 22:50:13 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 5F4E2120164 for ; Thu, 6 Feb 2020 22:50:13 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id h23so910791ljc.8 for ; Thu, 06 Feb 2020 22:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=liLCOcESvwJLeuAPP3TMkZwMrko2smXlpRvYnSK/47o=; b=BrIpjwkvRr3qxIx3GjHc+EuTFgd7LZZFgryzROFgfRdQAaoS5EzDjHd0o3w6vJhQTQ IK3MHN5f/Wry8uENukVNc6DAOUVZESlZa0Gzc43qOiz6cIwn3nPQVOjvb1sdvmBhgrol rjr/K8BSjKnyjDsAhIAvGQuQMOHkMbA37HYuJWlKW19tFj+0NbVR+IHKWDbNpqA9ue9W b8jZCrxZO4WjOgvMCicSW82KaNU550EGX4WOzLHfdMbBDTD2RALfa1FXlC+O3cE8ub1i 75G+LqPPqcQD8akTV2oh1xdrWP6W/mxLEKqQ3KlbWeCBG+M4rIpre+zcIKTb6mM988DY nSoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=liLCOcESvwJLeuAPP3TMkZwMrko2smXlpRvYnSK/47o=; b=tK5yAva307pvOgx4hoRgXS/TRQluDg4r77RAAHChcRRrYJ2nigx/BzIrNn2svazWJN bVqq0rlmNJ48A4ZpsHJj7woEeH3/Cj6EjfNFnobimvRvzuKLw41drs/OGIiFdkCiAb4z pf4OtpApTp9L34m3QMG3Vaa1Db8spqopSmQE4fcJqNjqbgMCqX6uyzgQA5UVzX7wUzRv 6UV8nXSjNrCRdcQ3EfgCH47qLP534dBsWk3nUey59u5WVHxxg0v/0kL91lzGUoJGCy7M W3CgEYOndvaHPOe9xXH8kJwXBlLX3YDl3hHpz59A8sycPXlAQvYEFm9gvXw/OUpzdLZh PJEw== X-Gm-Message-State: APjAAAXEbLB8hI8QHzvnLtvhdZiKoXFU1FpwvbTsIHftC+wk1mLoci1S quubW2vZe2yEt9lG/eIISRHuD1luYNPqe36c3+Q= X-Google-Smtp-Source: APXvYqz4VmwACE3lEYiSFua0WAcCKPR6QkKI2Rlxiqt4UM6iXgsnw6HiCaznBAZIGQUHVQolfBPB6BCb6k+Z4B+JuP4= X-Received: by 2002:a2e:8758:: with SMTP id q24mr4499227ljj.157.1581058211492; Thu, 06 Feb 2020 22:50:11 -0800 (PST) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Fri, 7 Feb 2020 09:51:18 +0300 Message-ID: To: Jean-Philippe Aumasson Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000010b5c5059df6cd36" Archived-At: Subject: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 06:50:16 -0000 --00000000000010b5c5059df6cd36 Content-Type: text/plain; charset="UTF-8" Dear Jean-Philippe, As we discussed yesterday with Alexey and Nick, we would like to ask you about reviewing the current version of draft-irtf-cfrg-kangarootwelve ( https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could you consider the possibility of providing such a review? Of course, we will be happy to receive reviews from all Crypto Review Panel members. Regards, Stanislav (on behalf of the CFRG chairs) --00000000000010b5c5059df6cd36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jean-Philippe,

As we discussed ye= sterday with Alexey and Nick, we would like to ask you about reviewing the = current version of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatrack= er.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could you consider th= e possibility of providing such a review?

Of cours= e, we will be happy to receive reviews from all Crypto Review Panel members= .

Regards,
Stanislav (on behalf of t= he CFRG chairs)

--00000000000010b5c5059df6cd36-- From nobody Thu Feb 6 23:27:30 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B33120858 for ; Thu, 6 Feb 2020 23:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 y-Eg8IC0KaEo for ; Thu, 6 Feb 2020 23:27:26 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 C14BF120853 for ; Thu, 6 Feb 2020 23:27:25 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id m16so1367144wrx.11 for ; Thu, 06 Feb 2020 23:27:25 -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=MlozkGcYV+qRkuTFFZjOzrGeMzzNfJ21D/hs5walhpQ=; b=ZEcOLipwxTwkmL6shKyIuf91H7pGRUCcrwbWyiREkFyJj8iTbA5dJ31CFUWrDSGbsN 5Bxdb3iwsn1dpkdfSIPPW+/kROMcIpnbien6QXWOa2trY6wq9dObufpec8txs72qStuH XMpPyDIOE+a8pIAYhAmj9yWr7QJdn16q9E03CrsoeOAYwyGjJsiWdXjwjszWRtcgF1JE vrVcK9/izhvby0R/AbxmIXXZI2+ybPpRi42OKIIkPXUREPh8LvGs+E61kXzwlkZe9CBw Q+9iUtMLXrJwKhHXVrQiE7PcaFM2TRdddcBKeK50i8zpBzLHTQ6Dtop7MXWRwaHVoF4m 1n0Q== 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=MlozkGcYV+qRkuTFFZjOzrGeMzzNfJ21D/hs5walhpQ=; b=dhqLeArr2IHkg2LkZWKnA7mHCAZnJWdreWfomBX3ii6pOwDQcbCxPAtkV1371Hu46P n8KDZHNjqjI5SAW2SKX1faqjFnclZ5u4PZoXFp52X7q2Ae2pjulnpKsKwoHVVtLuUf5X zhdfmV92y4wylK/SMMg49+wV6v1FasBrGeVEvgFXub3q49/CFuO08pW2mE8lhceSAvTk 9n8LlE57BeVLHvqdF7oX1mvOTcfOdiA9RauxOdLOyMQsTLg5i4R6NXucjasV04QMqi8O fM1UCUj0y58mGm5YUZ5/SVrTEpH6Ldk5C2F52/fLZ9VdMPxA1hAQt/A8N0onodcjgtwL 2RRQ== X-Gm-Message-State: APjAAAXKJpPbklO/bYoyFY8fWThnUCFFTerFK6DFERZpAIlIXMh/BBNx ntdoFtOFPrAtN9nvDP05anOtKU0iT9P7lM1w07I= X-Google-Smtp-Source: APXvYqzHusu+mFFEHl3Mm8mzVZ1oB7Say+Nbii0jE2wM+eptGP5MhM4RqXGe/yUDx6rGGqir9vg/gald4UKmoOg8W+c= X-Received: by 2002:a5d:6ac4:: with SMTP id u4mr2947097wrw.318.1581060444226; Thu, 06 Feb 2020 23:27:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Fri, 7 Feb 2020 08:27:13 +0100 Message-ID: To: "Stanislav V. Smyshlyaev" Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000258a8e059df752df" Archived-At: Subject: Re: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 07:27:28 -0000 --000000000000258a8e059df752df Content-Type: text/plain; charset="UTF-8" Hi! sure, but conflict-of-interest warning: I'm a co-designer of BLAKE3 ( https://blake3.io), a function that can be seen as a competitor of K12 in the super-fast, parallel hash category. I can do the review as objectively as I can but could understand that the CoI might be a concern for some (including the draft authors). wdyt? Cheers, JP On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev wrote: > Dear Jean-Philippe, > > As we discussed yesterday with Alexey and Nick, we would like to ask you > about reviewing the current version of draft-irtf-cfrg-kangarootwelve ( > https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could > you consider the possibility of providing such a review? > > Of course, we will be happy to receive reviews from all Crypto Review > Panel members. > > Regards, > Stanislav (on behalf of the CFRG chairs) > > --000000000000258a8e059df752df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

sure, but conflict-of-interest warn= ing: I'm a co-designer of BLAKE3 (https:/= /blake3.io), a function that can be seen as a competitor of K12 in the = super-fast, parallel hash category. I can do the review as objectively as I= can but could understand that the CoI might be a concern for some (includi= ng the draft authors).

wdyt?

<= div>Cheers,

JP

On Fri, Feb 7, 2020 at 7:50 AM= Stanislav V. Smyshlyaev <smyshsv@g= mail.com> wrote:
Dear Jean-Philippe,

As we disc= ussed yesterday with Alexey and Nick, we would like to ask you about review= ing the current version of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could you consider the possibility of providing such a review?


Stanislav (on behalf of the CFRG chairs)

--000000000000258a8e059df752df-- From nobody Thu Feb 6 23:50:25 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62912013B for ; Thu, 6 Feb 2020 23:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ryJVVcwNcks0 for ; Thu, 6 Feb 2020 23:50:20 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 727FE12003E for ; Thu, 6 Feb 2020 23:50:20 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id o15so1072782ljg.6 for ; Thu, 06 Feb 2020 23:50:20 -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=hfXYxSDBv58sIq/jbnRRWeiQotDYijT3Q3OnSpB3HZw=; b=ZkbLopdh72qwAGin9jNrBoJNhFww5Cydq2cxzxK/Nj22XE9F6o7YcOzCA8aWmlV0tX I3bKnSrAV9DB8fS19C+tW+UNawofvxiN5Ab48uvNwkjUam1M33zChYfVZtKF5zWCoeVh H2h+ynKiNOIIEE0bSBibqa25+GVYLPzs8YiZL0jP//U0tExeSSQJH7N7mjpiOY42p9kq KEbf4lqhHs2E6X1j7nnKAVIvYGpCXpTyeOJG3UByR4rYGF2CESTniil3xIhwx6t1fR+U MciqTogxKMYHuQ+NvSRcNUIaXi9w/vjrUUrcm9Lq6x+QnLAXz1k3LCvC9BIkktBvy3v5 97Pg== 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=hfXYxSDBv58sIq/jbnRRWeiQotDYijT3Q3OnSpB3HZw=; b=OSGG20SPwJUPhkaZ2RrqowMXTJ1r8FfTcKBsovJ/O/NijvNvf2D6GJWVGIB8tTJgHR 89uU8RO4owsnOor0u+rQU3TKaj2pWJakcSmndLh2PhnmuAMbVS1iEWP7hVWfOQbaW8Ge ZOaC/qW2xpHXhOrAIy9n4vYtsSnn/Y9xMcLTrZ0ydP9rPEj82i+bAkUyCTiLG4W01ait e1vJjlkR6+AyXtrwmHkjXpyh28IkJR52BlEFgbK9GirBbrleopDYLjVbgrEDd1Zgom+L ey+lyalTCtG8mEcNcgFI353rLRbFnQVrlMj7v+swXKEcJ5U/e3vkl3nLdXQ9sj4D1YEU 8IEA== X-Gm-Message-State: APjAAAUevc/LdT7D57MBQoT3hu98mIDlFN8V90GjuSx9os37+VDTvC18 Dk0AD8X0Ux3g9UDyihxGN3FFsn52TsPJXhaxcmw= X-Google-Smtp-Source: APXvYqyeMoIAlWj3blIZJq4Fva6UfV8jwJ0g4CoBO8rRGgfVtknOfq/hg278nA0h1ZVQW8i+O83M85+bWVLPp4/AnfU= X-Received: by 2002:a2e:9e55:: with SMTP id g21mr4576676ljk.245.1581061818617; Thu, 06 Feb 2020 23:50:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Fri, 7 Feb 2020 10:51:26 +0300 Message-ID: To: Jean-Philippe Aumasson Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001114b1059df7a4b4" Archived-At: Subject: Re: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 07:50:24 -0000 --0000000000001114b1059df7a4b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jean-Philippe, Many thanks for your reply, your readiness to do a review and for the warning! Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto Re= view Panel reviews for the draft-irtf-cfrg-kangarootwelve draft can be considered as independent opinions of the experts, that can help to highlight possible problems with the document (and can be disputed later by the authors). In my personal opinion (with my CFRG chair hat off), if you mention conflict-of-interest warning in your review, that will be enough. Regards, Stanislav On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumasson < jeanphilippe.aumasson@gmail.com> wrote: > Hi! > > sure, but conflict-of-interest warning: I'm a co-designer of BLAKE3 ( > https://blake3.io), a function that can be seen as a competitor of K12 in > the super-fast, parallel hash category. I can do the review as objectivel= y > as I can but could understand that the CoI might be a concern for some > (including the draft authors). > > wdyt? > > Cheers, > > JP > > On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev > wrote: > >> Dear Jean-Philippe, >> >> As we discussed yesterday with Alexey and Nick, we would like to ask you >> about reviewing the current version of draft-irtf-cfrg-kangarootwelve ( >> https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could >> you consider the possibility of providing such a review? >> >> Of course, we will be happy to receive reviews from all Crypto Review >> Panel members. >> >> Regards, >> Stanislav (on behalf of the CFRG chairs) >> >> --0000000000001114b1059df7a4b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jean-Philippe,

Many thanks for you= r reply, your readiness to do a review and for the warning!=C2=A0
Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto R= eview Panel reviews for the=20 draft-irtf-cfrg-kangarootwelve draft can be considered as independent opinions of the experts, that can he= lp to highlight possible problems with the document (and can be disputed la= ter by the authors).

In my personal opinion (w= ith my CFRG chair hat off), if you mention=C2=A0conflict-of-interest warnin= g in your review, that will be enough.

Regards= ,
Stanislav

On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumas= son <jeanphilippe.aum= asson@gmail.com> wrote:
Hi!

sure, but conflict-o= f-interest warning: I'm a co-designer of BLAKE3 (https://blake3.io), a function that can be se= en as a competitor of K12 in the super-fast, parallel hash category. I can = do the review as objectively as I can but could understand that the CoI mig= ht be a concern for some (including the draft authors).

wdyt?

Cheers,

JP

On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:<= br>
Dear Jean-Philippe,

As we discussed yesterday with Ale= xey and Nick, we would like to ask you about reviewing the current version = of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatra= cker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). Could you consider = the possibility of providing such a review?

Of cou= rse, we will be happy to receive reviews from all Crypto Review Panel membe= rs.

Regards,
Stanislav (on behalf of= the CFRG chairs)

--0000000000001114b1059df7a4b4-- From nobody Thu Feb 6 23:59:25 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC2A120120 for ; Thu, 6 Feb 2020 23:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 0ALTOv8NHFaj for ; Thu, 6 Feb 2020 23:59:22 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 E11B612003E for ; Thu, 6 Feb 2020 23:59:21 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id p9so1538753wmc.2 for ; Thu, 06 Feb 2020 23:59:21 -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=OA1qpD1JvTTE4CQt0ThJkft8BMk8oaaIo0003rzDPtA=; b=ryfx8PoazDl4415whxxofuCSmmT+0p62Q9cI+hLqJx4OO9KK8fQPtkxC1KtLgCVCpa QUCS5GDC/Ma8NYcS4b+FaQmEO5YZ6Rqt7GKxoo2vm/ZyzuhhmnoBgp0yQBNBz0Qp9d/I MFCZTkE7mtdp8lnnydPF1uBc17g8ldxtij8kBu+aaDQBz6SP5zjKYQagvWrr4kOj9JMR o47dUJhhNT0rD90NQBuIxRo93xPb4kYbkB1rTWUDZyHy50TZaN4FrFpWDocLM5exVcS9 gGY2It4rYoRttfFcFtRb6E/BIaCAmucsb9zQ7dvbNgUSy4doMbwyVGZll3Ts5BzBOlQJ ajmA== 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=OA1qpD1JvTTE4CQt0ThJkft8BMk8oaaIo0003rzDPtA=; b=fXNV5tkTtq2imRzXhxfScNzZ5MHXv+TxgHPZLWVyrD03ccOHeQgpTTsGu5MOgC4y6y NbNJJ1pzJEyfK4shBs7ChkHtnXQ3jKZcy9sUeWI3lEhDtqJgnZOJJLihOTgJ1LMIxL1b hYLxadt8CI0DMwwcXo+AjFAP2zLaWCACQpbXhNwSWG1g1C+whskO+MY+CutiHzULXSWq gtQVslEeB/fb4OYZkc9HWycw7s+aCqGrfAKL4HFDiK2afElSDz62cax9lns6hKmvlefX 3TCpv3AXCnWNBcsglbSpSrYa5eDcTYo+yjPkv2uAyc1ZZWuuRrv23SdBW1vhs3/eaLB4 SQwg== X-Gm-Message-State: APjAAAXpVxUOK5EPhkdrHaDxw18IseUHQJc3qpy9vhj101aLQ9ND2Bou Y/O7RGrbzm7DkDdxutY1VvAalEKkWG2FXJ2s88/EVbcu X-Google-Smtp-Source: APXvYqz8GSPKUdC5GF4ZEGEIRXATELbIYYLm6cvceBKoVTJoV275oF2SWQkWk0Wnel1nKDLTVwqXRMbS44MG7yYdXvg= X-Received: by 2002:a05:600c:2c41:: with SMTP id r1mr2739436wmg.57.1581062360366; Thu, 06 Feb 2020 23:59:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Fri, 7 Feb 2020 08:59:09 +0100 Message-ID: To: "Stanislav V. Smyshlyaev" Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005b8520059df7c4c8" Archived-At: Subject: Re: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 07:59:24 -0000 --0000000000005b8520059df7c4c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds good :) I'm familiar with CFRG's goal but as it's my first review, wanna make sure that we agree on the goals: do these include.. ? 1. technical correctness of the document 2. editorial quality 3. value of the content against alternative solutions 4. relevance of the topic wrt CFRG's goals Thanks! On Fri, Feb 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev wrote: > Dear Jean-Philippe, > > Many thanks for your reply, your readiness to do a review and for the > warning! > Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto = Review > Panel reviews for the draft-irtf-cfrg-kangarootwelve draft can be > considered as independent opinions of the experts, that can help to > highlight possible problems with the document (and can be disputed later = by > the authors). > > In my personal opinion (with my CFRG chair hat off), if you > mention conflict-of-interest warning in your review, that will be enough. > > Regards, > Stanislav > > On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumasson < > jeanphilippe.aumasson@gmail.com> wrote: > >> Hi! >> >> sure, but conflict-of-interest warning: I'm a co-designer of BLAKE3 ( >> https://blake3.io), a function that can be seen as a competitor of K12 >> in the super-fast, parallel hash category. I can do the review as >> objectively as I can but could understand that the CoI might be a concer= n >> for some (including the draft authors). >> >> wdyt? >> >> Cheers, >> >> JP >> >> On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev >> wrote: >> >>> Dear Jean-Philippe, >>> >>> As we discussed yesterday with Alexey and Nick, we would like to ask yo= u >>> about reviewing the current version of draft-irtf-cfrg-kangarootwelve ( >>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). >>> Could you consider the possibility of providing such a review? >>> >>> Of course, we will be happy to receive reviews from all Crypto Review >>> Panel members. >>> >>> Regards, >>> Stanislav (on behalf of the CFRG chairs) >>> >>> --0000000000005b8520059df7c4c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good :)

I'm famil= iar with CFRG's goal but as it's my first review, wanna make sure t= hat we agree on the goals: do these include.. ?

1.= technical correctness of the document
2. editorial quality
=
3. value of the content against alternative solutions
4. rel= evance of the topic wrt CFRG's goals

Thanks!


On Fri, Feb 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev &= lt;smyshsv@gmail.com= > wrote:
=
Dear Jean-Philippe,

Many thanks for you= r reply, your readiness to do a review and for the warning!=C2=A0
Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto R= eview Panel reviews for the=20 draft-irtf-cfrg-kangarootwelve draft can be considered as independent opinions of the experts, that can he= lp to highlight possible problems with the document (and can be disputed la= ter by the authors).

In my personal opinion (w= ith my CFRG chair hat off), if you mention=C2=A0conflict-of-interest warnin= g in your review, that will be enough.

Regards= ,
Stanislav

On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumas= son <jeanphilippe.aumasson@gmail.com> wrote:
Hi!

su= re, but conflict-of-interest warning: I'm a co-designer of BLAKE3 (https://blake3.io), a funct= ion that can be seen as a competitor of K12 in the super-fast, parallel has= h category. I can do the review as objectively as I can but could understan= d that the CoI might be a concern for some (including the draft authors).

wdyt?

Cheers,
JP

On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev= <smyshsv@gmail.c= om> wrote:
Dear Jean-Philippe,

As we discussed = yesterday with Alexey and Nick, we would like to ask you about reviewing th= e current version of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). C= ould you consider the possibility of providing such a review?
Of course, we will be happy to receive reviews from all Crypto = Review Panel members.

Regards,
Stani= slav (on behalf of the CFRG chairs)

--0000000000005b8520059df7c4c8-- From nobody Fri Feb 7 00:02:50 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC3120120 for ; Fri, 7 Feb 2020 00:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 F1UuqvD99pBk for ; Fri, 7 Feb 2020 00:02:47 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 0D0431200B4 for ; Fri, 7 Feb 2020 00:02:47 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id r19so1118412ljg.3 for ; Fri, 07 Feb 2020 00:02:46 -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=B2QWXa4VdVQ7ZfhwazcwtfjSS0ZDXny1G6ldFzU/NOo=; b=Ws7dHBwi1exI2Z1Z1G1gjIfyYhp6Ntd9RrAc+AO4V1VTbG70+s9uy7hYBlq7PNRuxV 7r3KuD9NnVkP3HguSXun2j+flp1w+RkbMisPedU1AXA4nPMTQMaW+cVaG8aXlS2dShdk UqiDNqp2rhYjwlF+WAJbY8vnt8+cZFpVTFFy8N8sn0vmaUaWoYQMJcz6mCRfLYHqbge1 jZlg4i6sp/yqOB+h0Tv2hhT9sWVW0ZrJnwxkOjHwQImOxodUaIgZIghZqxI0IOUjFjPk kWsXswpLN+JQemLdbkKQJylwXL/X9uT6oMT6jJAZmoFPMO12jdWvWmhNG6FuCC2E3Ubr G5eA== 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=B2QWXa4VdVQ7ZfhwazcwtfjSS0ZDXny1G6ldFzU/NOo=; b=NPUff+ih1TO7hyT59A1boGvP7yisxtVb4Da1+2BIkr73z+javluf5EUNWRyZopSp6Q aP4gZ93JJi/T0KHTYng0vkNCkgcdvOQCH2OJC+vOfvvmSNFcOSIJwzdzKKom7BDRSFA0 YRc3RCEv46hX33l8a0V8j+0hQyhIlouZwKfKwJssGcVit/ITd00jIf+ArUWjlrmO3aIg TPMMx7emQoM65vOAGWy6bmmQ5n0L2VeKXUS2CxKMTKa5NxzI1BW4EDQl3+YR4TYgoQt9 hIl4KDTu8QOJjIt4gSgozPgJFM45KZ9053YBs31vFHWjS4jlluw/hnmqXniuFoZMuVWT QeBQ== X-Gm-Message-State: APjAAAUTSyevGV3vhIKSgEegFj2NF6SErqUBWgPLzw9RMalwy5re72hz xsTJAThVhXyJziOYo67B/wxJ1cOTlOpHwX5wkFU= X-Google-Smtp-Source: APXvYqxvnKX14AMmp2m+zbHUfhH3EzzZjFNzGg77accvDYL4O0KGIHo8E+EAMp5IRHJMcbqaFglEWtv4xB7aBsHKlNo= X-Received: by 2002:a2e:880a:: with SMTP id x10mr4666969ljh.211.1581062565219; Fri, 07 Feb 2020 00:02:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Fri, 7 Feb 2020 11:03:52 +0300 Message-ID: To: Jean-Philippe Aumasson Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009151a5059df7d071" Archived-At: Subject: Re: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 08:02:49 -0000 --0000000000009151a5059df7d071 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, but since the document has already been adopted as a RG item, I think that "relevance of the topic wrt CFRG's goals" is not necessary. Nevertheless, all comments are always welcome - in any case, additional discussions during/after Research Group Last Call can be even more productive if many important points are highlighted by the review(s). Regards, Stanislav On Fri, 7 Feb 2020 at 10:59, Jean-Philippe Aumasson < jeanphilippe.aumasson@gmail.com> wrote: > Sounds good :) > > I'm familiar with CFRG's goal but as it's my first review, wanna make sur= e > that we agree on the goals: do these include.. ? > > 1. technical correctness of the document > 2. editorial quality > 3. value of the content against alternative solutions > 4. relevance of the topic wrt CFRG's goals > > Thanks! > > > On Fri, Feb 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev > wrote: > >> Dear Jean-Philippe, >> >> Many thanks for your reply, your readiness to do a review and for the >> warning! >> Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto= Review >> Panel reviews for the draft-irtf-cfrg-kangarootwelve draft can be >> considered as independent opinions of the experts, that can help to >> highlight possible problems with the document (and can be disputed later= by >> the authors). >> >> In my personal opinion (with my CFRG chair hat off), if you >> mention conflict-of-interest warning in your review, that will be enough= . >> >> Regards, >> Stanislav >> >> On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumasson < >> jeanphilippe.aumasson@gmail.com> wrote: >> >>> Hi! >>> >>> sure, but conflict-of-interest warning: I'm a co-designer of BLAKE3 ( >>> https://blake3.io), a function that can be seen as a competitor of K12 >>> in the super-fast, parallel hash category. I can do the review as >>> objectively as I can but could understand that the CoI might be a conce= rn >>> for some (including the draft authors). >>> >>> wdyt? >>> >>> Cheers, >>> >>> JP >>> >>> On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev < >>> smyshsv@gmail.com> wrote: >>> >>>> Dear Jean-Philippe, >>>> >>>> As we discussed yesterday with Alexey and Nick, we would like to ask >>>> you about reviewing the current version of draft-irtf-cfrg-kangarootwe= lve ( >>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). >>>> Could you consider the possibility of providing such a review? >>>> >>>> Of course, we will be happy to receive reviews from all Crypto Review >>>> Panel members. >>>> >>>> Regards, >>>> Stanislav (on behalf of the CFRG chairs) >>>> >>>> --0000000000009151a5059df7d071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, but since the document has already been adopted as a = RG item, I think that "relevance of the topic wrt CFRG's goals&quo= t; is not necessary. Nevertheless, all comments are always welcome - in any= case, additional discussions during/after Research Group Last Call can be = even more productive if many important points are highlighted by the review= (s).

Regards,
Stanislav

On Fri, 7 Feb 202= 0 at 10:59, Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> wrote:
Sounds = good :)

I'm familiar with CFRG's goal but = as it's my first review, wanna make sure that we agree on the goals: do= these include.. ?

1. technical correctness of the= document
2. editorial quality
3. value of the content = against alternative solutions
4. relevance of the topic wrt CFRG&= #39;s goals

Thanks!


=
On Fri, Fe= b 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Dear Jean-Ph= ilippe,

Many thanks for your reply, your readiness to do= a review and for the warning!=C2=A0
Regardimg BLAKE3 =E2=80=93 u= nlike the PAKE selection process, the Crypto Review Panel reviews for the= =20 draft-irtf-cfrg-kangarootwelve draft can be considered as independent opinions of the experts, that can he= lp to highlight possible problems with the document (and can be disputed la= ter by the authors).

In my personal opinion (w= ith my CFRG chair hat off), if you mention=C2=A0conflict-of-interest warnin= g in your review, that will be enough.

Regards= ,
Stanislav

On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumas= son <jeanphilippe.aumasson@gmail.com> wrote:
Hi!

su= re, but conflict-of-interest warning: I'm a co-designer of BLAKE3 (https://blake3.io), a funct= ion that can be seen as a competitor of K12 in the super-fast, parallel has= h category. I can do the review as objectively as I can but could understan= d that the CoI might be a concern for some (including the draft authors).

wdyt?

Cheers,
JP

On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev= <smyshsv@gmail.c= om> wrote:
Dear Jean-Philippe,

As we discussed = yesterday with Alexey and Nick, we would like to ask you about reviewing th= e current version of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). C= ould you consider the possibility of providing such a review?
Of course, we will be happy to receive reviews from all Crypto = Review Panel members.

Regards,
Stani= slav (on behalf of the CFRG chairs)

--0000000000009151a5059df7d071-- From nobody Mon Feb 10 08:03:16 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF9120091 for ; Sun, 9 Feb 2020 21:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tKtD1B_bQXco for ; Sun, 9 Feb 2020 21:28:48 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 97C3A120020 for ; Sun, 9 Feb 2020 21:28:47 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id c23so3229307lfi.7 for ; Sun, 09 Feb 2020 21:28:47 -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=evRPZegdVlWH1IARro8B6CvbRBGPb0pO5/0LwQrsE4Y=; b=JeVVU3nLMZnLAUnBUaJ7LTC9jeEtEPxbY5H+Q/BRiZmJ7Rpf57kDHHnpPJXfykB2D5 D36jURBS1QYjLEytf6obK+LdyoQVZ4SyH8CeiQOmcd7O6iNpsXQRbb6KSkzkSAQBOqTs pQmbz/BnvhiJViawcP6Y6vk6WyXT/IQGawrvBeZWU5XvB5/UH7iRCXkGv3MpWYGK8uHw zA4kA+TLieGsbRPSZ2OkWgvULwolZ/PEXtgbGjAkFYQrd5AbcDaYEqR3KvXTdL8OBex0 a0zvkwj/u2I4a36rtS2kEqKYqZ+kM8ct6Dw8OWLVquoVQbaQJOEibYQKXYfKZ4XB4177 Po/g== 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=evRPZegdVlWH1IARro8B6CvbRBGPb0pO5/0LwQrsE4Y=; b=SKZAb+hp3CftNfaeSnA/Q1a8e3lyyvqsv1VfUb4MVNZYl8td3Fcg1k53QydtVh60fT 1VUOjQXc9apgOBPUAkHJ21BUSBff0585JfIe2eln4a4KDcR+xHKOXp2URw2zKPiLg9Jd 0zCKhP21BejjkKGeQ2fN/n6URxdeRSB2Wvey4zpdWW3Q2CVkiYbaTrNxv+H4o0iyqAfB zohIju5eV+7CsT8J7Ll3sTlR5rKRlTAPzb6GcDnL8cbE1ccUtt4xFbF1VjPvvGL0LiYS mXWKAIyp+avrlP1934NRf61KSHBtQ+ELas4JXJ4GPq3Zkz+SJS0bYTlj90qYlTmo0Fyt d2SA== X-Gm-Message-State: APjAAAUste4fkn7SKt1+L1shlI/aJRTdOkK0nYLFq4LaNg8K4LDqxXyv liIrzipmBoFySlHhmcEedKr5giaByPP5HbYHjdo= X-Google-Smtp-Source: APXvYqxT75vRKuUZniMeia2C9K1dozOwhPbR+/f6XOe/rs1090gEUaS3T0cm6aj0Q8dzdhDgVJIsUDveGy0BpX2ruwg= X-Received: by 2002:a19:f006:: with SMTP id p6mr5114452lfc.94.1581312525609; Sun, 09 Feb 2020 21:28:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 08:29:53 +0300 Message-ID: To: Watson Ladd , Hugo Krawczyk , Hugo Krawczyk , =?UTF-8?B?QmrDtnJuIEhhYXNl?= , =?UTF-8?B?QmrDtnJuIEhhYXNl?= , Benjamin Kaduk Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e2e4e059e32039f" Archived-At: Subject: Re: [Crypto-panel] PAKE Selection Process: Round 2, Stage 2 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 05:28:50 -0000 --0000000000005e2e4e059e32039f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Watson and Ben, Hugo, Bj=C3=B6rn, Today is the last day of Stage 3 of the second round of the PAKE selection process. Please send your detailed answers to the questions listed at https://github.com/cfrg/pake-selection#questions-for-round-2 to crypto-panel@irtf.org today. The reviewers will do their work at Stage 4 based on these answers - so the answers will have a very big impact on the overall results of the selection process. Best regards, Stanislav, On behalf of the CFRG chairs On Wed, 18 Dec 2019 at 18:28, Stanislav V. Smyshlyaev wrote: > Dear Watson and Ben, Hugo, Bj=C3=B6rn, > > Now we're at Stage 3 of the second round of the PAKE selection process. > Please provide your replies for the questions (related to your PAKEs) for > Round 2 listed at > https://github.com/cfrg/pake-selection#questions-for-round-2. Please do > that until February, 10th and send your replies to crypto-panel@irtf.org. > > I believe that it will be good if you make your answers detailed enough, > so that there won't be many additional clarifying questions from the > reviewers. > > Best regards, > Stanislav, > CFRG Secretary > > > > =D0=BF=D0=BD, 9 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 15:43, Stanislav = V. Smyshlyaev : > >> Dear CFRG, >> >> According to the plan of Round 2 of the PAKE selection process, >> additional questions for all four remaining candidates have been collect= ed >> from CFRG participants (and Crypto Review Panel members) via >> crypto-panel@irtf.org . >> >> We've obtained the following list of questions: >> 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all >> existing good properties of PAKE2) with a correspondingly updated securi= ty >> proof, addressing the issue of a single discrete log relationship necess= ary >> for the security of all sessions (e.g., solution based on using >> M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))? >> 2) (to CPace and AuCPace): Can you propose a modification of CPace and >> AuCPace (preserving all existing good properties of these PAKEs) with a >> correspondingly updated security proof (maybe, in some other security >> models), addressing the issue of requiring the establishment of a sessio= n >> identifier (sid) during each call of the protocol for the cost of one >> additional message? >> 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the >> protocols please re-evaluate possible IPR conflicts between their >> candidates protocols and own and foreign patents? Specifically, can you >> discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of >> march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, >> expected expiration October 2026) on the free use of the RFC-drafts for >> OPAQUE? >> 4) (to all 4 remaining PAKEs) What can be said about the property of >> "quantum annoyance" (an attacker with a quantum computer needs to solve >> [one or more] DLP per password guess) of the PAKE? >> 5) (to all 4 remaining PAKEs) What can be said about "post-quantum >> preparedness" of the PAKE? >> >> Please let the chairs and the Crypto Review Panel members know (before >> December, 17th) if any questions (collected via crypto-panel@irtf.org) >> have been lost or misinterpreted (or something needs to be added). >> >> Best regards, >> Stanislav, >> CFRG Secretary >> > --0000000000005e2e4e059e32039f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Watson and Ben, Hugo, Bj=C3=B6rn,

Today is the= last day=C2=A0of Stage 3 of the second round of the PAKE selection process= .
Please=20 send=20 your detailed answers to the questions listed at https://github.com/cfrg/pake= -selection#questions-for-round-2 to crypto-panel@irtf.org today.

The reviewers will do their work at Stage 4 based= on these answers - so the answers will have a very big impact on the overa= ll results of the selection process.

Best regards,
Stanislav,
= On behalf of the CFRG chairs

On Wed, 18 Dec 2019 at 18:28, Stanislav V= . Smyshlyaev <smyshsv@gmail.com= > wrote:
Dear Watson and Ben, Hugo, Bj=C3=B6rn,
=

Now we're at Stage 3 of the second round of t= he PAKE selection process.
Please provide your replies for t= he questions (related to your PAKEs) for Round 2 listed at=C2=A0https://github.com/cfrg/pake-selection#questions-for-round-2. Plea= se do that=C2=A0until=C2=A0February, 10th and send your replies to crypto-panel@irtf.org.




=D0=BF=D0=BD, 9 =D0=B4= =D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 15:43, Stanislav V. Smyshlyaev <smyshsv@gmail.com>:=
Dear CFRG,

According to the plan = of Round 2 of the PAKE selection process, additional questions for all four= remaining candidates have been collected from CFRG participants (and Crypt= o Review Panel members) via crypto-panel@irtf.org .

We've = obtained the following list of questions:
1) (to SPAKE2): Can you= propose a modification of SPAKE2 (preserving all existing good properties = of PAKE2) with a correspondingly updated security proof, addressing the iss= ue of a single discrete log relationship necessary for the security of all = sessions (e.g., solution based on using M=3Dhash2curve(A|B), N=3Dhash2curve= (B|A))?
2) (to CPace and AuCPace): Can you propose a modification of C= Pace and AuCPace (preserving all existing good properties of these PAKEs) w= ith a correspondingly updated security proof (maybe, in some other security= models), addressing the issue of requiring the establishment of a session = identifier (sid) during each call of the protocol for the cost of one addit= ional message?
3)=20 (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possibl= e IPR conflicts between their candidates protocols and own and foreign pate= nts? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (exp= ected expiration 10th of march 2023) on free use of SPAKE2 and the impact o= f EP1847062B1 (HMQV, expected expiration October 2026) on the free use of t= he RFC-drafts for OPAQUE?
4) (to all 4 remaining = PAKEs) What can be said about the property of "quantum annoyance"= (an attacker with a quantum computer needs to solve [one or more] DLP per = password guess) of the PAKE?
5)=20 (to all 4 remaining PAKEs)=20 What can be said about "post-quantum preparedness" of the PAKE?

Please let the chairs and the = Crypto Review Panel members know (before December, 17th) if any questions (= collected via=C2=A0 crypto-panel@irt= f.org) have been lost or misinterpreted (or something needs to be added= ).

Best regards,
Stanislav,
CF= RG Secretary
--0000000000005e2e4e059e32039f-- From nobody Mon Feb 10 08:03:22 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB163120091 for ; Sun, 9 Feb 2020 21:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 BvdrUsXEW-l8 for ; Sun, 9 Feb 2020 21:44:36 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 5EBD1120096 for ; Sun, 9 Feb 2020 21:44:36 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id q8so5684021ljb.2 for ; Sun, 09 Feb 2020 21:44:36 -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 :content-transfer-encoding; bh=Yd0HxT4uj8m3bHzK828xZLznlWMnxhgqvhP5+oKC7nM=; b=Hpnh9jvFloLvXwS/9cjlcR60fYQyN+mbnQd5802wrXCO+DFBZdrSk5pRbPLEVjR54Y +e83R4YnuAGNcfKHKVFQAJcXSo1xkbRwOdKje8mDDV1265hGuJIT0uwNHRDf+HyJ0wff dNDBHkXwM3M0U0BijIBZ0LWU2PM66Dl5FgTanEbesp+RTw2maAaM0srJdO+RZ/lP27fI 6I1wRUmZ18EFev0gklkMvNeNZHhHQnm/SCfgBX5fUsxnT6gadTbi73ZxwDrwTedv8FzP tUgGHlb89ULvUmCpk+evkNUSvmu4Fp4uYYmCYoA/+VjPsO8kFW16+nFsTYZyV0JKIFZC MIjw== 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:content-transfer-encoding; bh=Yd0HxT4uj8m3bHzK828xZLznlWMnxhgqvhP5+oKC7nM=; b=T/NOSz95MxQMoRvueYYgLR0WDnM7M8/WT+uOwqNAgFYHdDGTi/5xta6k96FsumJ33m l+R/88Cas0bNDCYEgVtb4kWgfB0d4+22LMhnZduRMods/qSNCgt5aDT+F0XMcmTt9VqQ 9rHXxWLPIziksyxBsDaKybMcWq9JuNYqPC4dCPHJE4NdISJOFazyDNGCCUtowJgwoWGB vupwP4cyo5HiLd3+Xt1JRgHvz58EWmYMP9aysn/7vTdfRqAKpT/Y6Hik1oizSNE3OM/7 68/0oFlOta8Rr6ZFn9i+Mktv254YYpEjPf7IAwYRBNuwP4qkgKsfBXmZEDZfDpSwxX30 LqNA== X-Gm-Message-State: APjAAAUocMdJ0IYvnqS2Rz5ye2WeQkX/nG7pjZvAA5C55+jKJ1egE6Kk SEjft6uX8pY/ZPLHyN1BtXhf2nscYJanJl74G05t10ld X-Google-Smtp-Source: APXvYqw2Hw2e5zBlidKeuY4L+XMuCfxtSlwCNToO/0/vVeLQJJt90n8ZlE8eqqFLXEHZ4Lo7LzIX9x4a1C6P856Ze4Y= X-Received: by 2002:a2e:b017:: with SMTP id y23mr6941626ljk.229.1581313474394; Sun, 09 Feb 2020 21:44:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Watson Ladd Date: Sun, 9 Feb 2020 21:44:23 -0800 Message-ID: To: crypto-panel@irtf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Crypto-panel] Answers to PAKE Questions X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 05:44:39 -0000 This time with correct email On Sun, Feb 9, 2020 at 9:43 PM Watson Ladd wrote: > > Question 1: (to SPAKE2): Can you propose a modification of SPAKE2 > (preserving all > > existing good properties of PAKE2) with a correspondingly updated securit= y > > proof, addressing the issue of a single discrete log relationship necessa= ry > > for the security of all sessions (e.g., solution based on using > > M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))? > > > The next version will include an option to have M and N based on party > identities, ensuring that an attacker with the ability to solve a > discrete logarithm problem can only compromise a single session per > discrete logarithm computed. This form does introduce a dependency on > the hash2curve draft, and requires an invocation of hash2curve per > pair of participants. The proof of such a construction is in > https://eprint.iacr.org/2019/1194. > > > Question 2:Can the nominators/developers of the > > protocols please re-evaluate possible IPR conflicts between their > > candidates protocols and own and foreign patents? Specifically, can you > > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > > expected expiration October 2026) on the free use of the RFC-drafts for > > OPAQUE? > > > I=E2=80=99m not a patent lawyer, and cannot speculate on any IPR conflict= s > that may or may not exist. > > > Question 4:What can be said about the property of > > "quantum annoyance" (an attacker with a quantum computer needs to solve > > [one or more] DLP per password guess) of the PAKE? > > > An adversary needs to solve a single DLP and then carry out an online > attack to recover the password without further quantum work. > > > Question 5: What can be said about "post-quantum preparedness" of the PAK= E? > > SPAKE2 is unlikely to have a post-quantum alternative. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Feb 10 08:04:28 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AED1200A3 for ; Mon, 10 Feb 2020 00:36:36 -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, LOTS_OF_MONEY=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 (1024-bit key) header.d=endress.com header.b=aEFQmXAu; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=fh68C5fa 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 D84Pc8zFPH_a for ; Mon, 10 Feb 2020 00:36:32 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30048.outbound.protection.outlook.com [40.107.3.48]) (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 DA21312008C for ; Mon, 10 Feb 2020 00:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e1sbFXElLnKzrYNAqGo97IRUo3owN0zVTQfocdqUOl8=; b=aEFQmXAuL4Wv7jLWNFNKOcJ9kmVisMOxEp+71OW00vatVdHPSFDQGrgqwFxjNCoKrNZeDIiSWIFigszRHkiNcmIP/6QMt0+SoGfpJmvzPmXk3iodl3INGvyItuunNrZKjGw/96i7h+TFMeZ0/Q75bjzttxYIOm5BZam6nTPb8eo= Received: from DB6PR0501CA0009.eurprd05.prod.outlook.com (2603:10a6:4:8f::19) by DB6PR05MB3351.eurprd05.prod.outlook.com (2603:10a6:6:1f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Mon, 10 Feb 2020 08:36:23 +0000 Received: from VE1EUR03FT020.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::203) by DB6PR0501CA0009.outlook.office365.com (2603:10a6:4:8f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23 via Frontend Transport; Mon, 10 Feb 2020 08:36:23 +0000 Authentication-Results: spf=pass (sender IP is 40.113.82.155) smtp.mailfrom=endress.com; irtf.org; dkim=fail (body hash did not verify) header.d=endress.com;irtf.org; dmarc=pass action=none header.from=endress.com; Received-SPF: Pass (protection.outlook.com: domain of endress.com designates 40.113.82.155 as permitted sender) receiver=protection.outlook.com; client-ip=40.113.82.155; helo=iqsuite.endress.com; Received: from iqsuite.endress.com (40.113.82.155) by VE1EUR03FT020.mail.protection.outlook.com (10.152.18.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2665.18 via Frontend Transport; Mon, 10 Feb 2020 08:36:23 +0000 Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Mon, 10 Feb 2020 09:36:22 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com ([104.47.13.50]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Mon, 10 Feb 2020 09:36:21 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LjPMI200ArGG3fugWAeJv+xSqP2s5v8ukog0IiSyEGT4MvNPHEofCVwseiy9hfF5OyT+P0hGx+ytGhtawmCPNXZhf3dzO0ZPBQx2c7wjTZIGsG7Efyfjk9ztjZ9MxGMd50BD0PNvhZpaDTzFzaoG4m1RPMNsLGunEH6l1UvFiqU7Oj6Db4JyaZJOMiC5vgNfmzT0TnN8Mm0T9FkYoQDu/V83eefdxRjX6voW+S+S5FPB+x4jN4I88gDrUMxbNhVO70Wt23HZb93WMt7eZc3pNJpIApJXaIQ6iHKTp91RHlBFSTiwJOKtw5RmhKL4CISM6/2q/xGkZYhX5f6voAiHbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgmqIU3/N1U0AdBYiK6JMg/yCkFtLCtzDT+M6aUny1s=; b=kt5hRY+rzLWNlQtk7qiVjTLtd5YIv+GJ8sO23FArb2GssJgqNNoHGG97IvB1715vaS6VcYd6yAlbFLO/kF/Q47OLbrCAH7dlkT6Ofwtc8EGHiJa20W4BQgb7ZeAg84p82nZivVQffxyiabhnbVZea0ZQvWq6zPkUOz6tttphVb75wt/Z3XATOo9v5vJpOd4k2Ur/decP8srjb3VV4PMEfBVSGQ19CjKVEYVyzR8fj+aPCEwmvpCfuAqf2lWgN3fCovtefXnAGbcMrp9vXsLKI8Fr2/ndoe7BRBQDkhd6Y1FxuTvYc1g7yqTUMnPrQNWRtSQZnwERcFtkBTKGBF0n/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=endress.com; dmarc=pass action=none header.from=endress.com; dkim=pass header.d=endress.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgmqIU3/N1U0AdBYiK6JMg/yCkFtLCtzDT+M6aUny1s=; b=fh68C5fa3Uep7+v4f8PrdftshNsimvBBxVr93yRVCN66coKXKaQ/uhetg8HKogGcDmBHeQM2xnSxWWpDQiGGFvAsoEXLMk/qaSljFsyHiMRVs89mpaGiNv6/SPG64F+0e0CTuKE8lPBJEOthdX0nxxAM4+rPz/LXd8D6PjG2Trs= Received: from AM0PR05MB4786.eurprd05.prod.outlook.com (52.133.57.143) by AM0PR05MB4612.eurprd05.prod.outlook.com (52.133.55.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.26; Mon, 10 Feb 2020 08:36:20 +0000 Received: from AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::5511:16a9:b981:b642]) by AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::5511:16a9:b981:b642%5]) with mapi id 15.20.2707.028; Mon, 10 Feb 2020 08:36:20 +0000 From: =?utf-8?B?QmrDtnJuIEhhYXNl?= To: "crypto-panel@irtf.org" CC: "Stanislav V. Smyshlyaev" Thread-Topic: PAKE Selection Process: Round 2, Stage 2 Thread-Index: AQHVtbfIdK5mV98cAk2GpkL41DbXX6gUOs6AgAAl0/A= Content-Class: Date: Mon, 10 Feb 2020 08:36:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Enabled=True; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SiteId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Owner=bjoern.haase@endress.com; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_SetDate=2020-02-10T08:36:18.1763788Z; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Name=Not Protected; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Application=Microsoft Azure Information Protection; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_ActionId=b60b0182-f617-4e15-a6ce-44c2d57336b4; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Extended_MSFT_Method=Automatic Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=bjoern.haase@endress.com; x-originating-ip: [93.240.145.106] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: a65df1bb-4471-4c91-018f-08d7ae044f6c X-MS-TrafficTypeDiagnostic: AM0PR05MB4612:|DB6PR05MB3351: X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03094A4065 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(199004)(189003)(2906002)(6506007)(186003)(26005)(8936002)(4326008)(86362001)(71200400001)(5660300002)(55016002)(9686003)(52536014)(478600001)(966005)(316002)(81166006)(85182001)(6916009)(81156014)(64756008)(8676002)(85202003)(66446008)(66556008)(76116006)(7696005)(66946007)(66476007)(66574012)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB4612; H:AM0PR05MB4786.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: endress.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Ej7N7K5HflT8DiqAQeQOc8PrFuXpTMkAiSr3gJKC5S11Uf2kxK323anTY9QUaYWtciOm4DR2X8nhHq3XwkixBo/hOIeBL0Hs/GGk5aanrSF4Pm1bESMKHYXyJdPrIDB95iRhI6VpudwsQ3AWVH4xgub9GUsJvH1yph9EFOZp7caNg15FquDo4udgfuZI1tGUdo3xgT60ojQzX6LStNFqHmwTlozqATa2pwMdNduwKKgaFbPBrhz+9H1hIIvDRsY8h8ge+IKTIqveFi4N1BHgDWDIyJxVcDlcBAeu462HcWRshaI6GearjiZeoz2kD002GmPRekfmZIsmZ/u6imai9gVRK8MBJFWtG8k+Hj8D0Q7PPX8p5ZkKdKAwiinZ2bx4VmAMuufe4NS+7FyW/ozmvn8LgNszCGpnAztN7hkTdVWTieo7n3isidjAnqzmL4dejak8/aDq7WjibhZb/tHudrrnvHxSjOGzvfIcGGIKlIE8BV68S4UIIhQF8b49/KO26PoIzWWs6o/NzaVEVxGPvg== x-ms-exchange-antispam-messagedata: e8bWN+y/MopTIQoGhpb5gtzSg01wH4CmVr42XAmDCJuPmhVNlbDZPHFsNNCzjxTMoq6G9jBluUK+yQqiuHFCGsLXt0g2fMHExvpuuBNe6y6ZtYYlGDCfYkbdPfEhlidTtjOVW0e2mwss4unJBiciaQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB4612 X-OriginalArrivalTime: 10 Feb 2020 08:36:21.0271 (UTC) FILETIME=[2BD1CA70:01D5DFED] X-Trailer: 1 X-GBS-PROC: Su519rGUQRzW3/jPgXahqOwzvqyprQULH80jeAyq9+c= X-GRP-TAN: IQNE01@6FC3BEC4085A4447A6505A5AC739E4E2 X-iqsuite-process: processed X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT020.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:40.113.82.155; IPV:; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(376002)(199004)(189003)(86362001)(336012)(15974865002)(2906002)(966005)(5660300002)(6506007)(4326008)(70206006)(66574012)(85182001)(26005)(316002)(107886003)(8936002)(33656002)(85202003)(478600001)(8676002)(81156014)(81166006)(186003)(70586007)(7696005)(55016002)(9686003)(6916009)(52536014)(356004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR05MB3351; H:iqsuite.endress.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: d38b4a51-0bf9-47cc-1f83-08d7ae044d9b X-Forefront-PRVS: 03094A4065 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 77dgeyyeQo4EtsVc+iDRFKXmngj0FjdYwWHmwnDhBjx7dPluV89g/S2/XlWbC34rO7LRKiZNg5Su+OKNKmtgmI7yr16Twh6sRtFjmWWcH2AJl3Jyk1iBwDJvQYV+Ht5n9BUVMdR6/84SmQhll+Ru14a8QXqwtWKfpjrwCRjXaw/qG7aoFz5WQLWNVW01vrQOxL6fvkQG9C2uFEDfqmSla+E/81CEFPqDOZ/hXCI3MStoZCwBxkK+zwLvlTmVTHx4Wh2Byuz9TqQxeuR6sotnuJQzqNYCiX8Abjfm9nqs0Wq1bl9clrcQIRS1R8wVs3qE6zQ0wkPxvpLmB9qrdE1phYO43vUza2RZnpFE91e0EEouTnWWkMInOpiIOJUWmXi1FkJxWfLfR/u2X9Ca/B0/cB1YMbQf/Kv5sFGo5pPjjgtg/mTygU5KVDDLuA214OVDEnKhgTqYEjAzMpLVPQXO9vMBM89zKzbVl961RcCUeh9wDfXILlxW7YxZlBsnUK0VTWP5l6ytY1XJswh2HfNU9A== X-OriginatorOrg: endress.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2020 08:36:23.0834 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a65df1bb-4471-4c91-018f-08d7ae044f6c X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[40.113.82.155]; Helo=[iqsuite.endress.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR05MB3351 Archived-At: Subject: Re: [Crypto-panel] PAKE Selection Process: Round 2, Stage 2 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 08:36:36 -0000 RGVhciBDRlJHLA0KDQphcyByZXF1ZXN0ZWQgZm9yIHRoZSBiZWdpbm5pbmcgb2Ygc3RhZ2Ug NCBvZiB0aGUgc2Vjb25kIHJvdW5kIG9mIHRoZSBQQUtFIHNlbGVjdGlvbiBwcm9jZXNzLCBJ IGhhdmUgY29tcGlsZWQgdGhlIGFkZGl0aW9uYWwgZG9jdW1lbnRhdGlvbiBhdCB0aGUgZm9s bG93aW5nIHBsYWNlcy4NCg0KUGFwZXI6wqANCmh0dHBzOi8vZ2l0aHViLmNvbS9Cam9lcm5N SGFhc2UvQXVDUGFjZS9ibG9iL21hc3Rlci9hdWNwYWNlX3NlY3VyaXR5X2FuYWx5c2lzXzIw MjAwMjA4LnBkZg0KDQpJbnRlcm5ldCBEcmFmdHM6DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaGFhc2UtYXVjcGFjZS0wMQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWhhYXNlLWNwYWNlLTAxDQoNClJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbnM6 DQpodHRwczovL2dpdGh1Yi5jb20vQmpvZXJuTUhhYXNlL0F1Q1BhY2UNCg0KDQpQbGVhc2Ug ZmluZCBhIHNob3J0IHZlcnNpb24gb2YgbXkgcmVwbGllcyBiZWxvdzoNCg0KUXVlc3Rpb24g Mik6DQoiKHRvIENQYWNlIGFuZCBBdUNQYWNlKTogQ2FuIHlvdSBwcm9wb3NlIGEgbW9kaWZp Y2F0aW9uIG9mIENQYWNlIGFuZCBBdUNQYWNlIChwcmVzZXJ2aW5nIGFsbCBleGlzdGluZyBn b29kIHByb3BlcnRpZXMgb2YgdGhlc2UgUEFLRXMpIHdpdGggYSBjb3JyZXNwb25kaW5nbHkg dXBkYXRlZCBzZWN1cml0eSBwcm9vZiAobWF5YmUsIGluIHNvbWUgb3RoZXIgc2VjdXJpdHkg bW9kZWxzKSwgYWRkcmVzc2luZyB0aGUgaXNzdWUgb2YgcmVxdWlyaW5nIHRoZSBlc3RhYmxp c2htZW50IG9mIGEgc2Vzc2lvbiBpZGVudGlmaWVyIChzaWQpIGR1cmluZyBlYWNoIGNhbGwg b2YgdGhlIHByb3RvY29sIGZvciB0aGUgY29zdCBvZiBvbmUgYWRkaXRpb25hbCBtZXNzYWdl PyINCg0KUmVwbHkgdG8gMikgOg0KSSBoYXZlIHJlLXJldmlld2VkIHRoaXMgaXNzdWUgYW5k IGludGVncmF0ZWQgdGhlIGFsdGVybmF0aXZlIGFwcHJvYWNoIGFzIHN1Z2dlc3RlZCBieSBS YW4gQ2FuZXR0aSBvbiB0aGUgQ0ZSRyBsaXN0IGluIHRoZSBwYXBlciBhbmQgc2VjdXJpdHkg YW5hbHlzaXMgKHNlZSDigJxwYXBlcuKAnSBsaW5rIGFib3ZlKS4gVGhlIHNwZWNpZmljYXRp b24gaW4gdGhlIENQYWNlIGFuZCBBdUNQYWNlIGludGVybmV0IGRyYWZ0cyBub3cgYWxzbyBj b3JyZXNwb25kIHRvIHRoaXMgYXBwcm9hY2guIFdpdGggdGhpcyBtZXRob2QsIHRoZXJlIGlz IG5vIGxvbmdlciB0aGUgbmVlZCBmb3IgYW4gYWRkaXRpb25hbCBjb21tdW5pY2F0aW9uIHJv dW5kLg0KDQpRdWVzdGlvbiAzKToNCiAiKHRvIGFsbCA0IHJlbWFpbmluZyBQQUtFcykgOiBD YW4gdGhlIG5vbWluYXRvcnMvZGV2ZWxvcGVycyBvZiB0aGUgcHJvdG9jb2xzIHBsZWFzZSBy ZS1ldmFsdWF0ZSBwb3NzaWJsZSBJUFIgY29uZmxpY3RzIGJldHdlZW4gdGhlaXIgY2FuZGlk YXRlcyBwcm90b2NvbHMgYW5kIG93biBhbmQgZm9yZWlnbiBwYXRlbnRzPyBTcGVjaWZpY2Fs bHksIGNhbiB5b3UgZGlzY3VzcyB0aGUgaW1wYWN0IG9mIFUuUy4gUGF0ZW50IDcsMDQ3LDQw OCAoZXhwZWN0ZWQgZXhwaXJhdGlvbiAxMHRoIG9mIG1hcmNoIDIwMjMpIG9uIGZyZWUgdXNl IG9mIFNQQUtFMiBhbmQgdGhlIGltcGFjdCBvZiBFUDE4NDcwNjJCMSAoSE1RViwgZXhwZWN0 ZWQgZXhwaXJhdGlvbiBPY3RvYmVyIDIwMjYpIG9uIHRoZSBmcmVlIHVzZSBvZiB0aGUgUkZD LWRyYWZ0cyBmb3IgT1BBUVVFPyINCg0KUmVwbHkgdG8gMyk6DQpJIGhhdmUgcmUtdmlzaXRl ZCBhbGwgcGF0ZW50cyBhbmQgZGlkIG5vdCBmaW5kIGFueSBJUFIgdGhhdCBtaWdodCBnZW5l cmF0ZSBjb25mbGljdHMgd2l0aCBDUGFjZSBhbmQgQXVDUGFjZS4gVGhlIHRvcGljIG9mIHRo ZSBtYXBwaW5nIGFsZ29yaXRobXMgaXMgcmVzb2x2ZWQgaW4gbXkgb3BpbmlvbiB3aXRoIHRo ZSBsYXRlc3QgY2hhbmdlcyBpbiB0aGUgaGFzaF90b19jdXJ2ZSBkcmFmdCAod2hpY2ggYXZv aWRzIHRoZSDigJwtMSBub24tcwlxdWFyZeKAnSB0b3BpYyBhbmQgdGhlIOKAnHRocmVlLXBv bHlub21pYWzigJ0gaXNzdWUgZm9yIFNTV1UpLg0KDQpJbiBjb250cmFzdCwgaW4gdGhlIGNv dXJzZSBvZiB0aGlzIHJlc2VhcmNoIEkgY2FtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IFNQ QUtFMiBpcyBwcm9iYWJseSBhZmZlY3RlZCBieSBVUyA3LDA0Nyw0MDguIFRoZSBleGNlcHRp b25hbCBmZWF0dXJlIGlzIHRoYXQgdGhlIGR1cmF0aW9uIG9mIHRoaXMgcGF0ZW50IHNlZW1z IHRvIGhhdmUgYmVlbiBleHRlbmRlZCB0byBhIHBlcmlvZCBvZiBleGNlcHRpb25hbCAyMyB5 ZWFycyBpbnN0ZWFkIG9mIDIwIHllYXJzISBJIGhhdmUgZG91YmxlLWNoZWNrZWQgYW5kIHRo YXQgc2VlbXMgaW5kZWVkIHRvIGJlIGxlZ2FsbHkgcG9zc2libHkgaW4gdGhlIFVTLiBJIGhh dmUganVzdCBmaWxlZCBhIGNvcnJlc3BvbmRpbmcgSVBSIGRpc2Nsb3N1cmUuDQoNClF1ZXN0 aW9uIDQpOiANCiIodG8gYWxsIDQgcmVtYWluaW5nIFBBS0VzKSBXaGF0IGNhbiBiZSBzYWlk IGFib3V0IHRoZSBwcm9wZXJ0eSBvZiAicXVhbnR1bSBhbm5veWFuY2UiIChhbiBhdHRhY2tl ciB3aXRoIGEgcXVhbnR1bSBjb21wdXRlciBuZWVkcyB0byBzb2x2ZSBbb25lIG9yIG1vcmVd IERMUCBwZXIgcGFzc3dvcmQgZ3Vlc3MpIG9mIHRoZSBQQUtFPyINCg0KUmVwbHkgdG8gNCk6 DQoNCkFzIHByZXZpb3VzbHkgbm90ZWQgYWxzbyBieSDigJxTdGV2ZSBUaG9tYXPigJ0sIGZv ciBDUGFjZSBhbiBhY3RpdmUgYWR2ZXJzYXJ5IG5lZWRzIHRvIHNvbHZlIGF0IGxlYXN0IG9u ZSBETFAgcGVyIHBhc3N3b3JkIGd1ZXNzIHRoaXMgYWxzbyBob2xkcyBmb3IgdGhlIGNvbnZl bnRpb25hbGx5IGF1Z21lbnRlZCBBdUNQYWNlIHZhcmlhbnQuIA0KDQpUaGUgYWRkaXRpb25h bCBndWFyYW50ZWUgb2Yg4oCccHJlLWNvbXB1dGF0aW9uIGF0dGFjayByZXNpc3RhbmNl4oCd IHByb3ZpZGVkIGJ5IHRoZSBPUFJGIGNvbnN0cnVjdGlvbiBvZiBzdHJvbmcgQXVDUGFjZSwg aG93ZXZlciB3aWxsIG5vdCBiZSBwcmVzZXJ2ZWQuIFRoaXMgbWVhbnMgdGhhdCB0aGUgKnN0 cm9uZyogQXVDUGFjZSBwcm90b2NvbCB3aWxsIGZhbGwgYmFjayB0aGUgY29udmVudGlvbmFs bHkgYXVnbWVudGVkIEF1Q1BhY2UgaW4gdGhlIHBvc3QtcXVhbnR1bSB3b3JsZCwgd2hpY2gg aXRzZWxmIGlzIGFnYWluIHF1YW50dW0gYW5ub3lpbmcuICAoVGhpcyBjb21lcyBhcyBhIGNv bnNlcXVlbmNlIG9mIHRoZSBpc3N1ZSB3aXRoIHRoZSAic3RhdGljIERpZmZpZS1IZWxsbWFu biBvcmFjbGUgdG9waWMiIHJlZ2FyZGluZyB0aGUgT1BBUVVFIE9QUkYsIGFzIGJyb3VnaHQg dXAgcmVjZW50bHkgYnkgU3RldmUgVGhvbWFzIHJlY2VudGx5IG9uIHRoZSBjcnlwdG8gcGFu ZWwgbGlzdCkuDQoNClF1ZXN0aW9uIDUpOiAgIih0byBhbGwgNCByZW1haW5pbmcgUEFLRXMp IFdoYXQgY2FuIGJlIHNhaWQgYWJvdXQgInBvc3QtcXVhbnR1bSBwcmVwYXJlZG5lc3MiIG9m IHRoZSBQQUtFPyINCg0KUmVwbHkgdG8gNCk6DQoNCkluIHRoZSBJbnRlcm5ldCBEcmFmdHMg cmVnYXJkaW5nIENQYWNlIGFuZCBBdUNQYWNlIEkgaGF2ZSBhZGRlZCBhIHNob3J0IGRpc2N1 c3Npb24gb24gdGhpcyB0b3BpYy4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIGZhY3QgdGhhdCBD UGFjZSBhbmQgQXVDUGFjZSBkb27igJl0IGFjdHVhbGx5IHJlcXVpcmUgYSBmdWxsIGdyb3Vw IHN0cnVjdHVyZSBidXQgb25seSBvcGVyYXRpb25zIGluIGEgImdyb3VwIG1vZHVsbyBuZWdh dGlvbiIgbWlnaHQgcHJvdmlkZSBhIHBhdGggZm9yIHVzaW5nIGlzb2dlbnktYmFzZWQgY3J5 cHRvZ3JhcGh5IGFzIGtpbmQgb2YgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciB0aGUgRGlm ZmllLUhlbGxtYW5uIHN1YnN0ZXBzLiANCg0KV2hpbGUgcHJpbWl0aXZlcyBzdWNoIGFzIFNJ S0UgYW5kIENTSURIIHByb3ZpZGUgZnVuY3Rpb25hbGl0eSBzaW1pbGFyIHRvIGEgREggc2Vj cmV0IGVzdGFibGlzaG1lbnQgKHdoZXJlIGJvdGggcGFydGllcyBjb250cmlidXRlIHRvIHRo ZSBrZXkpLCB0aGVyZSBpcyBubyBzdWNoIGVxdWl2YWxlbnQgb2Yg4oCccG9pbnQgYWRkaXRp b27igJ0gaW4gdGhlIGlzb2dlbnkgd29ybGQuIEluIG15IG9waW5pb24sIGZvciB0aGUgYXVn bWVudGF0aW9uIGxheWVyIG9mIEF1Q1BhY2UsIHRoZSBtZWNoYW5pc21zIG9uIGlzb2dlbmll cyBmb3IgRGlmZmllLUhlbGxtYW5uLXN0eWxlIHNlY3JldCBlc3RhYmxpc2htZW50IGNvdWxk IGFscmVhZHkgYmUgdXNlZCBhcy1pcy4gRm9yIHRoZSBhcHBsaWNhdGlvbiBpbiBDUGFjZSAo d2l0aCB0aGUgbmVlZCBvZiBhbiBpc29nZW55LWVxdWl2YWxlbnQgb2YgYSBzZWNyZXQgcGFz c3dvcmQtZGVyaXZlZCBiYXNlIHBvaW50KSwgdGhlcmUgaXMgb25nb2luZyByZXNlYXJjaCB3 aGljaCBpcywgaG93ZXZlciwgbm90IHlldCBzdGFiaWxpemVkIGFuZCBtYXR1cmUgaW4gbXkg b3Bpbmlvbi4gSGVyZSBJIGhhdmUgYWRkZWQgYSBsaW5rcyByZWdhcmRpbmcgcG9zc2libGUg bWlncmF0aW9uIHBhdGhzIHJlZ2FyZGluZyBDUGFjZSBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGUgaW50ZXJuZXQgZHJhZnQuDQoNCkFkZGl0aW9uYWxs eSwgdGhlIG1vZHVsYXJpemVkIHNlY3VyaXR5IGFuYWx5c2lzIG9mIENQYWNlIGFzIGEgYnVp bGRpbmcgYmxvY2sgb2YgQXVDUGFjZSBhbGxvd3MgZm9yIHJlcGxhY2luZyB0aGUgQ1BhY2Ug Y29tcG9uZW50IGJ5IGFueSBmdXR1cmUgYmFsYW5jZWQgcG9zdC1xdWFudHVtIFBBS0UgKGlu IHRoZSBzdHlsZSB0aGF0IEh1Z28gc3VnZ2VzdHMgZm9yIE9QQVFVRSkuDQogRm9yIGluc3Rh bmNlLCBJIGJlbGlldmUgaXQgdG8gYmUgcHJvbWlzaW5nIHRvIGNvbnNpZGVyIGNvbnN0cnVj dGlvbnMgYmFzZWQgb24gdGhlIExXRSBwcm9ibGVtIHdoZXJlIHRoZSBtYXRyaWNlcyBhcmUg a2VwdCBzZWNyZXQgYW5kIGRlcml2ZWQgZnJvbSBhIHBhc3N3b3JkIGFuZCBhbiBlcGhlbWVy YWwgc2Vzc2lvbiBpZCwgaW4gdGhlIHN0eWxlIG9mICJOZXcgaG9wZSIgd2hpY2ggdXNlcyBT SEFLRSBmb3IgZ2VuZXJhdGlvbiBvZiBlcGhlbWVyYWwgTFdFIG1hdHJpY2VzLiBTdGlsbCBh Z2FpbiwgdGhpcyB0b3BpYywganVzdCBhcyB0aGUgaXNvZ2VuaWVzLCB3b3VsZCByZXF1aXJl IHNpZ25pZmljYW50IGZ1dHVyZSByZXNlYXJjaCBpbiBteSBvcGluaW9uLg0KDQpJIGFtIHVu Zm9ydHVuYXRlbHkgbm90IGF3YXJlIG9mIGFueSBjdXJyZW50IGNvbmNlcHQgcmVnYXJkaW5n IGEgcG9zdCBxdWFudHVtIHByaW1pdGl2ZSBmb3IgdGhlIE9QUkYgY29uc3RydWN0aW9uIGFz IG5lZWRlZCBmb3IgKnN0cm9uZyogQXVDUGFjZS4NCg0KWW91cnMsDQoNCkJqw7ZybiBIYWFz ZQ0KDQoNClAuUy46IEEgY29tcGlsYXRpb24gcmVnYXJkaW5nIG15IHBlcnNvbmFsIHZpZXcg b24gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIHNlbGVjdGlvbiBwcm9jZXNzIGlzIGZvdW5k IGF0DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9Cam9lcm5NSGFhc2UvZmUyNTUxOS9ibG9iL21h c3Rlci9TbGlkZXNfUEFLRV9zZWxlY3Rpb25fYXRfQ0ZSR19CcmFpbnBvb2xfMjAyMDAxMTUu cGRmIA0KDQpJIHRyaWVkIHRvIGJlIGFzIG9iamVjdGl2ZSBhcyBvbmUgY291bGQgcmVhc29u YWJseSBiZSBleHBlY3RpbmcgZnJvbSBhbiBpbmRpdmlkdWFsIGhhdmluZyBvd24gbm9taW5h dGlvbnMgcnVubmluZy4NCg0KDQpNaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuIEkgQmVzdCBS ZWdhcmRzIA0KDQpEci4gQmrDtnJuIEhhYXNlIA0KDQoNClNlbmlvciBFeHBlcnQgRWxlY3Ry b25pY3MgfCBUR1JFSCBFbGVjdHJvbmljcyBIYXJkd2FyZQ0KRW5kcmVzcytIYXVzZXIgQ29u ZHVjdGEgR21iSCtDby5LRyB8IERpZXNlbHN0cmFzc2UgMjQgfCA3MDgzOSBHZXJsaW5nZW4g fCBHZXJtYW55DQpQaG9uZTogKzQ5IDcxNTYgMjA5IDM3NyB8IEZheDogKzQ5IDcxNTYgMjA5 IDIyMQ0KYmpvZXJuLmhhYXNlQGVuZHJlc3MuY29tIHwgIHd3dy5jb25kdWN0YS5lbmRyZXNz LmNvbSANCg0KDQoNCkVuZHJlc3MrSGF1c2VyIENvbmR1Y3RhIEdtYkgrQ28uS0cNCkFtdHNn ZXJpY2h0IFN0dXR0Z2FydCBIUkEgMjAxOTA4DQpTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IEdl cmxpbmdlbg0KUGVyc8O2bmxpY2ggaGFmdGVuZGUgR2VzZWxsc2NoYWZ0ZXJpbjoNCkVuZHJl c3MrSGF1c2VyIENvbmR1Y3RhIFZlcndhbHR1bmdzZ2VzZWxsc2NoYWZ0IG1iSA0KU2l0eiBk ZXIgR2VzZWxsc2NoYWZ0OiBHZXJsaW5nZW4NCkFtdHNnZXJpY2h0IFN0dXR0Z2FydCBIUkEg MjAxOTI5DQpHZXNjaMOkZnRzZsO8aHJlcjogRHIuIE1hbmZyZWQgSmFnaWVsbGENCg0KwqAN CkdlbcOkc3MgRGF0ZW5zY2h1dHpncnVuZHZlcm9yZG51bmcgc2luZCB3aXIgdmVycGZsaWNo dGV0LCBTaWUgenUgaW5mb3JtaWVyZW4sIHdlbm4gd2lyIHBlcnNvbmVuYmV6b2dlbmUgRGF0 ZW4gdm9uIElobmVuIGVyaGViZW4uDQpEaWVzZXIgSW5mb3JtYXRpb25zcGZsaWNodCBrb21t ZW4gd2lyIG1pdCBmb2xnZW5kZW0gRGF0ZW5zY2h1dHpoaW53ZWlzIChodHRwczovL3d3dy5l bmRyZXNzLmNvbS9kZS9jb29raWVzLWVuZHJlc3MraGF1c2VyLXdlYnNpdGUpIG5hY2guDQoN CsKgDQoNCkRpc2NsYWltZXI6IA0KDQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBh bmQvb3IgcHJpdmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24s IGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlv biBpbiByZWxpYW5jZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50 aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGUgbWF0ZXJpYWwgZnJvbSBhbnkgY29tcHV0ZXIuIFRoaXMgZS1t YWlsIGRvZXMgbm90IGNvbnN0aXR1dGUgYSBjb250cmFjdCBvZmZlciwgYSBjb250cmFjdCBh bWVuZG1lbnQsIG9yIGFuIGFjY2VwdGFuY2Ugb2YgYSBjb250cmFjdCBvZmZlciB1bmxlc3Mg ZXhwbGljaXRseSBhbmQgY29uc3BpY3VvdXNseSBkZXNpZ25hdGVkIG9yIHN0YXRlZCBhcyBz dWNoLg0KIA0K From nobody Mon Feb 10 08:06:56 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FD1201E0 for ; Mon, 10 Feb 2020 04:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AxnjafX-g8n4 for ; Mon, 10 Feb 2020 04:37:14 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 DBC801201DE for ; Mon, 10 Feb 2020 04:37:13 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id y19so4061843lfl.9 for ; Mon, 10 Feb 2020 04:37:13 -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; bh=apGsNBauzrD/jgYf8VwGkwLjXxoBWwmj1BJ7lzhwgzY=; b=J3J6P4ytXPH+3NarcXyO6xN0anRsOzW8zF6+RqSN6pPwsuv0lGsZCqjgCVIaeVE8MY /SuKakBOk39uw+JyeYV9vxKk2wN0/xRI4VQyYegTR2LEXgSXvKqs5ByJouKqUlI/hDZM G8LD5ZfInok3l96GC0MIV/SAPgA4F6AqoXvArwDto53gP4waRO4DGYHZYrHSvRf+AtaG FCGNhqHAkEQVU59lWOUEv2n5MueWI8MN9C6c3TYvtTDWPTQT290o3pwV+ph5kC8FQyal p8tEHnqJusnLuAXAui71LWEfaNMJXS0nR9rQkAz1aunJIzOitn2EqJ5mrZsc6SqIJH5f AHRg== 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; bh=apGsNBauzrD/jgYf8VwGkwLjXxoBWwmj1BJ7lzhwgzY=; b=LEbb7+QaNS4Bnwr835VoC6HlzwMKmnUYSt2QrKyEyKO2OQzqscWpiN5I26u1rgDXTk db7D7KNzKY1oO6m+b4wwp9Ls9qSuNOOM3QoDU4MBhy5nOL2JilnHYROKF05YuUWlGLdE owSGyMlH66Hug/Ue2K+bX5pfnA8FI0yqtL7BgcPTdPnMFN+yDbeHeHdaiiHF8QQ+/F1U 0NTptrf3UbFW2ZfGGg2/DhhLzVV/Bm2U4evfPsZGOs1e8XZHJaxzYTG8ix1kIlBl2CFG a7Nfvp6/qZ/eZ5aVtEN+wPmQulNQPXNMqxfQeIORCPDkW8AGA0YZkQAOTW/jdvgftlVv A/oQ== X-Gm-Message-State: APjAAAVs2paTf1VtXnSksBDcvpoEYmclC2kUThQqbg3w9IiK9nbIq+OV FtCuygZSt06XeuyzGu8frMrar+0/6BBqU0HzUD79lIpf X-Google-Smtp-Source: APXvYqwNJxYXFnWtcGj9omqYwCdhNUEmCWM0eCdrI1c+AoVBH5Q5B9fFNF7a1BwIEnl42Lrw0LcWj1qp6oFTUOLeUEM= X-Received: by 2002:ac2:4c84:: with SMTP id d4mr692950lfl.64.1581338231425; Mon, 10 Feb 2020 04:37:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 15:38:18 +0300 Message-ID: To: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="0000000000008dcefe059e37ff32" Archived-At: Subject: [Crypto-panel] Fwd: PAKE Selection Process: Round 2, Stage 2 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 12:37:18 -0000 --0000000000008dcefe059e37ff32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forwarding a message from Bj=C3=B6rn Haase. ---------- Forwarded message --------- From: Bj=C3=B6rn Haase Date: Mon, 10 Feb 2020 at 11:36 Subject: AW: PAKE Selection Process: Round 2, Stage 2 To: crypto-panel@irtf.org Cc: Stanislav V. Smyshlyaev Dear CFRG, as requested for the beginning of stage 4 of the second round of the PAKE selection process, I have compiled the additional documentation at the following places. Paper: https://github.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analys= is_20200208.pdf Internet Drafts: https://tools.ietf.org/html/draft-haase-aucpace-01 https://tools.ietf.org/html/draft-haase-cpace-01 Reference implementations: https://github.com/BjoernMHaase/AuCPace Please find a short version of my replies below: Question 2): "(to CPace and AuCPace): Can you propose a modification of CPace and AuCPace (preserving all existing good properties of these PAKEs) with a correspondingly updated security proof (maybe, in some other security models), addressing the issue of requiring the establishment of a session identifier (sid) during each call of the protocol for the cost of one additional message?" Reply to 2) : I have re-reviewed this issue and integrated the alternative approach as suggested by Ran Canetti on the CFRG list in the paper and security analysis (see =E2=80=9Cpaper=E2=80=9D link above). The specification in the= CPace and AuCPace internet drafts now also correspond to this approach. With this method, there is no longer the need for an additional communication round. Question 3): "(to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE?" Reply to 3): I have re-visited all patents and did not find any IPR that might generate conflicts with CPace and AuCPace. The topic of the mapping algorithms is resolved in my opinion with the latest changes in the hash_to_curve draft (which avoids the =E2=80=9C-1 non-s quare=E2=80=9D topic and the =E2= =80=9Cthree-polynomial=E2=80=9D issue for SSWU). In contrast, in the course of this research I came to the conclusion that SPAKE2 is probably affected by US 7,047,408. The exceptional feature is that the duration of this patent seems to have been extended to a period of exceptional 23 years instead of 20 years! I have double-checked and that seems indeed to be legally possibly in the US. I have just filed a corresponding IPR disclosure. Question 4): "(to all 4 remaining PAKEs) What can be said about the property of "quantum annoyance" (an attacker with a quantum computer needs to solve [one or more] DLP per password guess) of the PAKE?" Reply to 4): As previously noted also by =E2=80=9CSteve Thomas=E2=80=9D, for CPace an ac= tive adversary needs to solve at least one DLP per password guess this also holds for the conventionally augmented AuCPace variant. The additional guarantee of =E2=80=9Cpre-computation attack resistance=E2= =80=9D provided by the OPRF construction of strong AuCPace, however will not be preserved. This means that the *strong* AuCPace protocol will fall back the conventionally augmented AuCPace in the post-quantum world, which itself is again quantum annoying. (This comes as a consequence of the issue with the "static Diffie-Hellmann oracle topic" regarding the OPAQUE OPRF, as brought up recently by Steve Thomas recently on the crypto panel list). Question 5): "(to all 4 remaining PAKEs) What can be said about "post-quantum preparedness" of the PAKE?" Reply to 4): In the Internet Drafts regarding CPace and AuCPace I have added a short discussion on this topic. I believe that the fact that CPace and AuCPace don=E2=80=99t actually requi= re a full group structure but only operations in a "group modulo negation" might provide a path for using isogeny-based cryptography as kind of a drop-in replacement for the Diffie-Hellmann substeps. While primitives such as SIKE and CSIDH provide functionality similar to a DH secret establishment (where both parties contribute to the key), there is no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the isogeny wo= rld. In my opinion, for the augmentation layer of AuCPace, the mechanisms on isogenies for Diffie-Hellmann-style secret establishment could already be used as-is. For the application in CPace (with the need of an isogeny-equivalent of a secret password-derived base point), there is ongoing research which is, however, not yet stabilized and mature in my opinion. Here I have added a links regarding possible migration paths regarding CPace in the security considerations section of the internet draft. Additionally, the modularized security analysis of CPace as a building block of AuCPace allows for replacing the CPace component by any future balanced post-quantum PAKE (in the style that Hugo suggests for OPAQUE). For instance, I believe it to be promising to consider constructions based on the LWE problem where the matrices are kept secret and derived from a password and an ephemeral session id, in the style of "New hope" which uses SHAKE for generation of ephemeral LWE matrices. Still again, this topic, just as the isogenies, would require significant future research in my opinion. I am unfortunately not aware of any current concept regarding a post quantum primitive for the OPRF construction as needed for *strong* AuCPace. Yours, Bj=C3=B6rn Haase P.S.: A compilation regarding my personal view on the current state of the selection process is found at https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selection_a= t_CFRG_Brainpool_20200115.pdf I tried to be as objective as one could reasonably be expecting from an individual having own nominations running. Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards Dr. Bj=C3=B6rn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany Phone: +49 7156 209 377 | Fax: +49 7156 209 221 bjoern.haase@endress.com | www.conducta.endress.com Endress+Hauser Conducta GmbH+Co.KG Amtsgericht Stuttgart HRA 201908 Sitz der Gesellschaft: Gerlingen Pers=C3=B6nlich haftende Gesellschafterin: Endress+Hauser Conducta Verwaltungsgesellschaft mbH Sitz der Gesellschaft: Gerlingen Amtsgericht Stuttgart HRA 201929 Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis ( https://www.endress.com/de/cookies-endress+hauser-website) nach. Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such. --0000000000008dcefe059e37ff32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forwarding a message from Bj=C3=B6rn Haase.

---------- Forwar= ded message ---------
From: Bj=C3=B6rn Haase <bjoern.haase@endress.com>
Date: Mon,= 10 Feb 2020 at 11:36
Subject: AW: PAKE Selection Process: Round 2, Stag= e 2
To: crypto-panel@irtf.org <crypto-panel@irtf.org&g= t;
Cc: Stanislav V. Smyshlyaev <= smyshsv@gmail.com>


Dear CFRG,

as requested for the beginning of stage 4 of the second round of the PAKE s= election process, I have compiled the additional documentation at the follo= wing places.

Paper:=C2=A0
https://gi= thub.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analysis_2020020= 8.pdf

Internet Drafts:
https://tools.ietf.org/html/draft-haase-aucpace-01=
https://tools.ietf.org/html/draft-haase-cpace-01=

Reference implementations:
https://github.com/BjoernMHaase/AuCPace


Please find a short version of my replies below:

Question 2):
"(to CPace and AuCPace): Can you propose a modification of CPace and A= uCPace (preserving all existing good properties of these PAKEs) with a corr= espondingly updated security proof (maybe, in some other security models), = addressing the issue of requiring the establishment of a session identifier= (sid) during each call of the protocol for the cost of one additional mess= age?"

Reply to 2) :
I have re-reviewed this issue and integrated the alternative approach as su= ggested by Ran Canetti on the CFRG list in the paper and security analysis = (see =E2=80=9Cpaper=E2=80=9D link above). The specification in the CPace an= d AuCPace internet drafts now also correspond to this approach. With this m= ethod, there is no longer the need for an additional communication round.
Question 3):
=C2=A0"(to all 4 remaining PAKEs) : Can the nominators/developers of t= he protocols please re-evaluate possible IPR conflicts between their candid= ates protocols and own and foreign patents? Specifically, can you discuss t= he impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023)= on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expira= tion October 2026) on the free use of the RFC-drafts for OPAQUE?"

Reply to 3):
I have re-visited all patents and did not find any IPR that might generate = conflicts with CPace and AuCPace. The topic of the mapping algorithms is re= solved in my opinion with the latest changes in the hash_to_curve draft (wh= ich avoids the =E2=80=9C-1 non-s=C2=A0 =C2=A0 =C2=A0 =C2=A0quare=E2=80=9D t= opic and the =E2=80=9Cthree-polynomial=E2=80=9D issue for SSWU).

In contrast, in the course of this research I came to the conclusion that S= PAKE2 is probably affected by US 7,047,408. The exceptional feature is that= the duration of this patent seems to have been extended to a period of exc= eptional 23 years instead of 20 years! I have double-checked and that seems= indeed to be legally possibly in the US. I have just filed a corresponding= IPR disclosure.

Question 4):
"(to all 4 remaining PAKEs) What can be said about the property of &qu= ot;quantum annoyance" (an attacker with a quantum computer needs to so= lve [one or more] DLP per password guess) of the PAKE?"

Reply to 4):

As previously noted also by =E2=80=9CSteve Thomas=E2=80=9D, for CPace an ac= tive adversary needs to solve at least one DLP per password guess this also= holds for the conventionally augmented AuCPace variant.

The additional guarantee of =E2=80=9Cpre-computation attack resistance=E2= =80=9D provided by the OPRF construction of strong AuCPace, however will no= t be preserved. This means that the *strong* AuCPace protocol will fall bac= k the conventionally augmented AuCPace in the post-quantum world, which its= elf is again quantum annoying.=C2=A0 (This comes as a consequence of the is= sue with the "static Diffie-Hellmann oracle topic" regarding the = OPAQUE OPRF, as brought up recently by Steve Thomas recently on the crypto = panel list).

Question 5):=C2=A0 "(to all 4 remaining PAKEs) What can be said about = "post-quantum preparedness" of the PAKE?"

Reply to 4):

In the Internet Drafts regarding CPace and AuCPace I have added a short dis= cussion on this topic.

I believe that the fact that CPace and AuCPace don=E2=80=99t actually requi= re a full group structure but only operations in a "group modulo negat= ion" might provide a path for using isogeny-based cryptography as kind= of a drop-in replacement for the Diffie-Hellmann substeps.

While primitives such as SIKE and CSIDH provide functionality similar to a = DH secret establishment (where both parties contribute to the key), there i= s no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the isogeny wor= ld. In my opinion, for the augmentation layer of AuCPace, the mechanisms on= isogenies for Diffie-Hellmann-style secret establishment could already be = used as-is. For the application in CPace (with the need of an isogeny-equiv= alent of a secret password-derived base point), there is ongoing research w= hich is, however, not yet stabilized and mature in my opinion. Here I have = added a links regarding possible migration paths regarding CPace in the sec= urity considerations section of the internet draft.

Additionally, the modularized security analysis of CPace as a building bloc= k of AuCPace allows for replacing the CPace component by any future balance= d post-quantum PAKE (in the style that Hugo suggests for OPAQUE).
=C2=A0For instance, I believe it to be promising to consider constructions = based on the LWE problem where the matrices are kept secret and derived fro= m a password and an ephemeral session id, in the style of "New hope&qu= ot; which uses SHAKE for generation of ephemeral LWE matrices. Still again,= this topic, just as the isogenies, would require significant future resear= ch in my opinion.

I am unfortunately not aware of any current concept regarding a post quantu= m primitive for the OPRF construction as needed for *strong* AuCPace.

Yours,

Bj=C3=B6rn Haase


P.S.: A compilation regarding my personal view on the current state of the = selection process is found at

https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selecti= on_at_CFRG_Brainpool_20200115.pdf

I tried to be as objective as one could reasonably be expecting from an ind= ividual having own nominations running.


Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards

Dr. Bj=C3=B6rn Haase


Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | G= ermany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
bjoern.haase@= endress.com |=C2=A0 www.conducta.endress.com



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Pers=C3=B6nlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella

=C2=A0
Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu inform= ieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hau= ser-website) nach.

=C2=A0

Disclaimer:

The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential, proprietary, and/or privi= leged material. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon, this information by persons or en= tities other than the intended recipient is prohibited. If you receive this= in error, please contact the sender and delete the material from any compu= ter. This e-mail does not constitute a contract offer, a contract amendment= , or an acceptance of a contract offer unless explicitly and conspicuously = designated or stated as such.

--0000000000008dcefe059e37ff32-- From nobody Mon Feb 10 08:07:56 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327C6120122 for ; Mon, 10 Feb 2020 06:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DU1KKXtpo5R7 for ; Mon, 10 Feb 2020 06:15:44 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 6AAF41200F5 for ; Mon, 10 Feb 2020 06:15:43 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id f25so7292873ljg.12 for ; Mon, 10 Feb 2020 06:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=V15GcVbEuqeVXuAcehHo+W0qlkQVmplchkqfXOufU+U=; b=QTO3QJgXoDpHqqry1BrOq3wusyF6sa7wZqvZ4jTZrt6Z2NCzoK6gr88TWU9MuCFBtI j8kEmOL03Mq019PMwR+lBcRGXrFLhYRAbevJRR3fLCAHETUpKVoNKK8RN7p2iWDmymY2 Yl18nFCS6tRnKEibtS9bjXGl7XTFF/cr4h26dwmcO2FAgHtXFRaZA2jjeTEBW75uJE7V Xts7K3m7gPN7ZlUXQV+ngiBaGDNHk2YP9Rld2jBHfC7YXYDnpblo53Qfxhynfz5rJN0M WqC+Ux5gonQYKmpNfvYdopHZb0PCYoW177OaVb35j5nmt4+L7Yhl86u8+9wEDm3WAwzq j6MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V15GcVbEuqeVXuAcehHo+W0qlkQVmplchkqfXOufU+U=; b=eDhhg05tT1pWJeezK/ReYxPq75goIQOjIejZbwFTNw1+10jGUKM9IeCAPfcfVP+Wqx PhBCOV22QpY77QnAxNFjcxMolusAxBRslYhdZJQoFJgXZoO1vLdLqJQ769E5gyWFAqiL 1CsIWtOOHNoRcDc5eunyH1C9lyJqJjGyKPtMqpgxnLsqQFwe9uOpBhhlynQTcguFsGCK fMazDZN9JB0MJIwVcNOUnW97bZEBzYYIGTIfCOk02NqHC8CVF4Hsn4AZ/WT+oLMY6XVp ROi7ZWRgyEm9hbCDCEFoYrhzg14m5PSufadcBjIb5VVlW2zvMhbhkztagHNI+ZoWLFeZ RVJg== X-Gm-Message-State: APjAAAV/OT1dnDochpfdRmeSL1sqEqSVbjRrfuYjvW2VItudIp9lw7Iw XDhfBa8klF/4Y9SDtziMPQozUVd++TvAycpVro0fJheD X-Google-Smtp-Source: APXvYqxYY+ldKVPSiKzoFWtTR5Ct2tkiJXFlysa+AyCvLpJWsIZwwuW9gK8N0tLuCkEbixyAOKoHxj48AteBfAXW6ys= X-Received: by 2002:a2e:8758:: with SMTP id q24mr1074336ljj.157.1581344141040; Mon, 10 Feb 2020 06:15:41 -0800 (PST) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 17:16:48 +0300 Message-ID: To: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="000000000000cb5e55059e395f36" Archived-At: Subject: [Crypto-panel] Forwarding a message from Bjoern Haase X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 14:15:47 -0000 --000000000000cb5e55059e395f36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear CFRG, as requested for the beginning of stage 4 of the second round of the PAKE selection process, I have compiled the additional documentation at the following places. Paper: https://github.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analys= is_20200208.pdf Internet Drafts: https://tools.ietf.org/html/draft-haase-aucpace-01 https://tools.ietf.org/html/draft-haase-cpace-01 Reference implementations: https://github.com/BjoernMHaase/AuCPace Please find a short version of my replies below: Question 2): "(to CPace and AuCPace): Can you propose a modification of CPace and AuCPace (preserving all existing good properties of these PAKEs) with a correspondingly updated security proof (maybe, in some other security models), addressing the issue of requiring the establishment of a session identifier (sid) during each call of the protocol for the cost of one additional message?" Reply to 2) : I have re-reviewed this issue and integrated the alternative approach as suggested by Ran Canetti on the CFRG list in the paper and security analysis (see =E2=80=9Cpaper=E2=80=9D link above). The specification in the= CPace and AuCPace internet drafts now also correspond to this approach. With this method, there is no longer the need for an additional communication round. Question 3): "(to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE?" Reply to 3): I have re-visited all patents and did not find any IPR that might generate conflicts with CPace and AuCPace. The topic of the mapping algorithms is resolved in my opinion with the latest changes in the hash_to_curve draft (which avoids the =E2=80=9C-1 non-s quare=E2=80=9D topic and the =E2= =80=9Cthree-polynomial=E2=80=9D issue for SSWU). In contrast, in the course of this research I came to the conclusion that SPAKE2 is probably affected by US 7,047,408. The exceptional feature is that the duration of this patent seems to have been extended to a period of exceptional 23 years instead of 20 years! I have double-checked and that seems indeed to be legally possibly in the US. I have just filed a corresponding IPR disclosure. Question 4): "(to all 4 remaining PAKEs) What can be said about the property of "quantum annoyance" (an attacker with a quantum computer needs to solve [one or more] DLP per password guess) of the PAKE?" Reply to 4): As previously noted also by =E2=80=9CSteve Thomas=E2=80=9D, for CPace an ac= tive adversary needs to solve at least one DLP per password guess this also holds for the conventionally augmented AuCPace variant. The additional guarantee of =E2=80=9Cpre-computation attack resistance=E2= =80=9D provided by the OPRF construction of strong AuCPace, however will not be preserved. This means that the *strong* AuCPace protocol will fall back the conventionally augmented AuCPace in the post-quantum world, which itself is again quantum annoying. (This comes as a consequence of the issue with the "static Diffie-Hellmann oracle topic" regarding the OPAQUE OPRF, as brought up recently by Steve Thomas recently on the crypto panel list). Question 5): "(to all 4 remaining PAKEs) What can be said about "post-quantum preparedness" of the PAKE?" Reply to 4): In the Internet Drafts regarding CPace and AuCPace I have added a short discussion on this topic. I believe that the fact that CPace and AuCPace don=E2=80=99t actually requi= re a full group structure but only operations in a "group modulo negation" might provide a path for using isogeny-based cryptography as kind of a drop-in replacement for the Diffie-Hellmann substeps. While primitives such as SIKE and CSIDH provide functionality similar to a DH secret establishment (where both parties contribute to the key), there is no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the isogeny wo= rld. In my opinion, for the augmentation layer of AuCPace, the mechanisms on isogenies for Diffie-Hellmann-style secret establishment could already be used as-is. For the application in CPace (with the need of an isogeny-equivalent of a secret password-derived base point), there is ongoing research which is, however, not yet stabilized and mature in my opinion. Here I have added a links regarding possible migration paths regarding CPace in the security considerations section of the internet draft. Additionally, the modularized security analysis of CPace as a building block of AuCPace allows for replacing the CPace component by any future balanced post-quantum PAKE (in the style that Hugo suggests for OPAQUE). For instance, I believe it to be promising to consider constructions based on the LWE problem where the matrices are kept secret and derived from a password and an ephemeral session id, in the style of "New hope" which uses SHAKE for generation of ephemeral LWE matrices. Still again, this topic, just as the isogenies, would require significant future research in my opinion. I am unfortunately not aware of any current concept regarding a post quantum primitive for the OPRF construction as needed for *strong* AuCPace. Yours, Bj=C3=B6rn Haase P.S.: A compilation regarding my personal view on the current state of the selection process is found at https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selection_a= t_CFRG_Brainpool_20200115.pdf I tried to be as objective as one could reasonably be expecting from an individual having own nominations running. Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards Dr. Bj=C3=B6rn Haase --000000000000cb5e55059e395f36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,

as requested for the beginning of stage = 4 of the second round of the PAKE selection process, I have compiled the ad= ditional documentation at the following places.

Paper:=C2=A0
https://github= .com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analysis_20200208.pd= f

Internet Drafts:
https://tools.iet= f.org/html/draft-haase-aucpace-01
https://too= ls.ietf.org/html/draft-haase-cpace-01

Reference implementations:=
https://github.com/BjoernMHaase/AuCPace


Pl= ease find a short version of my replies below:

Question 2):
"= ;(to CPace and AuCPace): Can you propose a modification of CPace and AuCPac= e (preserving all existing good properties of these PAKEs) with a correspon= dingly updated security proof (maybe, in some other security models), addre= ssing the issue of requiring the establishment of a session identifier (sid= ) during each call of the protocol for the cost of one additional message?&= quot;

Reply to 2) :
I have re-reviewed this issue and integrated = the alternative approach as suggested by Ran Canetti on the CFRG list in th= e paper and security analysis (see =E2=80=9Cpaper=E2=80=9D link above). The= specification in the CPace and AuCPace internet drafts now also correspond= to this approach. With this method, there is no longer the need for an add= itional communication round.

Question 3):
=C2=A0"(to all 4 r= emaining PAKEs) : Can the nominators/developers of the protocols please re-= evaluate possible IPR conflicts between their candidates protocols and own = and foreign patents? Specifically, can you discuss the impact of U.S. Paten= t 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 = and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on t= he free use of the RFC-drafts for OPAQUE?"

Reply to 3):
I ha= ve re-visited all patents and did not find any IPR that might generate conf= licts with CPace and AuCPace. The topic of the mapping algorithms is resolv= ed in my opinion with the latest changes in the hash_to_curve draft (which = avoids the =E2=80=9C-1 non-s=C2=A0 =C2=A0 =C2=A0 =C2=A0quare=E2=80=9D topic= and the =E2=80=9Cthree-polynomial=E2=80=9D issue for SSWU).

In cont= rast, in the course of this research I came to the conclusion that SPAKE2 i= s probably affected by US 7,047,408. The exceptional feature is that the du= ration of this patent seems to have been extended to a period of exceptiona= l 23 years instead of 20 years! I have double-checked and that seems indeed= to be legally possibly in the US. I have just filed a corresponding IPR di= sclosure.

Question 4):
"(to all 4 remaining PAKEs) What can = be said about the property of "quantum annoyance" (an attacker wi= th a quantum computer needs to solve [one or more] DLP per password guess) = of the PAKE?"

Reply to 4):

As previously noted also by = =E2=80=9CSteve Thomas=E2=80=9D, for CPace an active adversary needs to solv= e at least one DLP per password guess this also holds for the conventionall= y augmented AuCPace variant.

The additional guarantee of =E2=80=9Cpr= e-computation attack resistance=E2=80=9D provided by the OPRF construction = of strong AuCPace, however will not be preserved. This means that the *stro= ng* AuCPace protocol will fall back the conventionally augmented AuCPace in= the post-quantum world, which itself is again quantum annoying.=C2=A0 (Thi= s comes as a consequence of the issue with the "static Diffie-Hellmann= oracle topic" regarding the OPAQUE OPRF, as brought up recently by St= eve Thomas recently on the crypto panel list).

Question 5):=C2=A0 &q= uot;(to all 4 remaining PAKEs) What can be said about "post-quantum pr= eparedness" of the PAKE?"

Reply to 4):

In the Inter= net Drafts regarding CPace and AuCPace I have added a short discussion on t= his topic.

I believe that the fact that CPace and AuCPace don=E2=80= =99t actually require a full group structure but only operations in a "= ;group modulo negation" might provide a path for using isogeny-based c= ryptography as kind of a drop-in replacement for the Diffie-Hellmann subste= ps.

While primitives such as SIKE and CSIDH provide functionality si= milar to a DH secret establishment (where both parties contribute to the ke= y), there is no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the = isogeny world. In my opinion, for the augmentation layer of AuCPace, the me= chanisms on isogenies for Diffie-Hellmann-style secret establishment could = already be used as-is. For the application in CPace (with the need of an is= ogeny-equivalent of a secret password-derived base point), there is ongoing= research which is, however, not yet stabilized and mature in my opinion. H= ere I have added a links regarding possible migration paths regarding CPace= in the security considerations section of the internet draft.

Addit= ionally, the modularized security analysis of CPace as a building block of = AuCPace allows for replacing the CPace component by any future balanced pos= t-quantum PAKE (in the style that Hugo suggests for OPAQUE).
=C2=A0For i= nstance, I believe it to be promising to consider constructions based on th= e LWE problem where the matrices are kept secret and derived from a passwor= d and an ephemeral session id, in the style of "New hope" which u= ses SHAKE for generation of ephemeral LWE matrices. Still again, this topic= , just as the isogenies, would require significant future research in my op= inion.

I am unfortunately not aware of any current concept regarding= a post quantum primitive for the OPRF construction as needed for *strong* = AuCPace.

Yours,

Bj=C3=B6rn Haase


P.S.: A compilati= on regarding my personal view on the current state of the selection process= is found at

https://github.com/BjoernMHaase/fe25519/blob/master= /Slides_PAKE_selection_at_CFRG_Brainpool_20200115.pdf

I tried to= be as objective as one could reasonably be expecting from an individual ha= ving own nominations running.


Mit freundlichen Gr=C3=BC=C3=9Fen = I Best Regards

Dr. Bj=C3=B6rn Haase=C2=A0=C2=A0
--000000000000cb5e55059e395f36-- From nobody Mon Feb 10 08:08:05 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7412022A for ; Mon, 10 Feb 2020 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uR0gjQyyTr98 for ; Mon, 10 Feb 2020 06:31:19 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 A5CD5120227 for ; Mon, 10 Feb 2020 06:31:18 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id d10so7383531ljl.9 for ; Mon, 10 Feb 2020 06:31:18 -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=ELJI9VXNGz8J8NTziEuSgHFaY93XsGjHW1EyNYgqdaE=; b=mmBRNMCqSoILEnOblgIZqsoRKatwG04mkKdJMtVqSaCS3S0VW32MQuqgcBmSqoe+IR 7Ms0vWqxjApxuLN2402XwBulT3P9TGIcVQ7iuAotoih+J4zLmm4VP48RXjQbNiEltGcX rlWttiq/fxQ31FJ41pDtimeW0SN4JY0B0QXd7h5LqdTt+QWV7VWXEojzOBulT8XXZNLL 9XWj02bEvh7fydf20rhlb+nhQPjGmdhpf7cdNaS1bfxvoTxn7QgC/NwO1dVjj83HUdCa KuKxtIyAawJQ68zzeVo83PIZL2oBGPYNefbPV8ZNiNRR4siT2BQ33u4BYv/MDRG8Wl4X YBZQ== 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=ELJI9VXNGz8J8NTziEuSgHFaY93XsGjHW1EyNYgqdaE=; b=tMWVh1crsM0ulzDLxuXj0/u6Hfb2lnjoxvdj2GP9EcS1873vXYuNV0hIcQn7kr9MAy cvyYlEy3DF9RN1p9dp/7Qg7ZH1/g7D4IF2tdhNC7wbQbuMUewVaclMzCx7yz46ByRTnI Xz4SP3weY9vhyDTMgPu+Qb0ti7nsOBpOEVQcXva9QTtihqF2jnXIq0ljLt3FjP6GiKMx jp8cckpKzMJsUvxCjSyCvqQZHHjwYnchZJBX0KIDYDnmFKLRF/M0srfockTeKdiV+XSR iCChoCmOWjQMwfmkkhHwbTinJ9L/GR+e72RmlGOr47vHcQVxfZhKCNS7uVCiUwFHvHQo pt5g== X-Gm-Message-State: APjAAAWuK9PQWUJlzlvNQiewc0D8cykx3AlHjO9h3pooetP/f5ogc6HS NZQi+CHcoQDF2sV1qzD3D1Ti0tiezn/qmv1bfR8= X-Google-Smtp-Source: APXvYqzcPn2ZLkctHv8FcnJigBh4zAUYlcw0imMfVyGY9NW4DsVNI1PyJ7QkyR5LWJ9neOUj55lsimr/MnGz633lqfw= X-Received: by 2002:a2e:b007:: with SMTP id y7mr1044117ljk.215.1581345076836; Mon, 10 Feb 2020 06:31:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 17:32:24 +0300 Message-ID: To: Jean-Philippe Aumasson Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000927db8059e3997f1" Archived-At: Subject: Re: [Crypto-panel] Request for review of draft-irtf-cfrg-kangarootwelve X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 14:31:21 -0000 --000000000000927db8059e3997f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Crypto Review Panel members, Any other volunteers to review the draft?.. Regards, Stanislav On Fri, 7 Feb 2020 at 11:03, Stanislav V. Smyshlyaev wrote: > Yes, but since the document has already been adopted as a RG item, I thin= k > that "relevance of the topic wrt CFRG's goals" is not necessary. > Nevertheless, all comments are always welcome - in any case, additional > discussions during/after Research Group Last Call can be even more > productive if many important points are highlighted by the review(s). > > Regards, > Stanislav > > On Fri, 7 Feb 2020 at 10:59, Jean-Philippe Aumasson < > jeanphilippe.aumasson@gmail.com> wrote: > >> Sounds good :) >> >> I'm familiar with CFRG's goal but as it's my first review, wanna make >> sure that we agree on the goals: do these include.. ? >> >> 1. technical correctness of the document >> 2. editorial quality >> 3. value of the content against alternative solutions >> 4. relevance of the topic wrt CFRG's goals >> >> Thanks! >> >> >> On Fri, Feb 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev >> wrote: >> >>> Dear Jean-Philippe, >>> >>> Many thanks for your reply, your readiness to do a review and for the >>> warning! >>> Regardimg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypt= o Review >>> Panel reviews for the draft-irtf-cfrg-kangarootwelve draft can be >>> considered as independent opinions of the experts, that can help to >>> highlight possible problems with the document (and can be disputed late= r by >>> the authors). >>> >>> In my personal opinion (with my CFRG chair hat off), if you >>> mention conflict-of-interest warning in your review, that will be enoug= h. >>> >>> Regards, >>> Stanislav >>> >>> On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumasson < >>> jeanphilippe.aumasson@gmail.com> wrote: >>> >>>> Hi! >>>> >>>> sure, but conflict-of-interest warning: I'm a co-designer of BLAKE3 ( >>>> https://blake3.io), a function that can be seen as a competitor of K12 >>>> in the super-fast, parallel hash category. I can do the review as >>>> objectively as I can but could understand that the CoI might be a conc= ern >>>> for some (including the draft authors). >>>> >>>> wdyt? >>>> >>>> Cheers, >>>> >>>> JP >>>> >>>> On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev < >>>> smyshsv@gmail.com> wrote: >>>> >>>>> Dear Jean-Philippe, >>>>> >>>>> As we discussed yesterday with Alexey and Nick, we would like to ask >>>>> you about reviewing the current version of draft-irtf-cfrg-kangarootw= elve ( >>>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). >>>>> Could you consider the possibility of providing such a review? >>>>> >>>>> Of course, we will be happy to receive reviews from all Crypto Review >>>>> Panel members. >>>>> >>>>> Regards, >>>>> Stanislav (on behalf of the CFRG chairs) >>>>> >>>>> --000000000000927db8059e3997f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Crypto Review Panel members,
Any other volunteers to review the draft?..

Regards,
Stanislav

On Fri, 7 Feb 2020 at 11:03, Stanis= lav V. Smyshlyaev <smyshsv@gmail.co= m> wrote:
Yes, but since the document has already been adopted as a= RG item, I think that "relevance of the topic wrt CFRG's goals&qu= ot; is not necessary. Nevertheless, all comments are always welcome - in an= y case, additional discussions during/after Research Group Last Call can be= even more productive if many important points are highlighted by the revie= w(s).

Regards,
Stanislav

On Fri, 7 Feb 20= 20 at 10:59, Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> w= rote:
Sounds good :)

I'm familiar with= CFRG's goal but as it's my first review, wanna make sure that we a= gree on the goals: do these include.. ?

1. technic= al correctness of the document
2. editorial quality
3. = value of the content against alternative solutions
4. relevance o= f the topic wrt CFRG's goals

Thanks!


On Fri, Feb 7, 2020 at 8:50 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com>= wrote:
Dear Jean-Philippe,

Many thanks for your reply,= your readiness to do a review and for the warning!=C2=A0
Regardi= mg BLAKE3 =E2=80=93 unlike the PAKE selection process, the Crypto Review Pa= nel reviews for the=20 draft-irtf-cfrg-kangarootwelve draft can be considered as independent opinions of the experts, that can he= lp to highlight possible problems with the document (and can be disputed la= ter by the authors).

In my personal opinion (w= ith my CFRG chair hat off), if you mention=C2=A0conflict-of-interest warnin= g in your review, that will be enough.

Regards= ,
Stanislav

On Fri, 7 Feb 2020 at 10:27, Jean-Philippe Aumas= son <jeanphilippe.aumasson@gmail.com> wrote:
Hi!

su= re, but conflict-of-interest warning: I'm a co-designer of BLAKE3 (https://blake3.io), a funct= ion that can be seen as a competitor of K12 in the super-fast, parallel has= h category. I can do the review as objectively as I can but could understan= d that the CoI might be a concern for some (including the draft authors).

wdyt?

Cheers,
JP

On Fri, Feb 7, 2020 at 7:50 AM Stanislav V. Smyshlyaev= <smyshsv@gmail.c= om> wrote:
Dear Jean-Philippe,

As we discussed = yesterday with Alexey and Nick, we would like to ask you about reviewing th= e current version of=C2=A0draft-irtf-cfrg-kangarootwelve (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kangarootwelve/). C= ould you consider the possibility of providing such a review?
Of course, we will be happy to receive reviews from all Crypto = Review Panel members.

Regards,
Stani= slav (on behalf of the CFRG chairs)

--000000000000927db8059e3997f1-- From nobody Mon Feb 10 08:12:15 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7E120863 for ; Mon, 10 Feb 2020 08:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ajpx_vuQ6hAB for ; Mon, 10 Feb 2020 08:07:11 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 A273C120879 for ; Mon, 10 Feb 2020 08:07:04 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id z26so4532250lfg.13 for ; Mon, 10 Feb 2020 08:07: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=uf2YolYNmk/EM4BrYjxyexkWqtVQ0ZF3WlySy8aj5n0=; b=tcULxZ/IBumrof+Wuy2H34DfQb3jmHl1ZAJ63DBE3SsjE3Z5zWyHJTW+kK+f0Nj6O+ Uh2pWudkG9fQrmUYH9o4qL48FbFTnszUZlWPh2NsXuYiZI0rfeIs43++P5TUfrP+nhI5 FK0uOF1hSCrVuzmE317h0b4dH+3XWfhuNB+LzYFGkp8ro6YYc8j9/M+NeFuCIiKGGxAn n0WIQuEhE+wLZqFPc9QjFQKl6HA0Z1G7SHzh8+xvpYBKHVQ4J3S3IgwNePXNkOFtrmuG Q4RHqSrWf6QIK6hXOhOAy5h+Gx8rpFtObvM/KkIwW/pGLkyqkUrx3q2KOtof02DRzr5r dtMQ== 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=uf2YolYNmk/EM4BrYjxyexkWqtVQ0ZF3WlySy8aj5n0=; b=PS3E8dwQykfczX4IUAR9FqZEw0g8fv2hwBO+FkCeie0XfdqsRvwfodru6HroUptSCp nCy8yhMoS5yN1sCBcoVGjc7qYEhMMRBUNQbjT+BSnhPaJX1p3Dzy42s+pWave9Apd5EY DafuevzUvutWI3ZIsv3qKyF2k9XYW0CNK+MoQfpRXI8Jb4hiFKaYjuGsWUZMvsVUBYIw FEZ7y936LgW8JnfnQsEHZ3mAueSkERvU8u39HlngHZAcH6+rLI832mA5P/+Tj9CSUHSK CcP56lFHiEYMEnTr6Y4+w71oZwmRB+HdMMl/XcPiu/YaeVutINIRaZTX+bg/stv4z498 tiWg== X-Gm-Message-State: APjAAAX0XXlrjMa3FbHX0lMaPVGDgitjl5NBDw6HOU5R8MDyX2RwJB7W mFW4G/X7EN4COvmdawqIgnDeBAn3lfBXoWHMfEs= X-Google-Smtp-Source: APXvYqxX0tVT/KfNG8McKJCOxzYHpIb1Ak5mpfAzUD8tfTX+LL0YGArh13ipTSZxYwEBO3iu0hjzqUajesC2kRU3fkA= X-Received: by 2002:ac2:4c84:: with SMTP id d4mr1114822lfl.64.1581350822754; Mon, 10 Feb 2020 08:07:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 19:06:44 +0300 Message-ID: To: Watson Ladd Cc: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="0000000000000e3ec8059e3aeefe" Archived-At: Subject: Re: [Crypto-panel] Answers to PAKE Questions X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 16:07:18 -0000 --0000000000000e3ec8059e3aeefe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Many thanks, Watson! =D0=BF=D0=BD, 10 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 19:03, Watso= n Ladd : > This time with correct email > > > On Sun, Feb 9, 2020 at 9:43 PM Watson Ladd wrote: > > > > Question 1: (to SPAKE2): Can you propose a modification of SPAKE2 > > (preserving all > > > > existing good properties of PAKE2) with a correspondingly updated > security > > > > proof, addressing the issue of a single discrete log relationship > necessary > > > > for the security of all sessions (e.g., solution based on using > > > > M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))? > > > > > > The next version will include an option to have M and N based on party > > identities, ensuring that an attacker with the ability to solve a > > discrete logarithm problem can only compromise a single session per > > discrete logarithm computed. This form does introduce a dependency on > > the hash2curve draft, and requires an invocation of hash2curve per > > pair of participants. The proof of such a construction is in > > https://eprint.iacr.org/2019/1194. > > > > > > Question 2:Can the nominators/developers of the > > > > protocols please re-evaluate possible IPR conflicts between their > > > > candidates protocols and own and foreign patents? Specifically, can you > > > > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th o= f > > > > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > > > > expected expiration October 2026) on the free use of the RFC-drafts for > > > > OPAQUE? > > > > > > I=E2=80=99m not a patent lawyer, and cannot speculate on any IPR confli= cts > > that may or may not exist. > > > > > > Question 4:What can be said about the property of > > > > "quantum annoyance" (an attacker with a quantum computer needs to solve > > > > [one or more] DLP per password guess) of the PAKE? > > > > > > An adversary needs to solve a single DLP and then carry out an online > > attack to recover the password without further quantum work. > > > > > > Question 5: What can be said about "post-quantum preparedness" of the > PAKE? > > > > SPAKE2 is unlikely to have a post-quantum alternative. > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000000e3ec8059e3aeefe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks, Watson!

=D0=BF=D0=BD, 10 =D1= =84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 19:03, Watson Ladd <watsonbladd@gmail.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">This time with correct email


On Sun, Feb 9, 2020 at 9:43 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>
> Question 1: (to SPAKE2): Can you propose a modification of SPAKE2
> (preserving all
>
> existing good properties of PAKE2) with a correspondingly updated secu= rity
>
> proof, addressing the issue of a single discrete log relationship nece= ssary
>
> for the security of all sessions (e.g., solution based on using
>
> M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))?
>
>
> The next version will include an option to have M and N based on party=
> identities, ensuring that an attacker with the ability to solve a
> discrete logarithm problem can only compromise a single session per > discrete logarithm computed. This form does introduce a dependency on<= br> > the hash2curve draft, and requires an invocation of hash2curve per
> pair of participants. The proof of such a construction is in
> https://eprint.iacr.org/2019/1194.
>
>
> Question 2:Can the nominators/developers of the
>
> protocols please re-evaluate possible IPR conflicts between their
>
> candidates protocols and own and foreign patents? Specifically, can yo= u
>
> discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th = of
>
> march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV,=
>
> expected expiration October 2026) on the free use of the RFC-drafts fo= r
>
> OPAQUE?
>
>
> I=E2=80=99m not a patent lawyer, and cannot speculate on any IPR confl= icts
> that may or may not exist.
>
>
> Question 4:What can be said about the property of
>
> "quantum annoyance" (an attacker with a quantum computer nee= ds to solve
>
> [one or more] DLP per password guess) of the PAKE?
>
>
> An adversary needs to solve a single DLP and then carry out an online<= br> > attack to recover the password without further quantum work.
>
>
> Question 5: What can be said about "post-quantum preparedness&quo= t; of the PAKE?
>
> SPAKE2 is unlikely to have a post-quantum alternative.



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000000e3ec8059e3aeefe-- From nobody Mon Feb 10 08:12:21 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBD71208B7 for ; Mon, 10 Feb 2020 08:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nF2SH6sGb2Nw for ; Mon, 10 Feb 2020 08:08:42 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 55E4A12087C for ; Mon, 10 Feb 2020 08:08:38 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id h23so7776386ljc.8 for ; Mon, 10 Feb 2020 08:08:38 -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=g3z4yrB5Q6UOft3FgKhzhZbOhcOCh2iQLmrDOzspCL0=; b=rQiXcA/4j5wwzqzWxx9QQsA2fuhz0OPIQkI6N3J7abpf3YRrqNjSvxEO7mDPQqqFEO 2INEnJ9CeNLsktn99YruPQM5x0dpDmSS5Ar4fl8vCAlPDe/DqfmMlI8FYkCJbecRtCBM 8921ae5WlZr+GYJNydCwroT9vFz0sVqttEPlUDv4OopYNG20vnXNNPdhm6SxFsYVWOXh IX+R9WPvlBxXq4pvbVEPjOmllqq8rWAOjkLCcwsNk4f8bgCAbCnrtyNu+P6M4kVLIDUl U+Z+qsC57P/hiiG2B3cTqJD2Cy630gCg2YuuTmO0pqqFFsVFpAYXUZhYx2jVTzSvdjwO rM9g== 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=g3z4yrB5Q6UOft3FgKhzhZbOhcOCh2iQLmrDOzspCL0=; b=iI+D8p1lurZbQzmHjxhNLcY3mE0clWmUMYlbGVX1h+Lqg0TTEofH/o3WNjjqSyajRQ jH71d7OGLL6KMq9mPRABUeB/LQNZ4mqo9hNkMXw/dwSkMGr4F8mo/DHJYVilYJyzmX6h OCGL2bxINugYnZe9J67Rk0XbQq9cEgeRrwBtHMteuBDLgi5LcuorqTvB69QqA9ewDbPI ObPV0IgwbsVQF3Y+EGdYynisGoUTTC33lnWh4R9eOkyMXGJYAx0ldSSCZ5Xo2UHKAl8s zfYpJhOvyMPq/u3u1+Y1i5iHxcO7qJJ8AlD7QyAW4+5+1aKFmWtLaoUx529xKdG1Ykbk v/cA== X-Gm-Message-State: APjAAAUJPEyoGwYwvr1HEuKWCK+If26u5TKsHHBOmllCMcA6egJdBr2l BjyTgX5N2Vlf75c+aGfZslnza+YVjG31RLvg4dU= X-Google-Smtp-Source: APXvYqzAzY3KGFIlGVwxe/8Qlx2Y1QxRBXH2N18zmpeJF2zKg01ehWslMQ1wz5kXtlJ+gxBAbkMxTai9Kno+MZFSx0M= X-Received: by 2002:a2e:b007:: with SMTP id y7mr1289093ljk.215.1581350915415; Mon, 10 Feb 2020 08:08:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 19:08:24 +0300 Message-ID: To: =?UTF-8?B?QmrDtnJuIEhhYXNl?= Cc: "cfrg-chairs@ietf.org" , "crypto-panel@irtf.org" Content-Type: multipart/alternative; boundary="00000000000094230c059e3af3c9" Archived-At: Subject: Re: [Crypto-panel] PAKE Selection Process: Round 2, Stage 2 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 16:08:50 -0000 --00000000000094230c059e3af3c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Many thanks, Bj=C3=B6rn! =D0=BF=D0=BD, 10 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 11:36, Bj=C3= =B6rn Haase : > Dear CFRG, > > as requested for the beginning of stage 4 of the second round of the PAKE > selection process, I have compiled the additional documentation at the > following places. > > Paper: > > https://github.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_anal= ysis_20200208.pdf > > Internet Drafts: > https://tools.ietf.org/html/draft-haase-aucpace-01 > https://tools.ietf.org/html/draft-haase-cpace-01 > > Reference implementations: > https://github.com/BjoernMHaase/AuCPace > > > Please find a short version of my replies below: > > Question 2): > "(to CPace and AuCPace): Can you propose a modification of CPace and > AuCPace (preserving all existing good properties of these PAKEs) with a > correspondingly updated security proof (maybe, in some other security > models), addressing the issue of requiring the establishment of a session > identifier (sid) during each call of the protocol for the cost of one > additional message?" > > Reply to 2) : > I have re-reviewed this issue and integrated the alternative approach as > suggested by Ran Canetti on the CFRG list in the paper and security > analysis (see =E2=80=9Cpaper=E2=80=9D link above). The specification in t= he CPace and > AuCPace internet drafts now also correspond to this approach. With this > method, there is no longer the need for an additional communication round= . > > Question 3): > "(to all 4 remaining PAKEs) : Can the nominators/developers of the > protocols please re-evaluate possible IPR conflicts between their > candidates protocols and own and foreign patents? Specifically, can you > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > expected expiration October 2026) on the free use of the RFC-drafts for > OPAQUE?" > > Reply to 3): > I have re-visited all patents and did not find any IPR that might generat= e > conflicts with CPace and AuCPace. The topic of the mapping algorithms is > resolved in my opinion with the latest changes in the hash_to_curve draft > (which avoids the =E2=80=9C-1 non-s quare=E2=80=9D topic and the = =E2=80=9Cthree-polynomial=E2=80=9D > issue for SSWU). > > In contrast, in the course of this research I came to the conclusion that > SPAKE2 is probably affected by US 7,047,408. The exceptional feature is > that the duration of this patent seems to have been extended to a period = of > exceptional 23 years instead of 20 years! I have double-checked and that > seems indeed to be legally possibly in the US. I have just filed a > corresponding IPR disclosure. > > Question 4): > "(to all 4 remaining PAKEs) What can be said about the property of > "quantum annoyance" (an attacker with a quantum computer needs to solve > [one or more] DLP per password guess) of the PAKE?" > > Reply to 4): > > As previously noted also by =E2=80=9CSteve Thomas=E2=80=9D, for CPace an = active adversary > needs to solve at least one DLP per password guess this also holds for th= e > conventionally augmented AuCPace variant. > > The additional guarantee of =E2=80=9Cpre-computation attack resistance=E2= =80=9D provided > by the OPRF construction of strong AuCPace, however will not be preserved= . > This means that the *strong* AuCPace protocol will fall back the > conventionally augmented AuCPace in the post-quantum world, which itself = is > again quantum annoying. (This comes as a consequence of the issue with t= he > "static Diffie-Hellmann oracle topic" regarding the OPAQUE OPRF, as broug= ht > up recently by Steve Thomas recently on the crypto panel list). > > Question 5): "(to all 4 remaining PAKEs) What can be said about > "post-quantum preparedness" of the PAKE?" > > Reply to 4): > > In the Internet Drafts regarding CPace and AuCPace I have added a short > discussion on this topic. > > I believe that the fact that CPace and AuCPace don=E2=80=99t actually req= uire a > full group structure but only operations in a "group modulo negation" mig= ht > provide a path for using isogeny-based cryptography as kind of a drop-in > replacement for the Diffie-Hellmann substeps. > > While primitives such as SIKE and CSIDH provide functionality similar to = a > DH secret establishment (where both parties contribute to the key), there > is no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the isogeny = world. In my > opinion, for the augmentation layer of AuCPace, the mechanisms on isogeni= es > for Diffie-Hellmann-style secret establishment could already be used as-i= s. > For the application in CPace (with the need of an isogeny-equivalent of a > secret password-derived base point), there is ongoing research which is, > however, not yet stabilized and mature in my opinion. Here I have added a > links regarding possible migration paths regarding CPace in the security > considerations section of the internet draft. > > Additionally, the modularized security analysis of CPace as a building > block of AuCPace allows for replacing the CPace component by any future > balanced post-quantum PAKE (in the style that Hugo suggests for OPAQUE). > For instance, I believe it to be promising to consider constructions > based on the LWE problem where the matrices are kept secret and derived > from a password and an ephemeral session id, in the style of "New hope" > which uses SHAKE for generation of ephemeral LWE matrices. Still again, > this topic, just as the isogenies, would require significant future > research in my opinion. > > I am unfortunately not aware of any current concept regarding a post > quantum primitive for the OPRF construction as needed for *strong* AuCPac= e. > > Yours, > > Bj=C3=B6rn Haase > > > P.S.: A compilation regarding my personal view on the current state of th= e > selection process is found at > > > https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selection= _at_CFRG_Brainpool_20200115.pdf > > I tried to be as objective as one could reasonably be expecting from an > individual having own nominations running. > > > Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards > > Dr. Bj=C3=B6rn Haase > > > Senior Expert Electronics | TGREH Electronics Hardware > Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | > Germany > Phone: +49 7156 209 377 | Fax: +49 7156 209 221 > bjoern.haase@endress.com | www.conducta.endress.com > > > > Endress+Hauser Conducta GmbH+Co.KG > Amtsgericht Stuttgart HRA 201908 > Sitz der Gesellschaft: Gerlingen > Pers=C3=B6nlich haftende Gesellschafterin: > Endress+Hauser Conducta Verwaltungsgesellschaft mbH > Sitz der Gesellschaft: Gerlingen > Amtsgericht Stuttgart HRA 201929 > Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella > > > Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu > informieren, wenn wir personenbezogene Daten von Ihnen erheben. > Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis ( > https://www.endress.com/de/cookies-endress+hauser-website) nach. > > > > Disclaimer: > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other u= se > of, or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. If you recei= ve > this in error, please contact the sender and delete the material from any > computer. This e-mail does not constitute a contract offer, a contract > amendment, or an acceptance of a contract offer unless explicitly and > conspicuously designated or stated as such. > > --00000000000094230c059e3af3c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks, Bj=C3=B6rn!

=D0=BF=D0=BD, 10 = =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 11:36, Bj=C3=B6rn Haase <<= a href=3D"mailto:bjoern.haase@endress.com">bjoern.haase@endress.com>= :
Dear CFRG,

as requested for the beginning of stage 4 of the second round of the PAKE s= election process, I have compiled the additional documentation at the follo= wing places.

Paper:=C2=A0
https://gi= thub.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analysis_2020020= 8.pdf

Internet Drafts:
https://tools.ietf.org/html/draft-haase-aucpace-01=
https://tools.ietf.org/html/draft-haase-cpace-01=

Reference implementations:
https://github.com/BjoernMHaase/AuCPace


Please find a short version of my replies below:

Question 2):
"(to CPace and AuCPace): Can you propose a modification of CPace and A= uCPace (preserving all existing good properties of these PAKEs) with a corr= espondingly updated security proof (maybe, in some other security models), = addressing the issue of requiring the establishment of a session identifier= (sid) during each call of the protocol for the cost of one additional mess= age?"

Reply to 2) :
I have re-reviewed this issue and integrated the alternative approach as su= ggested by Ran Canetti on the CFRG list in the paper and security analysis = (see =E2=80=9Cpaper=E2=80=9D link above). The specification in the CPace an= d AuCPace internet drafts now also correspond to this approach. With this m= ethod, there is no longer the need for an additional communication round.
Question 3):
=C2=A0"(to all 4 remaining PAKEs) : Can the nominators/developers of t= he protocols please re-evaluate possible IPR conflicts between their candid= ates protocols and own and foreign patents? Specifically, can you discuss t= he impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023)= on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expira= tion October 2026) on the free use of the RFC-drafts for OPAQUE?"

Reply to 3):
I have re-visited all patents and did not find any IPR that might generate = conflicts with CPace and AuCPace. The topic of the mapping algorithms is re= solved in my opinion with the latest changes in the hash_to_curve draft (wh= ich avoids the =E2=80=9C-1 non-s=C2=A0 =C2=A0 =C2=A0 =C2=A0quare=E2=80=9D t= opic and the =E2=80=9Cthree-polynomial=E2=80=9D issue for SSWU).

In contrast, in the course of this research I came to the conclusion that S= PAKE2 is probably affected by US 7,047,408. The exceptional feature is that= the duration of this patent seems to have been extended to a period of exc= eptional 23 years instead of 20 years! I have double-checked and that seems= indeed to be legally possibly in the US. I have just filed a corresponding= IPR disclosure.

Question 4):
"(to all 4 remaining PAKEs) What can be said about the property of &qu= ot;quantum annoyance" (an attacker with a quantum computer needs to so= lve [one or more] DLP per password guess) of the PAKE?"

Reply to 4):

As previously noted also by =E2=80=9CSteve Thomas=E2=80=9D, for CPace an ac= tive adversary needs to solve at least one DLP per password guess this also= holds for the conventionally augmented AuCPace variant.

The additional guarantee of =E2=80=9Cpre-computation attack resistance=E2= =80=9D provided by the OPRF construction of strong AuCPace, however will no= t be preserved. This means that the *strong* AuCPace protocol will fall bac= k the conventionally augmented AuCPace in the post-quantum world, which its= elf is again quantum annoying.=C2=A0 (This comes as a consequence of the is= sue with the "static Diffie-Hellmann oracle topic" regarding the = OPAQUE OPRF, as brought up recently by Steve Thomas recently on the crypto = panel list).

Question 5):=C2=A0 "(to all 4 remaining PAKEs) What can be said about = "post-quantum preparedness" of the PAKE?"

Reply to 4):

In the Internet Drafts regarding CPace and AuCPace I have added a short dis= cussion on this topic.

I believe that the fact that CPace and AuCPace don=E2=80=99t actually requi= re a full group structure but only operations in a "group modulo negat= ion" might provide a path for using isogeny-based cryptography as kind= of a drop-in replacement for the Diffie-Hellmann substeps.

While primitives such as SIKE and CSIDH provide functionality similar to a = DH secret establishment (where both parties contribute to the key), there i= s no such equivalent of =E2=80=9Cpoint addition=E2=80=9D in the isogeny wor= ld. In my opinion, for the augmentation layer of AuCPace, the mechanisms on= isogenies for Diffie-Hellmann-style secret establishment could already be = used as-is. For the application in CPace (with the need of an isogeny-equiv= alent of a secret password-derived base point), there is ongoing research w= hich is, however, not yet stabilized and mature in my opinion. Here I have = added a links regarding possible migration paths regarding CPace in the sec= urity considerations section of the internet draft.

Additionally, the modularized security analysis of CPace as a building bloc= k of AuCPace allows for replacing the CPace component by any future balance= d post-quantum PAKE (in the style that Hugo suggests for OPAQUE).
=C2=A0For instance, I believe it to be promising to consider constructions = based on the LWE problem where the matrices are kept secret and derived fro= m a password and an ephemeral session id, in the style of "New hope&qu= ot; which uses SHAKE for generation of ephemeral LWE matrices. Still again,= this topic, just as the isogenies, would require significant future resear= ch in my opinion.

I am unfortunately not aware of any current concept regarding a post quantu= m primitive for the OPRF construction as needed for *strong* AuCPace.

Yours,

Bj=C3=B6rn Haase


P.S.: A compilation regarding my personal view on the current state of the = selection process is found at

https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selecti= on_at_CFRG_Brainpool_20200115.pdf

I tried to be as objective as one could reasonably be expecting from an ind= ividual having own nominations running.


Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards

Dr. Bj=C3=B6rn Haase


Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | G= ermany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
bjoern.haase@= endress.com |=C2=A0 www.conducta.endress.com



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Pers=C3=B6nlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella

=C2=A0
Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu inform= ieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hau= ser-website) nach.

=C2=A0

Disclaimer:

The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential, proprietary, and/or privi= leged material. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon, this information by persons or en= tities other than the intended recipient is prohibited. If you receive this= in error, please contact the sender and delete the material from any compu= ter. This e-mail does not constitute a contract offer, a contract amendment= , or an acceptance of a contract offer unless explicitly and conspicuously = designated or stated as such.

--00000000000094230c059e3af3c9-- From nobody Mon Feb 10 08:24:41 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA9120855; Mon, 10 Feb 2020 08:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 h3YcRDz43kYQ; Mon, 10 Feb 2020 08:24:16 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 8EFFE120853; Mon, 10 Feb 2020 08:24:15 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id l18so4634458lfc.1; Mon, 10 Feb 2020 08:24:15 -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=IBLCsEfByyD/GQx9itQQyWsi/waAUzsgyZmzT9qsUNE=; b=F4qLJLIJkxO8lmlqwKd3zob5yh4KLceJ3L1/yg2T2cTppMa1OGuykHs5TC6k1+HYmH 1ezsv2iDxzwf5QRsp5XJhX7D5d33Wq2D/udKrkK2KqO8frjEF5Uu/kMIjuhh0Ug9e7fS IQko66CYpbSDq3j0SeLf4REH4WrvOY00iTThAkadO2KxKEHtNHikEdWSQheDSfjr1Zab HbN67Dxej2wM+MASZzvz/nBY6NzdHIsoOuDneFtw+kCeHdSoToqfI7ejitYYUpTlZL2l Df7odU8SnOQNUEGcyqhNStH/+pftYX8OoKxFWaAzvU2/UHqdD0A6vDdlgKl1hp0QkWeQ juVw== 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=IBLCsEfByyD/GQx9itQQyWsi/waAUzsgyZmzT9qsUNE=; b=RfTVCqIBcmu8M9ogd3AWdIw5W+sS1UCboDt8JEXM9mOjH7CIKzAlAKORVFQX2tDCVR BINrANiTPP5GLwi7geEwGQ7PiCOtkFHTUNfx0videLRLYwjEAruqhABhBjTFflF35krh 4hGASOdSgaF+q0NzyXw/vbWENB8OeOWMJ3/r1MGzT7MO5ro0CVLi5cqXtEIr80mwA1g1 7iRAgWVxR+redYeqdvCoLi9BwhJ+3lgkIxJaavY+iB422edQi/DX8IK6/rfJbSgpGRvC nED0C4fjloJgte5FCbHUddj08ogavp4Da8GBfD7LVNNEEuRVppEXRhlz0DgXMeDjj+um OxSA== X-Gm-Message-State: APjAAAUAY5B5j++btQdoXicl90Yd5gOcE2epN/nwV/NrNLOgNTvg9QKm eKenTezsZMyz7jPWby03mGEtT/cHZYxKqxFeJgk= X-Google-Smtp-Source: APXvYqxjK1LKMKnqR434E8EZ7GiQaNSBok9Kym2YsGlH7mTDfZmpHwcZ4fB3l09rRtv25N7d89jjVbS17H0y1E/+8BU= X-Received: by 2002:a19:6449:: with SMTP id b9mr1151960lfj.5.1581351853276; Mon, 10 Feb 2020 08:24:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 10 Feb 2020 19:24:02 +0300 Message-ID: To: Hugo Krawczyk Cc: CFRG , cfrg-chairs@ietf.org, "crypto-panel@irtf.org" Content-Type: multipart/alternative; boundary="0000000000007ac25f059e3b2b98" Archived-At: Subject: Re: [Crypto-panel] OPAQUE responses (PAKE Selection Process: Round 2, Stage 2) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 16:24:27 -0000 --0000000000007ac25f059e3b2b98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Many thanks, Hugo! =D0=BF=D0=BD, 10 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 19:22, Hugo = Krawczyk : > Dear Stanislav and the CFRG selection committee, > > Below are answers to the questions you posed for OPAQUE. > Let me know if you need more information at this time. > > As a reminder, our analysis paper is in > https://eprint.iacr.org/2018/163.pdf > At the end of the introduction you can find several notes explaining the > revisions we did since the time we initially submitted OPAQUE to this > selection > process. Some of the important revisions were motivated by the excellent > feedback from this committee (especially Bjorn and Julia). We are truly > grateful > for that. The protocol itself has not changed except for noting that the > (full) > PFS requirement for the key exchange component (AKE) eliminates the optio= n > of a > 2-message protocol (see my email to cfrg from 11/18/2019). This does not > change > the analysis of OPAQUE performed by the TLS and IKE teams. > > The current internet draft (revision 03) is in > https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/ > It is intended as a high level description of the protocol built in a > modular > way based on three components: OPRF, Authenticated Encryption, and AKE. > The draft is purposely light in implementation details. These details wil= l > emerge through CFRG input as well as via our work on implementation plann= ed > to > start very soon in collaboration with a group of IETF and TLS 1.3 experts= . > We expect to build on existing tools and specifications, particularly the > OPRF > work in https://tools.ietf.org/html/draft-irtf-cfrg-voprf-02 and AKE > specifications borrowed from TLS 1.3. See also response to question (3) > below. > > The only module currently lacking a standardized specification is the > key-committing authenticated encryption required for building the OPAQUE > envelope. Several simple options are listed in the OPAQUE draft, one of > which > will be chosen for specification and implementation. There is also the > option > of minimizing the size of envelope for communication-constrained scenario= s. > > =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=3D > > Question 3 (to all 4 remaining PAKEs): Can the nominators/developers of t= he > protocols please re-evaluate possible IPR conflicts between their > candidates > protocols and own and foreign patents? > > OPAQUE can use any AKE (with KCI and PFS security) and therefore is not > limited > to any particular AKE protocol. The current OPAQUE internet draft > illustrates > the protocol using HMQV and SIGMA as the AKE component. HMQV is presented > as the most efficient instantiation and SIGMA as the basis for integratio= n > with TLS 1.3 > and IKEv2. Since HMQV is encumbered by an IBM-owned patent, the > instantiation > with HMQV cannot be standardized, at least for the moment (it can change = if > IBM > agrees to donate the patent for royalty-free use within OPAQUE). The 3DH > protocol (the basis of Signal) can serve as a drop-in replacement for HMQ= V > as > the only difference between the protocols is in the formula for the > computation > of the session key (which involves one extra exponentiation in 3DH). > > However, moving forward, OPAQUE specification and implementation will > center > around SIGMA as this is the way the protocol would be integrated with TLS > 1.3 > and IKEv2 (both of which build on SIGMA already). It is important to note > that > any asymmetric PAKE requires a mechanism that will protect user account > information and a data channel protocol for transmitting data protected > under > the shared session key. It makes no sense to re-invent any of these > mechanisms > rather than using established and standardized protocols like TLS or > IKE/IPsec. > Furthermore, when run inside TLS 1.3 (similarly for IKEv2), the cost of > OPAQUE-SIGMA-ECDSA is virtually the same as with HMQV (just one extra > fixed-base exponentiation for server and client). > > In comparison to Strong AuCPace, OPAQUE-SIGMA-ECDSA is more efficient in > terms of exponentiations and number of messages. The latter is particular= ly > advantageous for integration with TLS 1.3. An additional performance > advantage > of OPAQUE is that the DH exchange in TLS and IKE is re-used in OPAQUE whi= le > for AuCPace it represents an additional cost (one fixed and one variable > exponentiation for client and server). The favorable performance cost of > OPAQUE > when integrated with TLS, in terms of number of messages and > exponentiations, > holds also with respect to non-strong AuCPace. > > The size of the OPAQUE envelope can be minimized in settings where server > storage and/or communication are scarce resources. > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Question 5 (to all 4 remaining PAKEs): What can be said about "post-quant= um > preparedness" of the PAKE? > > I have already expressed my opinion that post-quantum-preparedness is a > much > more important property than "quantum annoyance" in this posting from > 10/27/2019: > > https://mailarchive.ietf.org/arch/browse/cfrg/?q=3DQuantum%20annoyance%20= vs%20post-quantum%20preparedness > > Thus, I will first refer to the really important question: Post-Quantum > (PQ) > preparedness. > > OPAQUE seems to be the only candidate among all CFRG proposals that could > be > implemented today with a full PQ design, albeit not a very efficient one. > Indeed, one can take any PQ PKE submission to NIST's competition and > generate > a PQ AKE with the properties of forward secrecy and KCI required by OPAQU= E > [1]. > As for the OPRF, we already have candidate PQ instantiations of this > primitive > [2,3] though not efficient enough for current deployment. > > However, note that even if the OPRF is not PQ but the AKE is (e.g., when > TLS, or > other settings where OPAQUE is used, adopts a PQ AKE), data will remain > secure > even if the OPRF is fully broken in the future. This is similar to the > situation with digital signatures used in TLS 1.3. Breaking them in the > future > has no bearing on data protected under keys authenticated with these > signatures. > One difference is that breaking the DH-OPRF in the future would enable a > dictionary attack on the user's password as used in the past (say, 10-20 > years > earlier). However, once TLS moves to PQ AKE (before that all data will be > vulnerable, with and without OPAQUE), this attack will be limited to acti= ve > attackers. Namely, only attackers that actively impersonated a user in an > OPAQUE session with the old OPRF may be able to attack the password in th= e > future. In other words, to learn today's password in 10-20 years, an > attacker > needs to impersonate the user now, hope that in 10-20 years it will have = a > machine that solves discrete log, and if all of that happens, it will hav= e > the > chance to find the 20-year old password through an exhaustive dictionary > attack. > (We already have honest-but-curious attackers in cryptography; this one > will > qualify as wasteful-and-very-curious.) > > I believe it is a very reasonable expectation (see below) that long befor= e > we > build a quantum computer capable of breaking today's elliptic curves, PQ > OPRF > schemes will reach the performance we need for the fully-PQ operation of > OPAQUE. > Given the increasing applications for OPRFs we can expect to see such > schemes in > just a few years. I am not sure one can say anything like this for the > other > PAKE candidates where completely new PQ PAKE schemes may need to be > invented. > > References: > > [1] Kathrin H=C3=B6velmanns, Eike Kiltz, Sven Sch=C3=A4ge, Dominique Unru= h > Generic Authenticated Key Exchange in the Quantum Random Oracle Model > https://eprint.iacr.org/2018/928 > (They show how to build PQ AKE from PQ PKE in the ROM). > > [2] Martin R. Albrecht, Alex Davidson, Amit Deo, Nigel P. Smart > Round-optimal Verifiable Oblivious Pseudorandom Functions From Ideal > Lattices > https://eprint.iacr.org/2019/1271 > > The above paper builds a PQ OPRF from lattices. It is not efficient enoug= h > for > the OPAQUE purposes, particularly as it is optimized for cases where one > applies > the OPRF with the same OPRF key on multiple inputs which is not the OPAQU= E > case. > But it is very good progress. Also, it tackles the harder problem of > *verifiable* OPRF while OPAQUE does not need the verifiability property. > > [3] Jonathan Katz, Samuel Ranellucci, Mike Rosulek, Xiao Wang > Optimizing Authenticated Garbling for Faster Secure Two-Party Computation > https://eprint.iacr.org/2018/578.pdf > > The above paper, as many others in this area, shows how to do secure > two-party > computation and reports on performance when the computed function is AES. > More specifically, in this setting one party (call it a server) holds a A= ES > key K while a client has an input x. The client learns AES(K,x) and nothi= ng > else. The server learns nothing. This is exactly the OPRF setting. > Is the scheme in the paper PQ secure? It is if one uses AES for Yao's > garbling > and uses lattice-based oblivious transfer. Are we done then? > Not really, because, as above, this results in a not-very-efficient schem= e > (particularly in terms of communication). But again, it is significant > progress > towards finding a practical PQ OPRF. > > Note: In addition to performance issues, one will probably need to adapt > the > above constructions to the UC setting in which OPAQUE is analyzed (e.g., > the > user will need to apply a hash function on top of the AES(K,x) result). > These are important details but the point is to demonstrate that we have > some > good reasons to believe that an efficient enough PQ OPRF is expected to b= e > built > in the not-too-far future (probably much much sooner than the quantum > computer > that will break DH-OPRF), and that is ALL we need to have a fully-PQ OPAQ= UE --0000000000007ac25f059e3b2b98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks, Hugo!

=D0=BF=D0=BD, 10 =D1=84= =D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 19:22, Hugo Krawczyk <hugokraw@gmail.com>:
Dear Stanislav and the CFRG selection committee,

Below are answers to the questions you posed for OPAQUE.
Let me know if you need more information at this time.

As a reminder, our analysis paper is in
https://eprint.iacr.org/2018/163.pdf
At the end of the introduction you can find several notes explaining the revisions we did since the time we initially submitted OPAQUE to this
selection
process. Some of the important revisions were motivated by the excellent feedback from this committee (especially Bjorn and Julia). We are truly
grateful
for that. The protocol itself has not changed except for noting that the (full)
PFS requirement for the key exchange component (AKE) eliminates the option<= br> of a
2-message protocol (see my email to cfrg from 11/18/2019). This does not change
the analysis of OPAQUE performed by the TLS and IKE teams.

The current internet draft (revision 03) is in
https://datatracker.ietf.org/doc/draft-k= rawczyk-cfrg-opaque/
It is intended as a high level description of the protocol built in a
modular
way based on three components: OPRF, Authenticated Encryption, and AKE.
The draft is purposely light in implementation details. These details will<= br> emerge through CFRG input as well as via our work on implementation planned=
to
start very soon in collaboration with a group of IETF and TLS 1.3 experts.<= br> We expect to build on existing tools and specifications, particularly the OPRF
work in https://tools.ietf.org/html/draft-irtf-c= frg-voprf-02 and AKE
specifications borrowed from TLS 1.3. See also response to question (3)
below.

The only module currently lacking a standardized specification is the
key-committing authenticated encryption required for building the OPAQUE envelope. Several simple options are listed in the OPAQUE draft, one of
which
will be chosen for specification and implementation. There is also the
option
of minimizing the size of envelope for communication-constrained scenarios.=

=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=3D

Question 3 (to all 4 remaining PAKEs): Can the nominators/developers of the=
protocols please re-evaluate possible IPR conflicts between their candidate= s
protocols and own and foreign patents?

OPAQUE can use any AKE (with KCI and PFS security) and therefore is not
limited
to any particular AKE protocol. The current OPAQUE internet draft
illustrates
the protocol using HMQV and SIGMA as the AKE component. HMQV is presented as the most efficient instantiation and SIGMA as the basis for integration<= br> with TLS 1.3
and IKEv2. Since HMQV is encumbered by an IBM-owned patent, the
instantiation
with HMQV cannot be standardized, at least for the moment (it can change if=
IBM
agrees to donate the patent for royalty-free use within OPAQUE). The 3DH protocol (the basis of Signal) can serve as a drop-in replacement for HMQV<= br> as
the only difference between the protocols is in the formula for the
computation
of the session key (which involves one extra exponentiation in 3DH).

However, moving forward, OPAQUE specification and implementation will cente= r
around SIGMA as this is the way the protocol would be integrated with TLS 1.3
and IKEv2 (both of which build on SIGMA already). It is important to note that
any asymmetric PAKE requires a mechanism that will protect user account
information and a data channel protocol for transmitting data protected
under
the shared session key. It makes no sense to re-invent any of these
mechanisms
rather than using established and standardized protocols like TLS or
IKE/IPsec.
Furthermore, when run inside TLS 1.3 (similarly for IKEv2), the cost of
OPAQUE-SIGMA-ECDSA is virtually the same as with HMQV (just one extra
fixed-base exponentiation for server and client).

In comparison to Strong AuCPace, OPAQUE-SIGMA-ECDSA is more efficient in terms of exponentiations and number of messages. The latter is particularly=
advantageous for integration with TLS 1.3. An additional performance
advantage
of OPAQUE is that the DH exchange in TLS and IKE is re-used in OPAQUE while=
for AuCPace it represents an additional cost (one fixed and one variable exponentiation for client and server). The favorable performance cost of OPAQUE
when integrated with TLS, in terms of number of messages and
exponentiations,
holds also with respect to non-strong AuCPace.

The size of the OPAQUE envelope can be minimized in settings where server storage and/or communication are scarce resources.

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Question 5 (to all 4 remaining PAKEs): What can be said about "post-qu= antum
preparedness" of the PAKE?

I have already expressed my opinion that post-quantum-preparedness is a muc= h
more important property than "quantum annoyance" in this posting = from
10/27/2019:
https://mailarchive.ietf.org/arch/browse/cfrg/?q=3DQuantum%20annoyance= %20vs%20post-quantum%20preparedness

Thus, I will first refer to the really important question: Post-Quantum (PQ= )
preparedness.

OPAQUE seems to be the only candidate among all CFRG proposals that could b= e
implemented today with a full PQ design, albeit not a very efficient one. Indeed, one can take any PQ PKE submission to NIST's competition and generate
a PQ AKE with the properties of forward secrecy and KCI required by OPAQUE<= br> [1].
As for the OPRF, we already have candidate PQ instantiations of this
primitive
[2,3] though not efficient enough for current deployment.

However, note that even if the OPRF is not PQ but the AKE is (e.g., when TLS, or
other settings where OPAQUE is used, adopts a PQ AKE), data will remain
secure
even if the OPRF is fully broken in the future. This is similar to the
situation with digital signatures used in TLS 1.3.=C2=A0 Breaking them in t= he
future
has no bearing on data protected under keys authenticated with these
signatures.
One difference is that breaking the DH-OPRF in the future would enable a dictionary attack on the user's password as used in the past (say, 10-2= 0
years
earlier). However, once TLS moves to PQ AKE (before that all data will be vulnerable, with and without OPAQUE), this attack will be limited to active=
attackers. Namely, only attackers that actively impersonated a user in an OPAQUE session with the old OPRF may be able to attack the password in the<= br> future. In other words, to learn today's password in 10-20 years, an attacker
needs to impersonate the user now, hope that in 10-20 years it will have a<= br> machine that solves discrete log, and if all of that happens, it will have<= br> the
chance to find the 20-year old password through an exhaustive dictionary attack.
(We already have honest-but-curious attackers in cryptography; this one wil= l
qualify as wasteful-and-very-curious.)

I believe it is a very reasonable expectation (see below) that long before<= br> we
build a quantum computer capable of breaking today's elliptic curves, P= Q
OPRF
schemes will reach the performance we need for the fully-PQ operation of OPAQUE.
Given the increasing applications for OPRFs we can expect to see such
schemes in
just a few years. I am not sure one can say anything like this for the othe= r
PAKE candidates where completely new PQ PAKE schemes may need to be
invented.

References:

[1] Kathrin H=C3=B6velmanns, Eike Kiltz, Sven Sch=C3=A4ge, Dominique Unruh<= br> Generic Authenticated Key Exchange in the Quantum Random Oracle Model
https://eprint.iacr.org/2018/928
(They show how to build PQ AKE from PQ PKE in the ROM).

[2] Martin R. Albrecht, Alex Davidson, Amit Deo, Nigel P. Smart
Round-optimal Verifiable Oblivious Pseudorandom Functions From Ideal
Lattices
https://eprint.iacr.org/2019/1271

The above paper builds a PQ OPRF from lattices. It is not efficient enough<= br> for
the OPAQUE purposes, particularly as it is optimized for cases where one applies
the OPRF with the same OPRF key on multiple inputs which is not the OPAQUE<= br> case.
But it is very good progress. Also, it tackles the harder problem of
*verifiable* OPRF while OPAQUE does not need the verifiability property.
[3] Jonathan Katz, Samuel Ranellucci, Mike Rosulek, Xiao Wang
Optimizing Authenticated Garbling for Faster Secure Two-Party Computation https://eprint.iacr.org/2018/578.pdf

The above paper, as many others in this area, shows how to do secure
two-party
computation and reports on performance when the computed function is AES. More specifically, in this setting one party (call it a server) holds a AES=
key K while a client has an input x. The client learns AES(K,x) and nothing=
else. The server learns nothing. This is exactly the OPRF setting.
Is the scheme in the paper PQ secure? It is if one uses AES for Yao's garbling
and uses lattice-based oblivious transfer. Are we done then?
Not really, because, as above, this results in a not-very-efficient scheme<= br> (particularly in terms of communication). But again, it is significant
progress
towards finding a practical PQ OPRF.

Note: In addition to performance issues, one will probably need to adapt th= e
above constructions to the UC setting in which OPAQUE is analyzed (e.g., th= e
user will need to apply a hash function on top of the AES(K,x) result).
These are important details but the point is to demonstrate that we have some
good reasons to believe that an efficient enough PQ OPRF is expected to be<= br> built
in the not-too-far future (probably much much sooner than the quantum
computer
that will break DH-OPRF), and that is ALL we need to have a fully-PQ OPAQUE=
--0000000000007ac25f059e3b2b98-- From nobody Mon Feb 10 22:41:18 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0331200E0 for ; Mon, 10 Feb 2020 22:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 fuQb8pgesktO for ; Mon, 10 Feb 2020 22:41:13 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 757F812008C for ; Mon, 10 Feb 2020 22:41:13 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id b15so6182088lfc.4 for ; Mon, 10 Feb 2020 22:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2KXtjSSe70+wdEQ9wTvCNEdYAYyQjYG1n8Bh8ShrX7E=; b=CWEiUlDfsJ9hlrhnCv9yxXD3FfGNB8JZXDKri20NQpIqcf4+ESytP/FEw5tahlkDiT dRqYHyuLk80lSi1YI19z6mfxxAAZuv9W0M9JTkWBUIQTHW6yMLXnCPEsaivEr/rfYkFS 3W1AAtiPJdVPEVE0sK2N/WFJ9AVWR431h7WeZUeDZ6i8GKroIIhnTl+dP/GfQz9hi+2w cQ5LAONSkOVbt1zgLNrWBai1s2gaYZGZU2DdnRPbKksbdEZqfNN4NRq52GBmx5RT5QR2 wlOjAHgr6Iah703QRp4Od2kJXQCM2FsSoBG5W+mHbAXbVC3twgHps0thJLNx8qKzkAak cUEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2KXtjSSe70+wdEQ9wTvCNEdYAYyQjYG1n8Bh8ShrX7E=; b=RaLxsJ1U8zM82LIiLPFQ8XN1+l5KrRht+XePXG6oqtIJFk4Z7lhhLCYEnXVm6h6RYQ Cvr+P2h+gdM1L7MJiAbXZwE8zBIWd+Mq97KvOuZ925hN9kq8PQ7uf8OwzYjy3K0EiyTz hXVx/BpQL0B3Z0qAaK9rKun0qZW3foWhGxQFBPblgYp01/JuLStnS/iUq1eUhegsTMzr mkewfA/eAPLUqjobc0mviTKg3YXoqsAOVoiVsq9wGUjmn+oebYSaRyCE3wKfJujo56bC G/8iF9V7m9MGqtQB2svJ0eiTeZ0SGzPE9XpwyhmgaB562CAhMx3zoGrjpGpkpUqqxZ38 STaQ== X-Gm-Message-State: APjAAAUGDavw++ns6YgM62t52aun6TCrFfM8v9jG9zesm3kLJ2xJyqzD BkeuW5aRzx62ROiVQwkelr4Izzu2aukFxtUBgJhcSZbBFiI= X-Google-Smtp-Source: APXvYqwhgvnmGNpqx+m8f6e7GSD57tMEKuaDtSyJpQp2F4LofC+sTO4NqqfGogdqI2lKojyjkCd01hwgJb0BOB0N6/s= X-Received: by 2002:a19:6449:: with SMTP id b9mr2786745lfj.5.1581403271349; Mon, 10 Feb 2020 22:41:11 -0800 (PST) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Tue, 11 Feb 2020 09:42:18 +0300 Message-ID: To: crypto-panel@irtf.org, Russ Housley , Yaron Sheffer , Bjoern Tackmann Cc: cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c4793059e4724f5" Archived-At: Subject: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 06:41:17 -0000 --0000000000003c4793059e4724f5 Content-Type: text/plain; charset="UTF-8" Dear Crypto Review Panel members, Due to the plan of the second round of the PAKE selection process, we're approaching Stage 4 of Round 2: *Stage 4: February, 12th - March, 10th* *Crypto Review Panel members prepare new overall reviews (for all 4 remaining PAKEs) taking into account both the reviews obtained on Round 1 and new information obtained during Round 2.* Let me remind you, that we have 4 candidates passed to Round 2: CPace, SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). The authors of the protocols have provided their answers to the additional questions that were asked after IETF 106 meeting (see https://github.com/cfrg/pake-selection/blob/master/README.md#questions-for-round-2 ). Their answers have been provided in the mailing list (see links at https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-round-2 ). The previous overall reviews by Bjoern Tackmann, myself, Russ Housley and Yaron Sheffer are available at https://github.com/cfrg/pake-selection/blob/master/README.md#overall-reviews-by-crypto-review-panel . All other reviews are available here: https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-reviews So now we need reviews (each review should consider all 4 protocols - otherwise it will be more difficult to compare) for the remaining candidates. The reviews should be done before *March, 10th*. First of all, it will be very important if *Bjoern, Russ *and *Yaron* could do their new (or, better to say, updated) reviews, since they have done them at the previous round. It will be great if Scott could participate, since he provided very important reviews on certain issues. Also since now we have *Chloe, Julia, Karthikeyan, Thomas, Jean-Philippe *and *Jon *on board. In this process we need as many good reviews as possible, so we ask all of you to consider your participation. Please let us know, whether you are ready to do this, before *February, 13th*. Regards, Stanislav (on behalf of the CFRG chairs) --0000000000003c4793059e4724f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Crypto Review Panel members,

Due t= o the plan of the second round of the PAKE selection process, we're app= roaching Stage 4 of Round 2:

Stage=C2=A04: February= , 12th - March, 10th
Crypto Review Panel members prepare n= ew overall reviews (for all=C2=A04=C2=A0rem= aining PAKEs) taking into account both the reviews obtained on=C2=A0Round=C2=A01 and new information obtained during= =C2=A0Round=C2=A02= .

Let me remind you, that = we have 4 candidates passed to Round 2: CPace, SPAKE2 (balanced) and AuCPac= e, OPAQUE (augmented).

The authors of the protocol= s have provided their answers to the additional questions that were asked a= fter IETF 106 meeting (see=C2=A0https://github.com/cfrg= /pake-selection/blob/master/README.md#questions-for-round-2).

Their answers have been provided in the mailing list (see l= inks at=C2=A0https://github.com/cfrg/pake-selection/blob/m= aster/README.md#answers-on-round-2).

The previ= ous overall reviews by Bjoern Tackmann, myself, Russ Housley and Yaron Shef= fer are available at=C2=A0https://gith= ub.com/cfrg/pake-selection/blob/master/README.md#overall-reviews-by-crypto-= review-panel . All other reviews are available here:=C2=A0https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of= -reviews

So now we need reviews (each review s= hould consider all 4 protocols - otherwise it will be more difficult=C2=A0t= o compare) for the remaining candidates. The reviews should be done before March, 10th.=C2=A0

First of all, it will be very important if Bjo= ern, Russ and Yaron could do their new (or, better to say, updat= ed) reviews, since they have done them at the previous round. It will be gr= eat if Scott could participate, since he provided very important reviews on= certain issues.
Also since now we have Chloe, Julia,=C2=A0Kar= thikeyan, Thomas,=C2=A0Jean-Philippe and Jon on board.
In this process we need as many good reviews as possible, so we ask all of= you to consider your participation.

Pl= ease let us know, whether you are ready to do this, before February, 13t= h.

Regards,
Stanislav (on behalf of = the CFRG chairs)


--0000000000003c4793059e4724f5-- From nobody Tue Feb 11 09:47:48 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C81209A6 for ; Tue, 11 Feb 2020 09:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 vaXY92J0h4s9 for ; Tue, 11 Feb 2020 09:47:45 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1436B120987 for ; Tue, 11 Feb 2020 09:47:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 88A1D300B42 for ; Tue, 11 Feb 2020 12:21:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UlgCwJ_Ko43Y for ; Tue, 11 Feb 2020 12:21:00 -0500 (EST) Received: from [192.168.0.166] (wsip-72-194-193-110.dc.dc.cox.net [72.194.193.110]) by mail.smeinc.net (Postfix) with ESMTPSA id 9413F3005D5; Tue, 11 Feb 2020 12:21:00 -0500 (EST) From: Russ Housley Message-Id: <7E818D37-B68A-4154-87AC-B2E044371BC6@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8C2A981-3E18-4A59-8B1C-84AFE2E49BBD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Feb 2020 12:47:40 -0500 In-Reply-To: Cc: crypto-panel@irtf.org, Yaron Sheffer , Bjoern Tackmann , cfrg-chairs@ietf.org To: "Stanislav V. Smyshlyaev" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 17:47:47 -0000 --Apple-Mail=_E8C2A981-3E18-4A59-8B1C-84AFE2E49BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, I am prepared to update my review based on the updates. Russ > On Feb 11, 2020, at 1:42 AM, Stanislav V. Smyshlyaev = wrote: >=20 > Dear Crypto Review Panel members, >=20 > Due to the plan of the second round of the PAKE selection process, = we're approaching Stage 4 of Round 2: >=20 > Stage 4: February, 12th - March, 10th > Crypto Review Panel members prepare new overall reviews (for all 4 = remaining PAKEs) taking into account both the reviews obtained on Round = 1 and new information obtained during Round 2. >=20 > Let me remind you, that we have 4 candidates passed to Round 2: CPace, = SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). >=20 > The authors of the protocols have provided their answers to the = additional questions that were asked after IETF 106 meeting (see = https://github.com/cfrg/pake-selection/blob/master/README.md#questions-for= -round-2 = ). >=20 > Their answers have been provided in the mailing list (see links at = https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-ro= und-2 = ). >=20 > The previous overall reviews by Bjoern Tackmann, myself, Russ Housley = and Yaron Sheffer are available at = https://github.com/cfrg/pake-selection/blob/master/README.md#overall-revie= ws-by-crypto-review-panel = . All other reviews are available here: = https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-re= views = >=20 > So now we need reviews (each review should consider all 4 protocols - = otherwise it will be more difficult to compare) for the remaining = candidates. The reviews should be done before March, 10th.=20 >=20 > First of all, it will be very important if Bjoern, Russ and Yaron = could do their new (or, better to say, updated) reviews, since they have = done them at the previous round. It will be great if Scott could = participate, since he provided very important reviews on certain issues. > Also since now we have Chloe, Julia, Karthikeyan, Thomas, = Jean-Philippe and Jon on board. > In this process we need as many good reviews as possible, so we ask = all of you to consider your participation. >=20 > Please let us know, whether you are ready to do this, before February, = 13th. >=20 > Regards, > Stanislav (on behalf of the CFRG chairs) >=20 >=20 --Apple-Mail=_E8C2A981-3E18-4A59-8B1C-84AFE2E49BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, = I am prepared to update my review based on the updates.
Russ

On Feb = 11, 2020, at 1:42 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com> = wrote:

Dear Crypto Review Panel members,

Due to the plan of the = second round of the PAKE selection process, we're approaching Stage 4 of = Round 2:

Stage 4: February, 12th - March, 10th
Crypto Review Panel members prepare new overall = reviews (for all 4 remaining = PAKEs) taking into account both the reviews obtained on Round 1 and new information obtained = during Round 2.

Let me remind you, = that we have 4 candidates passed to Round 2: CPace, SPAKE2 (balanced) = and AuCPace, OPAQUE (augmented).

The authors of the protocols have = provided their answers to the additional questions that were asked after = IETF 106 meeting (see https://github.com/cfrg/pake-selection/blob/master/README.md#qu= estions-for-round-2).

Their answers have been provided in the mailing list (see = links at https://github.com/cfrg/pake-selection/blob/master/README.md#an= swers-on-round-2).

The previous overall reviews by Bjoern Tackmann, myself, Russ = Housley and Yaron Sheffer are available at https://github.com/cfrg/pake-selection/blob/master/README.md#ov= erall-reviews-by-crypto-review-panel . All other reviews are = available here: https://github.com/cfrg/pake-selection/blob/master/README.md#su= mmary-of-reviews

So now we need reviews (each review should consider all 4 = protocols - otherwise it will be more difficult to compare) for the = remaining candidates. The reviews should be done before March, 10th. 

First of all, = it will be very important if Bjoern, Russ and Yaron could do their new (or, better to say, updated) = reviews, since they have done them at the previous round. It will be = great if Scott could participate, since he provided very important = reviews on certain issues.
Also since now we have = Chloe, Julia, Karthikeyan, Thomas, Jean-Philippe = and Jon on board.
In this = process we need as many good reviews as possible, so we ask all of you = to consider your participation.

Please let us = know, whether you are ready to do this, before February, = 13th.

Regards,
Stanislav (on behalf of the = CFRG chairs)


= --Apple-Mail=_E8C2A981-3E18-4A59-8B1C-84AFE2E49BBD-- From nobody Tue Feb 11 09:49:45 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58C12013D for ; Tue, 11 Feb 2020 09:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 lQ0aWZkYoyvI for ; Tue, 11 Feb 2020 09:49:40 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 7D30A120926 for ; Tue, 11 Feb 2020 09:49:40 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id f25so12560804ljg.12 for ; Tue, 11 Feb 2020 09:49:40 -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=7C/ZChC7Pk69nIAdQHczRzIf10yqr58FWt04L7QXi/c=; b=nIk0QRrFggJ6vDRJQntIFBvchFLLGDR4AjWK4pEYY7FCR34fYfguhlMA5X+fL2yY84 LdBgN1OC6+B2TVxK3MH6V0+ERfdmSttDCnT2lskfMxGR1tXUBCW8JFfjJ44svpxPcXg3 wsSY0+jgWIVBmz3n7DWR+OyCcfQGsYUHPToPg0UJDbOqc9jAVBRRLUU4NC1S1yigb8jv +mm3dM4+vG7QM2/kUJoOmQwnpun7rg9x1Z5Qtdg27GXybpJWSm+4RB+MKJu+VKB0iapr PQPvtrOHqsucmHVdXXWopY93DQgPYta2oxapVudJxQjCvy2emzvOjv9rDN0M/SMQcHed Oe8w== 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=7C/ZChC7Pk69nIAdQHczRzIf10yqr58FWt04L7QXi/c=; b=n6tSEiBWl3lGyAiHrlgQR4KuWEHd6iyVAuXBih2fjQKoWMVyg4By3toFZ2Q9mOxfKD M9OugyEVDkyl7oE54I3cJQzg1ZJY6NRWToyYL/mGvTWRoWuvKVxkBK11BSJAf+r1BT3Z skyLhkKEq6WXzoqGrAdMDwPT5zBHqHastISepctuPGXrfAAUuNu0ujy3iQfwix5QGkwM bfBMtKwIrg+eVK7FKbFn8onfZC9hPnjmoq09F9IPv6WJWk6ESRaNgv7BkPhNQLeyuNiP 4qfd2qzd3zAlcF51eoQ48cDfceU+boGVvT5OmGQ23KmRJwpsfuNcGvdtz5HopX4um90j 9YvQ== X-Gm-Message-State: APjAAAW7GRb9VikheV0cNBERjbXLn6yUdQeWgUY7WvYSk3Dxjbb0B6dT 2Z96TEiHMXRdrL8BCZ/mG0TMJsnrDyPoOFjGg+Y= X-Google-Smtp-Source: APXvYqwUWJDIBkygYofUISb8KlAYAlS0UjUsTaj6oTB6iJzeUgA2ym9SoVvFqtUJrRj0nE56xyVseY3OEydd0eQ9P0U= X-Received: by 2002:a2e:8758:: with SMTP id q24mr5044248ljj.157.1581443378641; Tue, 11 Feb 2020 09:49:38 -0800 (PST) MIME-Version: 1.0 References: <7E818D37-B68A-4154-87AC-B2E044371BC6@vigilsec.com> In-Reply-To: <7E818D37-B68A-4154-87AC-B2E044371BC6@vigilsec.com> From: "Stanislav V. Smyshlyaev" Date: Tue, 11 Feb 2020 20:49:27 +0300 Message-ID: To: Russ Housley Cc: Bjoern Tackmann , Yaron Sheffer , cfrg-chairs@ietf.org, crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="000000000000d0fde6059e507a6b" Archived-At: Subject: Re: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 17:49:43 -0000 --000000000000d0fde6059e507a6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great, many thanks, Russ! Regards, Stanislav =D0=B2=D1=82, 11 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 20:47, Russ = Housley : > Yes, I am prepared to update my review based on the updates. > > Russ > > On Feb 11, 2020, at 1:42 AM, Stanislav V. Smyshlyaev > wrote: > > Dear Crypto Review Panel members, > > Due to the plan of the second round of the PAKE selection process, we're > approaching Stage 4 of Round 2: > > *Stage 4: February, 12th - March, 10th* > *Crypto Review Panel members prepare new overall reviews (for > all 4 remaining PAKEs) taking into account both the reviews obtained > on Round 1 and new information obtained during Round 2.* > > Let me remind you, that we have 4 candidates passed to Round 2: CPace, > SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). > > The authors of the protocols have provided their answers to the additiona= l > questions that were asked after IETF 106 meeting (see > https://github.com/cfrg/pake-selection/blob/master/README.md#questions-fo= r-round-2 > ). > > Their answers have been provided in the mailing list (see links at > https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-r= ound-2 > ). > > The previous overall reviews by Bjoern Tackmann, myself, Russ Housley and > Yaron Sheffer are available at > https://github.com/cfrg/pake-selection/blob/master/README.md#overall-revi= ews-by-crypto-review-panel > . All other reviews are available here: > https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-r= eviews > > So now we need reviews (each review should consider all 4 protocols - > otherwise it will be more difficult to compare) for the remaining > candidates. The reviews should be done before *March, 10th*. > > First of all, it will be very important if *Bjoern, Russ *and *Yaron* > could do their new (or, better to say, updated) reviews, since they have > done them at the previous round. It will be great if Scott could > participate, since he provided very important reviews on certain issues. > Also since now we have *Chloe, Julia, Karthikeyan, Thomas, Jean-Philippe = *and > *Jon *on board. > In this process we need as many good reviews as possible, so we ask all o= f > you to consider your participation. > > Please let us know, whether you are ready to do this, before *February, > 13th*. > > Regards, > Stanislav (on behalf of the CFRG chairs) > > > > --000000000000d0fde6059e507a6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, many thanks, Russ!

Regards,
Stanislav

=D0=B2=D1=82, 11 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 20:47, Rus= s Housley <housley@vigilsec.com<= /a>>:
Yes, I am prepared to update my revi= ew based on the updates.

Russ


Dear Crypto Review Panel members= ,

Due to the plan of the second round of the PAKE select= ion process, we're approaching Stage 4 of Round 2:

=
Stage=C2=A04: February, 12th - March= , 10th
Crypto Review Panel members prepare new overall rev= iews (for all=C2=A04=C2=A0remaining PAKEs) taking into account= both the reviews obtained on=C2=A0Round=C2=A01 and new inform= ation obtained during=C2=A0Round=C2=A02.

Let me remind you, that we have 4 candida= tes passed to Round 2: CPace, SPAKE2 (balanced) and AuCPace, OPAQUE (augmen= ted).

The authors of the protocols have provided t= heir answers to the additional questions that were asked after IETF 106 mee= ting (see=C2=A0https://github.com/cfr= g/pake-selection/blob/master/README.md#questions-for-round-2).

Their answers have been provided in the mailing list (see = links at=C2=A0https://github.com/cfrg/pa= ke-selection/blob/master/README.md#answers-on-round-2).

<= /div>
The previous overall reviews by Bjoern Tackmann, myself, Russ Hou= sley and Yaron Sheffer are available at=C2=A0https://github.com/cfrg/pake-selection/blob/master= /README.md#overall-reviews-by-crypto-review-panel . All other reviews a= re available here:=C2=A0https://github.c= om/cfrg/pake-selection/blob/master/README.md#summary-of-reviews

So now we need reviews (each review should consider all 4= protocols - otherwise it will be more difficult=C2=A0to compare) for the r= emaining candidates. The reviews should be done before March, 10th.=C2=A0

First of all, it will be very important if Bjo= ern, Russ and Yaron could do their new (or, better to say, updat= ed) reviews, since they have done them at the previous round. It will be gr= eat if Scott could participate, since he provided very important reviews on= certain issues.
Also since now we have Chloe, Julia,=C2=A0Kar= thikeyan, Thomas,=C2=A0Jean-Philippe and Jon on board.
In this process we need as many good reviews as possible, so we ask all of= you to consider your participation.

Pl= ease let us know, whether you are ready to do this, before February, 13t= h.

Regards,
Stanislav (on behalf of = the CFRG chairs)



--000000000000d0fde6059e507a6b-- From nobody Wed Feb 12 12:11:21 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E122120817 for ; Wed, 12 Feb 2020 12:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org 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 ExOv5KFOyscu for ; Wed, 12 Feb 2020 12:11:16 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 716BF120074 for ; Wed, 12 Feb 2020 12:11:16 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id g1so3746552wmh.4 for ; Wed, 12 Feb 2020 12:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mB41H02k3BT4oxebe15BIQOc4K/ek6P2A4JybPF3RiU=; b=Pw+WW0a7dhwC9Ns2//P9NtLka7jE4kIG8v15lrb9ibDoLZJdBS8HNrvcqqAfrZE8Zj q3JemWj1gjnMIxURV1S2HXGiHswkTUtwpH3L7fH7o2W6sRvCoCesMfSdqz1DItgLLG+u L5JvGblSIXopQB8YfpoYBVy2neQsdZaw/wTjQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mB41H02k3BT4oxebe15BIQOc4K/ek6P2A4JybPF3RiU=; b=lKIPZ5N206A14yNotpH3qVHaq0wpLLd80f99Kb1WJ7TNiNCK54YPwMhX4b/GuCIpkf CB9f4hxymiDktj1qoab4NnSQOod+jscelZ4ZIRGOnNBttgem8mJN8x7BTaUyn7VY/1Cq +Wi3wonLE9iKeGPoVCFOJCsECPJxC+GBwRodF7CyNwHvGBgiUwqljVTTcp/mVlHM+onm itHkN3X8iHzW8klyMCtdTcXP1mtQJQO3d3ZtOxOJZnhe7ZoKBEMHYyg3JSoqHvgp8AwU MdX6+ejaf22Pl+Kw54Ia3imLmGRqQayuC64wENU7y0QBUTXv4/rUmXx0cPer+V5aGF/R mznA== X-Gm-Message-State: APjAAAV+orbbdCpOmQglv2k3S0pLq+hjSejbij6KNZczvbLWdMKRjg+l bmZj3J/kLI/rhtIr4KytGyHkdw== X-Google-Smtp-Source: APXvYqyFtpHUljopADuMhuh98tfsS8n0UHkOGFRrC0pJ3z/rY+qxyKy4vhcrHJYPQVOVAxGtxqzIRA== X-Received: by 2002:a1c:1b93:: with SMTP id b141mr847705wmb.114.1581538274878; Wed, 12 Feb 2020 12:11:14 -0800 (PST) Received: from ?IPv6:2001:8e0:2002:8600:b501:1636:161:ae3a? ([2001:8e0:2002:8600:b501:1636:161:ae3a]) by smtp.gmail.com with ESMTPSA id q14sm1869361wrj.81.2020.02.12.12.11.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Feb 2020 12:11:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Bjoern Tackmann In-Reply-To: Date: Wed, 12 Feb 2020 21:11:12 +0100 Cc: crypto-panel@irtf.org, Russ Housley , Yaron Sheffer , cfrg-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Stanislav V. Smyshlyaev" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 20:11:19 -0000 Dear Stanislav, sure, I=E2=80=99ll update my review, I=E2=80=99ll also adapt it to some = insights I got through further discussions with Hugo and Stanislaw = Jarecki. I=E2=80=99ll most likely get around to it only in March, = though. Cheers, Bj=C3=B6rn > On Feb 11, 2020, at 7:42 AM, Stanislav V. Smyshlyaev = wrote: >=20 > Dear Crypto Review Panel members, >=20 > Due to the plan of the second round of the PAKE selection process, = we're approaching Stage 4 of Round 2: >=20 > Stage 4: February, 12th - March, 10th > Crypto Review Panel members prepare new overall reviews (for all 4 = remaining PAKEs) taking into account both the reviews obtained on Round = 1 and new information obtained during Round 2. >=20 > Let me remind you, that we have 4 candidates passed to Round 2: CPace, = SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). >=20 > The authors of the protocols have provided their answers to the = additional questions that were asked after IETF 106 meeting (see = https://github.com/cfrg/pake-selection/blob/master/README.md#questions-for= -round-2). >=20 > Their answers have been provided in the mailing list (see links at = https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-ro= und-2). >=20 > The previous overall reviews by Bjoern Tackmann, myself, Russ Housley = and Yaron Sheffer are available at = https://github.com/cfrg/pake-selection/blob/master/README.md#overall-revie= ws-by-crypto-review-panel . All other reviews are available here: = https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-re= views >=20 > So now we need reviews (each review should consider all 4 protocols - = otherwise it will be more difficult to compare) for the remaining = candidates. The reviews should be done before March, 10th.=20 >=20 > First of all, it will be very important if Bjoern, Russ and Yaron = could do their new (or, better to say, updated) reviews, since they have = done them at the previous round. It will be great if Scott could = participate, since he provided very important reviews on certain issues. > Also since now we have Chloe, Julia, Karthikeyan, Thomas, = Jean-Philippe and Jon on board. > In this process we need as many good reviews as possible, so we ask = all of you to consider your participation. >=20 > Please let us know, whether you are ready to do this, before February, = 13th. >=20 > Regards, > Stanislav (on behalf of the CFRG chairs) >=20 >=20 From nobody Thu Feb 13 01:00:43 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EAE1200BA for ; Thu, 13 Feb 2020 01:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 jcZrzmRtxv-3 for ; Thu, 13 Feb 2020 01:00:39 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 17B411200B6 for ; Thu, 13 Feb 2020 01:00:39 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id x14so5624674ljd.13 for ; Thu, 13 Feb 2020 01:00:38 -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=ox14nGJblUlol/KpBikjtT+25PmcBRrPW2kPr0ZVIZM=; b=EK8dh36maTGin35GycsgLJD9qmZ743Gn2MC4VDyfOO2mIowu2vyA7S6Nt2jdGVYamx EuZClEdS9vh3CH8Dqu1pC2sgJIeCDtkjob0haO4llE27R3swOrR7fbUEeSWPZRz2xi0e 2KiwXKE4lxBv7mHpUBuDYYZpo9X1EiQ2X0ZNiAowT1LkyvskqrHoRpQ/uREP+IGF6Sgv aLYWPx43dp3fS+4KO6c2pjUgenbQ+BAWmz5mBOxCKAXy7c0SM1+Lyd0VPkUEreDNdH1T CTP6kx6eEy2MGwqWfoiDwMpXQe7HZkHA+Tee5c2MUrf+KAGSEnbVLbzJZoRIVsumXea2 Ad4A== 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=ox14nGJblUlol/KpBikjtT+25PmcBRrPW2kPr0ZVIZM=; b=ZlpTW4l9kENMVEsliy0OV8oSk0ZiaPIZfKF1kUYj9X7Y6sWqs90WrjBKGihlNWwZkr 3dVm4ACydxUai7VN8skC1rKUqRyn+TMaj8KggQhoJOQ3ze3RLJVRO/lcTcijOZZapies 5Grd0LOCxt1D9J2AA4RpEoEEVuum2NWRNYxM15aLW0NW2FTyILEN5j5DG/P2zanZ8sfx aiXCfLqiWGM0EfITTEnP4INRIqZi61qq2WBIHKoJf7CDGQH64NqMOjjOi/Zy/FJtP4B8 lcCNeuTflqJqkZ97gPwed4u6oIEMamQAiMd5E7pLkDxwsBBixHkHAf/KOEaBDF5YBGZg N9TQ== X-Gm-Message-State: APjAAAXN0KeAHTVhHxRnPCVzgtO7iwqHR7hEwrD/bkJ6r1edjg3jQzy7 O9UD+Uvw/MDpDuKBsBj1FpciiE+dRV9EQmLW/c4= X-Google-Smtp-Source: APXvYqzNyFg63Udkf/qXZrxWFp8yNDYD+eg5g2Sf5FTfSGS/J6V8KAR6BgO797/CfUrBFcEYu+zckwfSuHiyGm4ja+c= X-Received: by 2002:a2e:8758:: with SMTP id q24mr10671025ljj.157.1581584437251; Thu, 13 Feb 2020 01:00:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Thu, 13 Feb 2020 12:00:51 +0300 Message-ID: To: Bjoern Tackmann Cc: crypto-panel@irtf.org, Russ Housley , Yaron Sheffer , cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009090d1059e715263" Archived-At: Subject: Re: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 09:00:42 -0000 --0000000000009090d1059e715263 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Bj=C3=B6rn, Many thanks for your reply and for your confirmation! >> I=E2=80=99ll most likely get around to it only in March, though. We need the reviews before March, 10th =E2=80=93 is it OK for you? Regards, Stanislav On Wed, 12 Feb 2020 at 23:11, Bjoern Tackmann wrote: > Dear Stanislav, > > sure, I=E2=80=99ll update my review, I=E2=80=99ll also adapt it to some i= nsights I got > through further discussions with Hugo and Stanislaw Jarecki. I=E2=80=99ll= most > likely get around to it only in March, though. > > Cheers, > Bj=C3=B6rn > > > > On Feb 11, 2020, at 7:42 AM, Stanislav V. Smyshlyaev > wrote: > > > > Dear Crypto Review Panel members, > > > > Due to the plan of the second round of the PAKE selection process, we'r= e > approaching Stage 4 of Round 2: > > > > Stage 4: February, 12th - March, 10th > > Crypto Review Panel members prepare new overall reviews (for all 4 > remaining PAKEs) taking into account both the reviews obtained on Round 1 > and new information obtained during Round 2. > > > > Let me remind you, that we have 4 candidates passed to Round 2: CPace, > SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). > > > > The authors of the protocols have provided their answers to the > additional questions that were asked after IETF 106 meeting (see > https://github.com/cfrg/pake-selection/blob/master/README.md#questions-fo= r-round-2 > ). > > > > Their answers have been provided in the mailing list (see links at > https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-r= ound-2 > ). > > > > The previous overall reviews by Bjoern Tackmann, myself, Russ Housley > and Yaron Sheffer are available at > https://github.com/cfrg/pake-selection/blob/master/README.md#overall-revi= ews-by-crypto-review-panel > . All other reviews are available here: > https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-r= eviews > > > > So now we need reviews (each review should consider all 4 protocols - > otherwise it will be more difficult to compare) for the remaining > candidates. The reviews should be done before March, 10th. > > > > First of all, it will be very important if Bjoern, Russ and Yaron could > do their new (or, better to say, updated) reviews, since they have done > them at the previous round. It will be great if Scott could participate, > since he provided very important reviews on certain issues. > > Also since now we have Chloe, Julia, Karthikeyan, Thomas, Jean-Philippe > and Jon on board. > > In this process we need as many good reviews as possible, so we ask all > of you to consider your participation. > > > > Please let us know, whether you are ready to do this, before February, > 13th. > > > > Regards, > > Stanislav (on behalf of the CFRG chairs) > > > > > > --0000000000009090d1059e715263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Bj=C3=B6rn,

Many thanks for your r= eply and for your confirmation!

>> I=E2=80= =99ll most likely get around to it only in March, though.
We need= the reviews before March, 10th =E2=80=93 is it OK for you?

<= /div>
Regards,
Stanislav

On Wed, 12 Feb 2020 at 23:11, B= joern Tackmann <bjoern.tackm= ann@ieee.org> wrote:
Dear Stanislav,

sure, I=E2=80=99ll update my review, I=E2=80=99ll also adapt it to some ins= ights I got through further discussions with Hugo and Stanislaw Jarecki. I= =E2=80=99ll most likely get around to it only in March, though.

Cheers,
Bj=C3=B6rn


> On Feb 11, 2020, at 7:42 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:<= br> >
> Dear Crypto Review Panel members,
>
> Due to the plan of the second round of the PAKE selection process, we&= #39;re approaching Stage 4 of Round 2:
>
> Stage 4: February, 12th - March, 10th
> Crypto Review Panel members prepare new overall reviews (for all 4 rem= aining PAKEs) taking into account both the reviews obtained on Round 1 and = new information obtained during Round 2.
>
> Let me remind you, that we have 4 candidates passed to Round 2: CPace,= SPAKE2 (balanced) and AuCPace, OPAQUE (augmented).
>
> The authors of the protocols have provided their answers to the additi= onal questions that were asked after IETF 106 meeting (see https://github.com/cfrg/pake-selec= tion/blob/master/README.md#questions-for-round-2).
>
> Their answers have been provided in the mailing list (see links at https://github.com/cfrg/= pake-selection/blob/master/README.md#answers-on-round-2).
>
> The previous overall reviews by Bjoern Tackmann, myself, Russ Housley = and Yaron Sheffer are available at https://github.com/cfrg/pake-selection/bl= ob/master/README.md#overall-reviews-by-crypto-review-panel . All other = reviews are available here: https://github.com/cfrg/pake-selection/blob/master/README.md#summary= -of-reviews
>
> So now we need reviews (each review should consider all 4 protocols - = otherwise it will be more difficult to compare) for the remaining candidate= s. The reviews should be done before March, 10th.
>
> First of all, it will be very important if Bjoern, Russ and Yaron coul= d do their new (or, better to say, updated) reviews, since they have done t= hem at the previous round. It will be great if Scott could participate, sin= ce he provided very important reviews on certain issues.
> Also since now we have Chloe, Julia, Karthikeyan, Thomas, Jean-Philipp= e and Jon on board.
> In this process we need as many good reviews as possible, so we ask al= l of you to consider your participation.
>
> Please let us know, whether you are ready to do this, before February,= 13th.
>
> Regards,
> Stanislav (on behalf of the CFRG chairs)
>
>

--0000000000009090d1059e715263-- From nobody Sat Feb 15 07:28:31 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3F01200A4 for ; Sat, 15 Feb 2020 07:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TQlqLoU18GQ6 for ; Sat, 15 Feb 2020 07:28:26 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 E28051200B1 for ; Sat, 15 Feb 2020 07:28:25 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id a6so14032452wme.2 for ; Sat, 15 Feb 2020 07:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=xIW4q8P01V3KhHVtYBnN0WJnqWjLx/jU/EkNVEbDUjA=; b=WxRkcZOo1GKWbINjk0Y3K/XcOFcjcjxixUJR5kGH7IvctVeyHnH+QOFhj5CEKnF59B oQ6D2vYo/jZn4miF0mZGc26bmFxW1OTykjUtraqv1lpPrAzgAuoaMVgZxl0M/Nqtl+ri m1ia6mUhYZTDLjhh8jl3o+4iWBrwudZZZVl1fV2HDx+VHqYXM4pw9uVsfvhdDgRsSlLK nQcqZ2UOe9/o931cbD9RwzFUTEj3NdI9XUSTxjal56Un66AXKbeoMIvKPSwb06E1ikPc qfHE93xOGQH6tOpVoTWj9fUjkb/yVfoJL+hSeNKyxIrlnH+UcI7i3NljtoCFdkIDbo3f mTeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=xIW4q8P01V3KhHVtYBnN0WJnqWjLx/jU/EkNVEbDUjA=; b=ljjD1h5Noop8ycnt6WluypjEnXxgJy6ygt1WPSIKjdiU8gnSwGk29T4kURbMeI62XQ K9k3WEQ/Hkdop1O3DWLAdeQB2lwy8LV6TBo1SLHoLm4B5Jy1XFn7gEhhIUDS8vkUieNr WmR7Mfdj7bkLYI4BOzqsCdXrrtmLQ2AhcroCotjyAeMNnARvPRJ8LCsdqas2Et7S8gZn c1oY+DIG1d/6aTCDI1AvEAb1kvUuF51E15WAn5E/JX8EEA6DY3JisTUwkCxsB6TsvsB9 l9zWTkYcJcuQIWyLpArTNA194ZUG+nFDeuc98kWKetJNoQ31vFh3BdggbgeDF+cFKst6 uq9A== X-Gm-Message-State: APjAAAVTQvQFAEoGwL59lxvLvN6yIJX6v2TI6kDzP40H6jpm454vu8j4 oA2+SqELGpmJ7I12WyhuNVQqyHtvVFIcE25HEaw= X-Google-Smtp-Source: APXvYqwLmVzvya7wv0Q3DWdz1fFK8PABzi8OB7nwAj0b0FEABXEl8VbSFHaJpfBKu7q8Th8IOZ5uSsN9/RkMizuE558= X-Received: by 2002:a7b:cb97:: with SMTP id m23mr10801442wmi.37.1581780504227; Sat, 15 Feb 2020 07:28:24 -0800 (PST) MIME-Version: 1.0 From: Jean-Philippe Aumasson Date: Sat, 15 Feb 2020 16:28:13 +0100 Message-ID: To: cfrg@ietf.org Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001134b1059e9ef98c" Archived-At: Subject: [Crypto-panel] Review of draft-irtf-cfrg-kangarootwelve-01 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 15:28:29 -0000 --0000000000001134b1059e9ef98c Content-Type: text/plain; charset="UTF-8" Document: draft-irtf-cfrg-kangarootwelve-01 Reviewer: Jean-Philippe Aumasson Review Date: 2020-02-13 Summary: almost ready, editorial changes needed Conflict of interest warning: I'm a co-designer of BLAKE3, another fast hash function using a tree mode, recently announced at RWC, see https://github.com/BLAKE3-team/BLAKE3/. ## Draft content This draft specifies KangarooTwelve (K12), a Keccak variant introduced [in 2016](https://teserakt.io/doc/teserakt-product.pdf) that can be seen as a variant of the ParallelHash "SHA-3 derived function" standardized [by NIST in SP 800-185]( https://www.nist.gov/publications/sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) in December 2016. The version specified in the draft seems identical to that described in the [research paper](https://eprint.iacr.org/2016/770.pdf). The test vectors are the same. ## Technical merits The main selling point of K12 is its speed, from 1. doing 12 rounds instead of 24 for Keccak (which I believe is fine, as commented in my Too Much Crypto paper where I suggest 10 rounds only). 2. a parallel mode with unbounded fan-out and one parent node, allowing "unlimited parallelism". Compared to ParallelHash, K12's mode is more efficient on short messages. ParallelHash internally calls the variant cSHAKE, which is essentially the SHAKE XOF. The ParallelHashXOF variants provide XOF functionality as well but they are slower than K12 because of the round numbers. I find K12 a bit simpler. ## Adoption Like all the standard and non-standard SHA-3/Keccak variants (except maybe for SHAKE), K12 hasn't received much interest from application developers. But K12 is IMHO one of the variants that has the greatest application potential, in part thanks to its pragmatic round number. K12's official C code is available at https://github.com/XKCP/K12 and in the Keccak family package https://github.com/XKCP/XKCP. I found some third-party implementations: in [JS](https://github.com/twuni/kangaroo12.js), [Ruby](https://github.com/konsolebox/digest-kangarootwelve-ruby), and in [Go](https://github.com/mimoo/GoKangarooTwelve). K12 seems to be used in some PoW, at least there's a miner tool: https://github.com/Noob-X/Aeon-K12-cpuminer ## Editorial I cannot comment with the compliance with IETF style and formatting rules, not being familiar with these. The specification looks to me mostly standalone and complete. Specific comments: * in 2.1, in "outputByteLen (..) the Length", "Length" does not seem to require capitalization * 2.1 refers to "the absorbing phase" and to "the squeezing phase" for the first time, without said phases being defined/introduced. The notions are common in the Keccak ecosystem, but may be new to many readers. * in 2.1, the pseudocode refers twice to `inputBytes`, which is not defined; I think it should be `input` instead * notations such as `S_n-2`, meaning `S_(n-2)` rather than `(S_n)-2`, are error prone and should probably be avoided; same comment for other occurrences such as `x_n-1`. * "compute the 32-bytes Chaining Values": I believe the correct spelling is "32-byte". * "This computation SHOULD exploit the parallelism available on the platform in order to be optimally efficient": maybe be more specific? parallelism may refer to SIMD instructions and/or multi-core processing, for example. * pseudocode is sometimes spelled "pseudo code", sometimes "pseudo-code", not sure what IETF prefers. * "In the table below are gathered the values" would be clearer with active voice ("The table below gathers the values"). --0000000000001134b1059e9ef98c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-irtf-cfrg-kangarootwelve-01
Reviewer: J= ean-Philippe Aumasson
Review Date: 2020-02-13

Sum= mary: almost ready, editorial changes needed

Conflict of inte= rest warning: I'm a co-designer of BLAKE3, another fast=C2=A0
hash function using a tree mode, recently announced at RWC, see https://github.com/BLAKE3-team/BLA= KE3/.


## Draft content

This draft s= pecifies KangarooTwelve (K12), a Keccak variant introduced
[in 2016](https://teserakt.io/d= oc/teserakt-product.pdf) that can be seen
as a variant of the Parall= elHash "SHA-3 derived function" standardized [by
NIST in SP 80= 0-185](https://www.nist.gov/publications/= sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) in Dece= mber 2016.

The version specified in the draft seems identical to tha= t described in
the [research paper](https://eprint.iacr.org/2016/770.pdf). The test
vectors= are the same.

## Technical merits

The main selling point of = K12 is its speed, from

1. doing 12 rounds instead of 24 for Keccak (= which I believe is fine, as
commented in my Too Much Crypto paper where = I suggest 10 =C2=A0rounds only).

2. a parallel mode with unbounded f= an-out and one parent node, allowing
"unlimited parallelism".<= br>
Compared to ParallelHash, K12's mode is more efficient on short<= br>messages. ParallelHash internally calls the variant cSHAKE, which is
= essentially the SHAKE XOF. The ParallelHashXOF variants provide XOF
func= tionality as well but they are slower than K12 because of the round
numb= ers. I find K12 a bit simpler.

## Adoption

Like all the stand= ard and non-standard SHA-3/Keccak variants (except
maybe for SHAKE), K12= hasn't received much interest from application developers. But K12 is = IMHO one of the variants that has the greatest application potential, in pa= rt thanks to its pragmatic round number.

K12's official C code i= s available at https://github.com/X= KCP/K12 and in
the Keccak family package https://github.com/XKCP/XKCP.

I found some third-p= arty implementations: in
[JS](https://github.com/twuni/kangaroo12.js),
[Ruby](https://github.c= om/konsolebox/digest-kangarootwelve-ruby), and in
[Go](https://github.com/mimoo/GoKangaro= oTwelve).

K12 seems to be used in some PoW, at least =C2=A0there= 's a miner tool:
https://github.com/Noob-X/Aeon-K12-cpuminer


## Editoria= l

I cannot comment with the compliance with IETF style and formattin= g
rules, not being familiar with these.

The specification looks t= o me mostly standalone and complete.

Specific comments:

* in = 2.1, in "outputByteLen (..) the Length", "Length" does = not seem to
=C2=A0 require capitalization

* 2.1 =C2=A0refers to &= quot;the absorbing phase" and to "the squeezing phase" for=C2=A0 the first time, without said phases being defined/introduced. The<= br>=C2=A0 notions are common in the Keccak ecosystem, but may be new to man= y
=C2=A0 readers.

* in 2.1, the pseudocode =C2=A0refers twice to = `inputBytes`, which is not
=C2=A0 defined; I think it should be `input` = instead

* notations such as `S_n-2`, meaning `S_(n-2)` rather than `= (S_n)-2`,
=C2=A0 are error prone and should probably be avoided; same co= mment for other
=C2=A0 occurrences such as `x_n-1`.

* "compu= te the 32-bytes Chaining Values": I believe the correct spelling
= =C2=A0 is "32-byte".

* "This computation SHOULD explo= it the parallelism available on the
=C2=A0 =C2=A0platform in order to be= optimally efficient": maybe be more specific?
=C2=A0 =C2=A0paralle= lism may refer to SIMD instructions and/or multi-core
=C2=A0 =C2=A0proce= ssing, for example.

* pseudocode is sometimes spelled "pseudo c= ode", =C2=A0sometimes
=C2=A0 "pseudo-code", not sure what= IETF prefers.

* "In the table below are gathered the values&qu= ot; would be clearer with
=C2=A0 active voice ("The table below gat= hers the values").


--0000000000001134b1059e9ef98c-- From nobody Mon Feb 17 18:26:53 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25C12011E for ; Sun, 16 Feb 2020 21:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 rP8oas5Rwb8Z for ; Sun, 16 Feb 2020 21:25:57 -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 4E1D312011B for ; Sun, 16 Feb 2020 21:25:57 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id 203so10849318lfa.12 for ; Sun, 16 Feb 2020 21:25:57 -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=p2EluauYl6yW/X7yfpAWSqYAee8vBRFVnWlbJgMRooY=; b=HNnTmziVtEq8lPWnkGNX2PNyZwcTVN0Ub2Md9h7/9QjNDMkceSuwmM4UlWglM8+VTE GmErN0kJ9/BqkL25MId8tgdB1xNn6K2+HA7jMDOsMcPZ9phE3jJ5LL5/w2d+r3J08X52 4asYh7WFRwhF4R/MEsqJNRtgF0tuu3RJlb0fvcFeH1kqALN5ayU7gTa0EWnyHiFs8jzz U5qAd/b7iJ1IcKKpnNcOd1RWrrgPTy3EEv1vfSO1UDBASusInN8vIyfupoH1xaNodMwX kBicpAPCrFfxYPSD1Jiqk0Hpw2pIsXbOBxZJhaCJhtBoemsV0zoTptc/OiGx0JfNi5fq ENZA== 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=p2EluauYl6yW/X7yfpAWSqYAee8vBRFVnWlbJgMRooY=; b=BglHmANBZZpUlp3Z6rqmxCjFFqFjcR4PvbKSggCT1rk/t1xx0E7Dw2jmd0RmF2dJQ+ 24G/QqNaGifysPjP+HzvGl33CN6bX6tmwkpR79lE5/MmP0iGY+WGmj+zZdY+zQOc+bmv NTQtSTP9Ii8ep0AuOTubZUSejRJF/3dJsSUcEmC1G0PCr/bMqQeoI2rG0jJokF/PNKk2 r0/te51Z6hvyxvDlKAXObel05Qs/tjT9ICZgKcAfD4cg52mo6PvcArulSjgnPYORU8II iEnWpBjN8imzNJ5iZ1RkSAU7WJDYi2clCccw5y+EHcTLAKzOtaBTftzzy063qq7j/rhT dLHw== X-Gm-Message-State: APjAAAWMENGD+Y1wounXs2JOu8cQ4thRGVqyJn+3EwgznM6c9hN5K1x0 4coeUHpb2z/lIFPgDOvyfCpbc8fXDrTE44oyH0c= X-Google-Smtp-Source: APXvYqwS1avu3BmDPHc1em9LOuLzuvm+krf9QUWXlvvglWbnqToUkhygPQ2cr4Pz4n/hFv0+Q2/3iWdulWjaEgpf9zg= X-Received: by 2002:ac2:52a3:: with SMTP id r3mr7055780lfm.189.1581917155265; Sun, 16 Feb 2020 21:25:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 17 Feb 2020 08:26:11 +0300 Message-ID: To: Russ Housley , Bjoern Tackmann , Julia Hesse Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a9280059ebecaf7" Archived-At: Subject: Re: [Crypto-panel] Reviews for 4 PAKEs (PAKE slection process) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 05:26:01 -0000 --0000000000001a9280059ebecaf7 Content-Type: text/plain; charset="UTF-8" Dear Russ, Bjoern and Julia! Thanks a lot for agreeing to prepare your reviews for the Round 2 of the PAKE selection process! The new answers of the authors have been provided in the mailing list (see links at https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-round-2 ). The previous overall reviews by Bjoern Tackmann, myself, Russ Housley and Yaron Sheffer are available at https://github.com/cfrg/pake-selection/blob/master/README.md#overall-reviews-by-crypto-review-panel . All other reviews are available here: https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-reviews We ask each of you to prepare a review for the *4 remaining protocols passed to Round 2: CPace, SPAKE2 (balanced) and AuCPace, OPAQUE (augmented)*, with the main focus on the new information provided in the new answers ( https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-round-2 ). We ask you to do this before *March, 10th*, so that we have some time before the meeting to discuss the results with Alexey and Nick. Thanks a lot again! Best regards, Stanislav, on behalf of chairs On Tue, 11 Feb 2020 at 09:42, Stanislav V. Smyshlyaev wrote: > Dear Crypto Review Panel members, > > Due to the plan of the second round of the PAKE selection process, we're > approaching Stage 4 of Round 2: > > *Stage 4: February, 12th - March, 10th* > *Crypto Review Panel members prepare new overall reviews (for > all 4 remaining PAKEs) taking into account both the reviews obtained > on Round 1 and new information obtained during Round 2.* > > Let me remind you, that we have 4 candidates passed to Round 2: CPace, > SPAKE2 (balanced) and AuCPace, OPAQUE (augmented). > > The authors of the protocols have provided their answers to the additional > questions that were asked after IETF 106 meeting (see > https://github.com/cfrg/pake-selection/blob/master/README.md#questions-for-round-2 > ). > > Their answers have been provided in the mailing list (see links at > https://github.com/cfrg/pake-selection/blob/master/README.md#answers-on-round-2 > ). > > The previous overall reviews by Bjoern Tackmann, myself, Russ Housley and > Yaron Sheffer are available at > https://github.com/cfrg/pake-selection/blob/master/README.md#overall-reviews-by-crypto-review-panel > . All other reviews are available here: > https://github.com/cfrg/pake-selection/blob/master/README.md#summary-of-reviews > > So now we need reviews (each review should consider all 4 protocols - > otherwise it will be more difficult to compare) for the remaining > candidates. The reviews should be done before *March, 10th*. > > First of all, it will be very important if *Bjoern, Russ *and *Yaron* > could do their new (or, better to say, updated) reviews, since they have > done them at the previous round. It will be great if Scott could > participate, since he provided very important reviews on certain issues. > Also since now we have *Chloe, Julia, Karthikeyan, Thomas, Jean-Philippe *and > *Jon *on board. > In this process we need as many good reviews as possible, so we ask all of > you to consider your participation. > > Please let us know, whether you are ready to do this, before *February, > 13th*. > > Regards, > Stanislav (on behalf of the CFRG chairs) > > > --0000000000001a9280059ebecaf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Russ, Bjoern and Julia!

Thanks a lot for agreeing to prepare your reviews for the Round 2 of= the PAKE selection process!=C2=A0

The new answers= of the authors have been provided in the mailing list (see links at=C2=A0<= a href=3D"https://github.com/cfrg/pake-selection/blob/master/README.md#answ= ers-on-round-2" target=3D"_blank">https://github.com/cfrg/pake-selection/bl= ob/master/README.md#answers-on-round-2).


We a= sk each of you to prepare a review for the 4 remaining protocols=20 passed to Round 2: CPace, SPAKE2 (balanced) and AuCPace, OPAQUE (augmented= ), with the main focus on the new information provided in the new answe= rs (https://github.com/cfrg/pake-selection/blob/master/REA= DME.md#answers-on-round-2).=C2=A0

We ask you t= o do this before=C2=A0March, 10th, so that we have some time before = the meeting to discuss the results with Alexey and Nick.

Thanks a lot again!

Best regards,
Stanislav, on behalf of chairs

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, 11 Feb 2020 at 09:42, Stanisla= v V. Smyshlyaev <smyshsv@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Dear Crypto Review Panel members,

Due to= the plan of the second round of the PAKE selection process, we're appr= oaching Stage 4 of Round 2:

Stage=C2=A04: February, 12th - March, 10th
Cry= pto Review Panel members prepare new overall reviews (for all=C2=A04<= /span>=C2=A0remaining PAKEs) taking into account both the reviews obtained = on=C2=A0Round=C2=A01 and new information obtained during=C2=A0= Round=C2=A02.

Their answ= ers have been provided in the mailing list (see links at=C2=A0https://github.com/cfrg/pake-selection/blob/master/RE= ADME.md#answers-on-round-2).

The previous over= all reviews by Bjoern Tackmann, myself, Russ Housley and Yaron Sheffer are = available at=C2=A0ht= tps://github.com/cfrg/pake-selection/blob/master/README.md#overall-reviews-= by-crypto-review-panel . All other reviews are available here:=C2=A0https://github.com/cfrg/pake-selection/blob= /master/README.md#summary-of-reviews

So now we= need reviews (each review should consider all 4 protocols - otherwise it w= ill be more difficult=C2=A0to compare) for the remaining candidates. The reviews should be done before March, 10th.=C2=A0

First of all, it will be very important if Bjo= ern, Russ and Yaron could do their new (or, better to say, updat= ed) reviews, since they have done them at the previous round. It will be gr= eat if Scott could participate, since he provided very important reviews on= certain issues.
Also since now we have Chloe, Julia,=C2=A0Kar= thikeyan, Thomas,=C2=A0Jean-Philippe and Jon on board.
In this process we need as many good reviews as possible, so we ask all of= you to consider your participation.

Pl= ease let us know, whether you are ready to do this, before February, 13t= h.

Regards,
Stanislav (on behalf of = the CFRG chairs)


--0000000000001a9280059ebecaf7-- From nobody Mon Feb 17 18:30:13 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7E120821 for ; Mon, 17 Feb 2020 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DmHlSiqm37Dr for ; Mon, 17 Feb 2020 02:24:23 -0800 (PST) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 5D4081201E4 for ; Mon, 17 Feb 2020 02:24:23 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id w15so19001282wru.4 for ; Mon, 17 Feb 2020 02:24:23 -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=MF7U9AfIfPO5WhC99cUMgWqKPuwZ+s9OpX5nB6JGhhg=; b=i5CDdfHOEszmmca7zYSl1GjawceykVhoTBjyZQhILyIf75DvUJF3DcYnmiI8AIKcm5 EW5NlEP9KPVBL3v4f88eHynFtmulmyLYNT3a0Znpsw/b15WTn6rtwZme9PZSQgJ9R0O5 WTj2z/m8gHc7jPcFbzTSHsFkLWoZzKUOnxdATGmZAnTKA5bLuc+OhYi31UimboL/RK3s LEOZj8KBS9SmwmgcAs1xz4ZiEFNx/4FJpjej2nM1EVVH7mGSyRfkDYAHrY2F+H0XvHlE 5OmnEC5ch/V+hAQnmpihFzK1heqADr1juFO8qjodpZOVQbm0n0m+tTFFZktwPnp8AE2o lk/A== 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=MF7U9AfIfPO5WhC99cUMgWqKPuwZ+s9OpX5nB6JGhhg=; b=smYIVKpKid1+/kot67UUjA1akc+x5CoGRC14UqF50/C3rpozO4fe9r/Vd6FTUFo+PB JSzNfBqS/G+hFAAObjjNKsIzVbrCk6ZZC95T+fw+GKvy07Nez2Hu+4RhaIdKVI8p4q53 /KBzyMuiRf4ARnzfvcm6bQNyfc5TKToBz/W/F8hLhKJl04LRy1P6GM9COgcQu9/7fZRH hdTtXCxvLBrALlrri9uF3SBwESl+Nf1WOPK6M4N7p6K2zR8viXBuhbTQu0lLKSueGM20 9aPC7Q38pILMh8cUBpTVBDy0HrOhaDol3aYQUow1a11P8/tb+XIa4zHe8S8gv/oW9BJC aUHA== X-Gm-Message-State: APjAAAViCkB2nSIs/VlkGINAScW8bQ8qEuIYZvYFPMEMWS0qbADYGkH6 clI413wtbgQW5btdDaDr/VNvHuOZw0wFYUYruK4= X-Google-Smtp-Source: APXvYqx50ZlJmw/88T3Cy3Gf4289NFX+kIMcoe//UZ0fUn2HePvMREBZKJ4HIk6Cis7bSFJWczIJt6G+GcCeIThcXNE= X-Received: by 2002:adf:f744:: with SMTP id z4mr17232490wrp.318.1581935061752; Mon, 17 Feb 2020 02:24:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Mon, 17 Feb 2020 11:24:10 +0100 Message-ID: To: cfrg@ietf.org Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000069de67059ec2f523" Archived-At: Subject: Re: [Crypto-panel] Review of draft-irtf-cfrg-kangarootwelve-01 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 10:24:27 -0000 --00000000000069de67059ec2f523 Content-Type: text/plain; charset="UTF-8" Errata: major copypasta fail, K12 link should be [in 2016]( https://eprint.iacr.org/2016/770.pdf), corrected version below Document: draft-irtf-cfrg-kangarootwelve-01 Reviewer: Jean-Philippe Aumasson Review Date: 2020-02-13 Summary: almost ready, editorial changes needed Conflict of interest warning: I'm a co-designer of BLAKE3, another fast hash function using a tree mode, recently announced at RWC, see https://github.com/BLAKE3-team/BLAKE3/. ## Draft content This draft specifies KangarooTwelve (K12), a Keccak variant introduced [in 2016](https://eprint.iacr.org/2016/770.pdf) that can be seen as a variant of the ParallelHash "SHA-3 derived function" standardized [by NIST in SP 800-185]( https://www.nist.gov/publications/sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) in December 2016. The version specified in the draft seems identical to that described in the [research paper](https://eprint.iacr.org/2016/770.pdf). The test vectors are the same. ## Technical merits The main selling point of K12 is its speed, from 1. doing 12 rounds instead of 24 for Keccak (which I believe is fine, as commented in my Too Much Crypto paper where I suggest 10 rounds only). 2. a parallel mode with unbounded fan-out and one parent node, allowing "unlimited parallelism". Compared to ParallelHash, K12's mode is more efficient on short messages. ParallelHash internally calls the variant cSHAKE, which is essentially the SHAKE XOF. The ParallelHashXOF variants provide XOF functionality as well but they are slower than K12 because of the round numbers. I find K12 a bit simpler. ## Adoption Like all the standard and non-standard SHA-3/Keccak variants (except maybe for SHAKE), K12 hasn't received much interest from application developers. But K12 is IMHO one of the variants that has the greatest application potential, in part thanks to its pragmatic round number. K12's official C code is available at https://github.com/XKCP/K12 and in the Keccak family package https://github.com/XKCP/XKCP. I found some third-party implementations: in [JS](https://github.com/twuni/kangaroo12.js), [Ruby](https://github.com/konsolebox/digest-kangarootwelve-ruby), and in [Go](https://github.com/mimoo/GoKangarooTwelve). K12 seems to be used in some PoW, at least there's a miner tool: https://github.com/Noob-X/Aeon-K12-cpuminer ## Editorial I cannot comment with the compliance with IETF style and formatting rules, not being familiar with these. The specification looks to me mostly standalone and complete. Specific comments: * in 2.1, in "outputByteLen (..) the Length", "Length" does not seem to require capitalization * 2.1 refers to "the absorbing phase" and to "the squeezing phase" for the first time, without said phases being defined/introduced. The notions are common in the Keccak ecosystem, but may be new to many readers. * in 2.1, the pseudocode refers twice to `inputBytes`, which is not defined; I think it should be `input` instead * notations such as `S_n-2`, meaning `S_(n-2)` rather than `(S_n)-2`, are error prone and should probably be avoided; same comment for other occurrences such as `x_n-1`. * "compute the 32-bytes Chaining Values": I believe the correct spelling is "32-byte". * "This computation SHOULD exploit the parallelism available on the platform in order to be optimally efficient": maybe be more specific? parallelism may refer to SIMD instructions and/or multi-core processing, for example. * pseudocode is sometimes spelled "pseudo code", sometimes "pseudo-code", not sure what IETF prefers. * "In the table below are gathered the values" would be clearer with active voice ("The table below gathers the values"). On Sat, Feb 15, 2020 at 4:28 PM Jean-Philippe Aumasson < jeanphilippe.aumasson@gmail.com> wrote: > Document: draft-irtf-cfrg-kangarootwelve-01 > Reviewer: Jean-Philippe Aumasson > Review Date: 2020-02-13 > > Summary: almost ready, editorial changes needed > > Conflict of interest warning: I'm a co-designer of BLAKE3, another fast > hash function using a tree mode, recently announced at RWC, see > https://github.com/BLAKE3-team/BLAKE3/. > > > ## Draft content > > This draft specifies KangarooTwelve (K12), a Keccak variant introduced > [in 2016](https://teserakt.io/doc/teserakt-product.pdf) that can be seen > as a variant of the ParallelHash "SHA-3 derived function" standardized [by > NIST in SP 800-185]( > https://www.nist.gov/publications/sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) > in December 2016. > > The version specified in the draft seems identical to that described in > the [research paper](https://eprint.iacr.org/2016/770.pdf). The test > vectors are the same. > > ## Technical merits > > The main selling point of K12 is its speed, from > > 1. doing 12 rounds instead of 24 for Keccak (which I believe is fine, as > commented in my Too Much Crypto paper where I suggest 10 rounds only). > > 2. a parallel mode with unbounded fan-out and one parent node, allowing > "unlimited parallelism". > > Compared to ParallelHash, K12's mode is more efficient on short > messages. ParallelHash internally calls the variant cSHAKE, which is > essentially the SHAKE XOF. The ParallelHashXOF variants provide XOF > functionality as well but they are slower than K12 because of the round > numbers. I find K12 a bit simpler. > > ## Adoption > > Like all the standard and non-standard SHA-3/Keccak variants (except > maybe for SHAKE), K12 hasn't received much interest from application > developers. But K12 is IMHO one of the variants that has the greatest > application potential, in part thanks to its pragmatic round number. > > K12's official C code is available at https://github.com/XKCP/K12 and in > the Keccak family package https://github.com/XKCP/XKCP. > > I found some third-party implementations: in > [JS](https://github.com/twuni/kangaroo12.js), > [Ruby](https://github.com/konsolebox/digest-kangarootwelve-ruby), and in > [Go](https://github.com/mimoo/GoKangarooTwelve). > > K12 seems to be used in some PoW, at least there's a miner tool: > https://github.com/Noob-X/Aeon-K12-cpuminer > > > ## Editorial > > I cannot comment with the compliance with IETF style and formatting > rules, not being familiar with these. > > The specification looks to me mostly standalone and complete. > > Specific comments: > > * in 2.1, in "outputByteLen (..) the Length", "Length" does not seem to > require capitalization > > * 2.1 refers to "the absorbing phase" and to "the squeezing phase" for > the first time, without said phases being defined/introduced. The > notions are common in the Keccak ecosystem, but may be new to many > readers. > > * in 2.1, the pseudocode refers twice to `inputBytes`, which is not > defined; I think it should be `input` instead > > * notations such as `S_n-2`, meaning `S_(n-2)` rather than `(S_n)-2`, > are error prone and should probably be avoided; same comment for other > occurrences such as `x_n-1`. > > * "compute the 32-bytes Chaining Values": I believe the correct spelling > is "32-byte". > > * "This computation SHOULD exploit the parallelism available on the > platform in order to be optimally efficient": maybe be more specific? > parallelism may refer to SIMD instructions and/or multi-core > processing, for example. > > * pseudocode is sometimes spelled "pseudo code", sometimes > "pseudo-code", not sure what IETF prefers. > > * "In the table below are gathered the values" would be clearer with > active voice ("The table below gathers the values"). > > > --00000000000069de67059ec2f523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Errata: major copypasta fail, K12 link should be [in 2016]= (https://eprint.iacr.org/2= 016/770.pdf), corrected version below

Document: draf= t-irtf-cfrg-kangarootwelve-01
Reviewer: Jean-Philippe Aumasson
Review= Date: 2020-02-13

Summary: almost ready, editorial c= hanges needed

Conflict of interest warning: I'm a co-desi= gner of BLAKE3, another fast=C2=A0
hash function using a tree mod= e, recently announced at RWC, see=C2=A0https://github.com/BLAKE3-team/BLAKE3/= .


## Draft content

This draft specifies= KangarooTwelve (K12), a Keccak variant introduced
[in 2016](https://eprint.iacr.org/2016/770.pdf<= /a>) that can be seen
as a variant of the ParallelHash "SHA-= 3 derived function" standardized [by
NIST in SP 800-185](https://www.nist.gov/publications= /sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) in Dec= ember 2016.

The version specified in the draft seems identical to th= at described in
the [research paper](https://eprint.iacr.org/2016/770.pdf). = The test
vectors are the same.

## Technical merits

The mai= n selling point of K12 is its speed, from

1. doing 12 rounds instead= of 24 for Keccak (which I believe is fine, as
commented in my Too Much = Crypto paper where I suggest 10 =C2=A0rounds only).

2. a parallel mo= de with unbounded fan-out and one parent node, allowing
"unlimited = parallelism".

Compared to ParallelHash, K12's mode is more = efficient on short
messages. ParallelHash internally calls the variant c= SHAKE, which is
essentially the SHAKE XOF. The ParallelHashXOF variants = provide XOF
functionality as well but they are slower than K12 because o= f the round
numbers. I find K12 a bit simpler.

## Adoption
Like all the standard and non-standard SHA-3/Keccak variants (except
ma= ybe for SHAKE), K12 hasn't received much interest from application deve= lopers. But K12 is IMHO one of the variants that has the greatest applicati= on potential, in part thanks to its pragmatic round number.

K12'= s official C code is available at=C2=A0https://github.com/XKCP/K12=C2=A0and in
the Ke= ccak family package=C2=A0https://github.com/XKCP/XKCP.

I found some third-party = implementations: in
[JS](https://github.com/twuni/kangaroo12.js),
[Ruby= ](https://github.com/konsolebox/digest-kangarootwelve-ruby)= , and in
[Go](https://github.com/mimoo/GoKangarooTwelve).

K12 se= ems to be used in some PoW, at least =C2=A0there's a miner tool:
http= s://github.com/Noob-X/Aeon-K12-cpuminer


## Editorial

= I cannot comment with the compliance with IETF style and formatting
rule= s, not being familiar with these.

The specification looks to me most= ly standalone and complete.

Specific comments:

* in 2.1, in &= quot;outputByteLen (..) the Length", "Length" does not seem = to
=C2=A0 require capitalization

* 2.1 =C2=A0refers to "the = absorbing phase" and to "the squeezing phase" for
=C2=A0 = the first time, without said phases being defined/introduced. The
=C2=A0= notions are common in the Keccak ecosystem, but may be new to many
=C2= =A0 readers.

* in 2.1, the pseudocode =C2=A0refers twice to `inputBy= tes`, which is not
=C2=A0 defined; I think it should be `input` instead<= br>
* notations such as `S_n-2`, meaning `S_(n-2)` rather than `(S_n)-2`= ,
=C2=A0 are error prone and should probably be avoided; same comment fo= r other
=C2=A0 occurrences such as `x_n-1`.

* "compute the 3= 2-bytes Chaining Values": I believe the correct spelling
=C2=A0 is = "32-byte".

* "This computation SHOULD exploit the par= allelism available on the
=C2=A0 =C2=A0platform in order to be optimally= efficient": maybe be more specific?
=C2=A0 =C2=A0parallelism may r= efer to SIMD instructions and/or multi-core
=C2=A0 =C2=A0processing, for= example.

* pseudocode is sometimes spelled "pseudo code",= =C2=A0sometimes
=C2=A0 "pseudo-code", not sure what IETF pref= ers.

* "In the table below are gathered the values" would = be clearer with
=C2=A0 active voice ("The table below gathers the v= alues").


On Sat, Feb 15, 2020 at 4:28 PM Jean-Philippe= Aumasson <jeanphilip= pe.aumasson@gmail.com> wrote:
Document: draft-irtf-cfrg-kangarootwe= lve-01
Reviewer: Jean-Philippe Aumasson
Review Date: 2020-02-13

Summary: almost ready, editorial changes needed

Conflict of interest warning: I'm a co-designer of BLAKE3, another= fast=C2=A0
hash function using a tree mode, recently announced a= t RWC, see https://github.com/BLAKE3-team/BLAKE3/.


## Draft= content

This draft specifies KangarooTwelve (K12), a Kec= cak variant introduced
[in 2016](https://teserakt.io/doc/teserakt-produc= t.pdf) that can be seen
as a variant of the ParallelHash "SHA-3= derived function" standardized [by
NIST in SP 800-185](https://www.nist.gov/publications/= sha-3-derived-functions-cshake-kmac-tuplehash-and-parallelhash) in Dece= mber 2016.

The version specified in the draft seems identical to tha= t described in
the [research paper](https://eprint.iacr.org/2016/770.pdf). T= he test
vectors are the same.

## Technical merits

The main= selling point of K12 is its speed, from

1. doing 12 rounds instead = of 24 for Keccak (which I believe is fine, as
commented in my Too Much C= rypto paper where I suggest 10 =C2=A0rounds only).

2. a parallel mod= e with unbounded fan-out and one parent node, allowing
"unlimited p= arallelism".

Compared to ParallelHash, K12's mode is more e= fficient on short
messages. ParallelHash internally calls the variant cS= HAKE, which is
essentially the SHAKE XOF. The ParallelHashXOF variants p= rovide XOF
functionality as well but they are slower than K12 because of= the round
numbers. I find K12 a bit simpler.

## Adoption

= Like all the standard and non-standard SHA-3/Keccak variants (except
may= be for SHAKE), K12 hasn't received much interest from application devel= opers. But K12 is IMHO one of the variants that has the greatest applicatio= n potential, in part thanks to its pragmatic round number.

K12's= official C code is available at https://github.com/XKCP/K12 and in
the Keccak family= package https:/= /github.com/XKCP/XKCP.

I found some third-party implementations:= in
[JS](https://github.com/twuni/kangaroo12.js),
[Ruby](h= ttps://github.com/konsolebox/digest-kangarootwelve-ruby), and in
[Go= ](h= ttps://github.com/mimoo/GoKangarooTwelve).

K12 seems to be used = in some PoW, at least =C2=A0there's a miner tool:
https://github.com/= Noob-X/Aeon-K12-cpuminer


## Editorial

I cannot commen= t with the compliance with IETF style and formatting
rules, not being fa= miliar with these.

The specification looks to me mostly standalone a= nd complete.

Specific comments:

* in 2.1, in "outputByte= Len (..) the Length", "Length" does not seem to
=C2=A0 re= quire capitalization

* 2.1 =C2=A0refers to "the absorbing phase= " and to "the squeezing phase" for
=C2=A0 the first time,= without said phases being defined/introduced. The
=C2=A0 notions are co= mmon in the Keccak ecosystem, but may be new to many
=C2=A0 readers.
=
* in 2.1, the pseudocode =C2=A0refers twice to `inputBytes`, which is n= ot
=C2=A0 defined; I think it should be `input` instead

* notatio= ns such as `S_n-2`, meaning `S_(n-2)` rather than `(S_n)-2`,
=C2=A0 are = error prone and should probably be avoided; same comment for other
=C2= =A0 occurrences such as `x_n-1`.

* "compute the 32-bytes Chaini= ng Values": I believe the correct spelling
=C2=A0 is "32-byte&= quot;.

* "This computation SHOULD exploit the parallelism avail= able on the
=C2=A0 =C2=A0platform in order to be optimally efficient&quo= t;: maybe be more specific?
=C2=A0 =C2=A0parallelism may refer to SIMD i= nstructions and/or multi-core
=C2=A0 =C2=A0processing, for example.
<= br>* pseudocode is sometimes spelled "pseudo code", =C2=A0sometim= es
=C2=A0 "pseudo-code", not sure what IETF prefers.

* = "In the table below are gathered the values" would be clearer wit= h
=C2=A0 active voice ("The table below gathers the values").<= br>

--00000000000069de67059ec2f523-- From nobody Thu Feb 27 09:56:17 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741183A0E38 for ; Thu, 27 Feb 2020 09:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 9Ja8FIdcX95A for ; Thu, 27 Feb 2020 09:56:12 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B9D3A0E3D for ; Thu, 27 Feb 2020 09:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 941FA300B43 for ; Thu, 27 Feb 2020 12:56:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mHYWBJNuvKAf for ; Thu, 27 Feb 2020 12:56:08 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id EAD06300A02; Thu, 27 Feb 2020 12:56:07 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 27 Feb 2020 12:56:09 -0500 Cc: crypto-panel@irtf.org To: cfrg-chairs@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Crypto-panel] Round 2 Stage 4 of PAKE selection process X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 17:56:16 -0000 CFRG is looking for a PAKE to support TLS 1.3 and IKEv2. I provided an = earlier review as part of Round 1, and I am providing this review as = part of Round 2 (Stage 4). The candidate algorithms fro Round 2 have = been reduced to four choices, two Balanced PAKE algorithms and two = Augmented PAKE algorithms. Augmented PAKE (OPAQUE vs AuCPace) RECOMMENDATION: OPAQUE OPAQUE uses fewer messages than AuCPace. The recent update to AuCPace = (called AuPace without explicit key confirmation) reduces the round = trips from the version that reviewed the the previous round. OPAQUE is = modular, so the CFRG will need to make choices for each of the component = parts. On one hand, the computational cost cannot be clearly known = without picking all of the components. On the other hand, there are = reasonable choices for all of the components that fit well with TLS 1.3 = and IKEv2, and if a problem is ever found with a particular choice, = there are replacements already on the shelf. Assuming very reasonable = choices for the components, OPAQUE uses less computation that AuCPace. = In addition, OPAQUE is "post-quantum prepared". That is, the modular = design allows post-quantum components to be selected after the NIST = competition is complete. The biggest downside was already raise by = Scott Fluhrer, and that is the lack of "quantum annoyance". Despite = this downside, in my view, the modularity and reduced computational cost = tilt the scale in favor of OPAQUE. Balanced PAKE (CPace vs SPAKE2) RECOMMENDATION: CPace CPace requires fewwer elliptic curve operations by each party. CPace = has better "quantum annoyance" than SPAKE2. Neither algorithm is = "post-quantum prepared". (In fact, Watson Ladd said "SPAKE2 is unlikely = to have a post-quantum alternative".) The lack of response to the Third = Party IPR disclose against SPAKE2 is also a significant concern.