Re: [Cfrg] Round 2 of the PAKE selection process

"Hao, Feng" <> Wed, 20 November 2019 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 305B712083F for <>; Wed, 20 Nov 2019 14:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DSEULew13pPs for <>; Wed, 20 Nov 2019 14:49:01 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe1f::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE5D5120836 for <>; Wed, 20 Nov 2019 14:49:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=lAsE63YLKBWh72lszFmAA1DFULwkRaL3gTDRW2DuOW4kSS6Ccc9Yj9KoNdcDmxlJUmR/0BAjgs3jhJkVL3kPSgTXX+gpXLS3N7hrq9AuBjJvA0+/iNHgQsVa3ElzkMK2uZkF49QVGInQysciaRatbFGOaMJzzLiqHsh6ES11D2WuBP80UHskHDTzR875gJioAh8I+QZoT2YKfNS3vEbEw5Whavm/IYmieHckUVv4PA4CFN2J2+QT0L0VqqQ5qJ/DrjBIAzSBGUtPUaKPKpGQkx4TTx8jcPU/854UQB6x3M2s4ZCZuLuikxwx5uGOwDe0bZqufUGNlhanBe0stdsezw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K96pNUt96clJET08QR8+k2stC2gpgnhj1jZ2WaOCX8Q=; b=a56S6DQaRluneB5zmKwS3GlroF9vz+RN/UnctgrE/FI9G32vM7hx5e8wUUTzUhUDR1XBGwKw1DAZ5hUAu8BxjZYfoAiTVNGkui0tpjAiydJgJV4otFdQl/qX/B2tw3EzuQi7MlWrFn7/n9Ytd1/OgiapdazAgW7LAtQS3DcDhwJ7+LSTz+1X4DqW3XpBBEOkcppjybcms1zjA8XYw03aZ/cHzoKqVrGAIM85Cdh+Q9HJMKxozMXNaaYEso4usiAMgjlTMn8toHoZPDgwqQ0Q1H6MdmJqPxdUuicCkw6245WYL78+zlxho4llY6SRTYyCUY89GPYqBJliee2C++88cg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Wed, 20 Nov 2019 22:48:57 +0000
Received: from ([fe80::e925:ac07:6d27:3073]) by ([fe80::e925:ac07:6d27:3073%7]) with mapi id 15.20.2474.015; Wed, 20 Nov 2019 22:48:57 +0000
From: "Hao, Feng" <>
To: "Stanislav V. Smyshlyaev" <>
Thread-Topic: [Cfrg] Round 2 of the PAKE selection process
Thread-Index: AQHVn2gUS25dXHzxpEuEV6PoAhn9EKeT2+aAgAAEC4CAAF5ZAIAAQqoA
Date: Wed, 20 Nov 2019 22:48:57 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1e.1.191020
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b7a45e7f-6ab2-4ce4-0607-08d76e0bd416
x-ms-traffictypediagnostic: DB7PR01MB4763:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(51914003)(199004)(189003)(81156014)(606006)(99286004)(1411001)(478600001)(229853002)(4326008)(6436002)(8676002)(6486002)(86362001)(966005)(413944005)(66066001)(26005)(5660300002)(186003)(6916009)(25786009)(8936002)(236005)(76176011)(6306002)(54896002)(33656002)(6512007)(6506007)(2906002)(53546011)(14454004)(786003)(3846002)(58126008)(6116002)(102836004)(446003)(66946007)(14444005)(256004)(64756008)(7736002)(76116006)(66476007)(66556008)(71190400001)(71200400001)(66446008)(476003)(486006)(11346002)(316002)(91956017)(6246003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB4763;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UYPhcvkvIOHeT0jCxg6orhCbzMGjivMxg8hJhx+DsXr5swJ56PMd8BBMRQ/kEb4fkXTaS6UhrA+1f+BwE7iQr/GvQ++hSHbzdXPjPuE7rUyF74Bug3/Z1v2bzYFPRffiWIlgUcVrJhVy0gd5ZIU4laVkm2FpdU51PcJJWk7mZkYinqTlxYpF/pS/BJc2dI4a1/zqQ5ax9VCM871Zm3PovX4PRl8XPg1cGfH8TmUuXl3MW2PtiBkLIO0j7Il+M3Xnj3PN9EAVjyijbY4S6XtT6ONzBjr8Bm2vx4DdClKHiEBXMrHXbfCzk+HKEiV4gbP0j32kwo6wQ/ul6FjKFmwfJQ3fXFPIYMvxKDqBtboMumyDtkG6YfljlH8GTlpsDFuD7Lb+rSYpeF2FDjyk+E8wsDXpgMU3JhE5PxtH/kIFqLS7p11TQa8T/eEcXxpTtOF6G6zZcexUMN+yVocnEbKLZNZFA0smXm4Kfjqu++osCro=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_8DDC5DF8B89C461CAA339C7F616A3540livewarwickacuk_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b7a45e7f-6ab2-4ce4-0607-08d76e0bd416
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 22:48:57.6684 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yOhmADlf2L/rl1zkPlREXDjrMBYUbr+LTjtqFEvY1IMwieq6mYPonEZmXVJtXh9V+pEY9wLxSYbdbLxSQ0l1/CBxss8EmjWbcqQ3WeSD5bw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB4763
Archived-At: <>
Subject: Re: [Cfrg] Round 2 of the PAKE selection process
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 22:49:04 -0000

Dear Stanislav,

In the previous discussions on the CFRG list, several questions about the panel reviews (linked below in your email) were raised. They include: the cost of the map-to-field operation has been almost entirely neglected for the finite field setting, which has caused a significant bias in the efficiency comparison; as for the elliptic curve setting, the details on hash-to-curve are yet to be finalized, so the cost remains unconfirmed, but it has been largely neglected in the efficiency analysis;  it remains unclear if the hash-to-curve will guarantee to be a constant-time operation for all the curves that it is meant to support or whether this constant-time requirement is relevant in the specific context of a protocol (this is related to the question that a candidate protocol must be fully specified so to allow meaningful analysis and a fair comparison with others); given that there is no (yet) general solution to do hash-to-curve, there is a question whether things might break in the future for new curves or whether that is an irrelevant concern; there is also a question whether the assumption of a trusted setup is considered acceptable and if yes, the worse-case scenario should be analysed to properly justify that choice.

I think these are relevant and important issues to consider. I had hoped that the panel would consider these questions (along with other questions raised in the list) and respond with a summary of justifications for their decision before going forward to round 2. That will give a proper closure of round 1. In any case, I appreciate all the efforts put in by the panel. I respect how this process is currently run and the result, so I don’t intend to change anything. But I hope these questions are still relevant and helpful for the round 2.


From: Cfrg <> on behalf of "Stanislav V. Smyshlyaev" <>
Date: Wednesday, 20 November 2019 at 16:22
To: "" <>
Subject: Re: [Cfrg] Round 2 of the PAKE selection process

To eliminate any possible misunderstanding: "the Crypto Review Panel member reviews" in my previous message = the four overall reviews provided by the Crypto Review Panel experts:


ср, 20 нояб. 2019 г. в 13:43, Stanislav V. Smyshlyaev <<>>:
Dear Feng,

The decision was made based on the Crypto Review Panel member reviews (which in turn were based on partial reviews by independent experts), which are available at (see “Overall reviews by Crypto Review Panel”).

Best regards,

ср, 20 нояб.. 2019 г. в 18:29, Hao, Feng <<>>:
Dear Stanislav (and the review panel),

Many thanks for the update.

For the benefits of openness and transparency, can you give reasons why these four were selected and the rest were removed? I couldn’t find those on your slides.

I’m sure that’ll be helpful for people on the CRFG to understand better this selection process.


From: Cfrg <<>> on behalf of "Stanislav V. Smyshlyaev" <<>>
Date: Wednesday, 20 November 2019 at 06:02
To: "<>" <<>>
Cc: "<>" <<>>
Subject: [Cfrg] Round 2 of the PAKE selection process

Dear CFRG,

As we've announced at the CFRG session today, now we're starting the Round 2 of the PAKE selection process.

We have narrowed down choices to: two balanced (SPAKE2 and CPace) and two augmented (OPAQUE and AuCPace).

Some additional information can be found in my slides from the IETF 106 CFRG meeting:

Please take a look at the plan and especially at Stage 1 - please send your additional questions to be considered at Round 2 to<> until December, 5th.

Round 2 of the PAKE selection process
Stage 1: November, 21st - December, 5th
Additional questions for all four candidates are collected from CFRG participants  (and Crypto Review Panel members). The questions can be of one of possible types:
a) Requests for clarifications for the candidate protocols or their proposed modifications (e.g., security of CPace and AuCPace without negotiation of sid, security and convenient of SPAKE2 with a hash2curve function used to obtain M and N for each pair of identifiers).
b) Questions to be taken into account in addition to ones collected at Stage 1 of Round 1 (e.g., quantum annoyance, post-quantum preparedness).
The questions should be sent to<>.

Stage 2: December, 10th - December, 17th
A list of new questions is published on; the CFRG is asked whether anything else should be added.

Stage 3: December 25th - February, 10th
The authors of the candidates prepare their replies to the additional questions/requested clarifications.

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.

IETF 107:
The CFRG chairs discuss the obtained reviews and make their recommendations to CFRG (or convey to CFRG that they can’t make a recommendation yet).
If everything is clear:
- one (or zero) balanced PAKE is selected;
- one (or zero) augmented PAKE is selected;
- the process with CFRG document “Recommendations for password-based authenticated key establishment in IETF protocols” is initiated: all practically important recommendations (parameter selection, protecting implementations against side-channel attacks, handling of counters etc.) must be given there.

Best regards,
Stanislav Smyshlyaev
CFRG Secretary

С уважением,

Станислав Смышляев, к.ф.-м.н.,

Заместитель генерального директора