Re: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

"Hao, Feng" <> Tue, 07 January 2020 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 137A41200C5 for <>; Tue, 7 Jan 2020 05:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6QPdmmV6-2Zi for <>; Tue, 7 Jan 2020 05:02:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43FA41200B6 for <>; Tue, 7 Jan 2020 05:02:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=LmYzW6v5pH2GI+ipWLC4C6afQFcNflW+xQinhJlcTRlkdXxF0WudPgMqvb9Yl3vUeQw96ZrxyxyI49DeH7Pd1TCZ1a05Wtqji9Hje9K3KBONF2rAxiiSsZ8F/9WnTyuIL28zYIH6wcu5exKKHsps0PYAX7yx0SXn6wvNNIkrJz7T75zAAUz/n6H9TJ4U4ax+QJu6y/KseyerukspxjQdBoXjcsenqoimY23vJ8qRh/mrfgIKTB2a5LFiPSJRDAuHciZM9icXj1+uM9suJp0pEp7f4qyQJOxmR9zt3ZY2wKJwQrk4ip2SNMPl8QKy+sDsklFpOa44TBXyO/sYZlnmiQ==
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=xVbCSxCeu9tymaUX3pLED8QcTEq1DA36yJ61rfBEDNM=; b=lHGBfcYpf+1iujlgR6cmLEfetY45rUMF3k4bKzIAlzIiB2qSO6DqCd2K23/L+CB30sOeaIOlhoSlfLywzhDz+pEfu15kmOJWyhL5t6EGydhi1ZqAti8unOcitobbzBqECxc6D3BsuCE0la1Ycz49ScV0slwqCTs3tfP7JTqjVj3+L+QtEyv4ZC265LGkhEDTm/Jbm4L6vllniCgCXlGg292bMCjJ6jn5/KbEG9cVHKD2zThHzunb1ASk/cs5ZvTw1UKribgoGrcFWo27ExJDecXNcozo8Av1Py7aLvzN4/IhIlCJpdGigwd32eUMxDdHRbH4Q5If09sEMEX80CVnMg==
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.2602.14; Tue, 7 Jan 2020 13:02:14 +0000
Received: from ([fe80::f059:923a:d030:fc69]) by ([fe80::f059:923a:d030:fc69%4]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 13:02:14 +0000
From: "Hao, Feng" <>
To: =?utf-8?B?IkJqw7ZybiBIYWFzZSI=?= <>
CC: <>
Thread-Topic: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available
Thread-Index: AQHVxOxLmN6fnIX7eUaVVmSPzY3m+6ffK4KA
Date: Tue, 7 Jan 2020 13:02:13 +0000
Message-ID: <>
References: <trinity-caa25477-d476-4e61-ba8b-384eafcf5a82-1578354680136@3c-app-webde-bap14>
In-Reply-To: <trinity-caa25477-d476-4e61-ba8b-384eafcf5a82-1578354680136@3c-app-webde-bap14>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7b0061b1-dea5-4a97-f5a8-08d79371d0e1
x-ms-traffictypediagnostic: DB7PR01MB4363:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(346002)(136003)(376002)(189003)(199004)(91956017)(2906002)(76116006)(86362001)(8676002)(66946007)(81166006)(81156014)(5660300002)(66574012)(316002)(786003)(6486002)(6916009)(26005)(186003)(53546011)(6506007)(9326002)(33656002)(66446008)(66476007)(478600001)(64756008)(6512007)(4326008)(71200400001)(8936002)(66556008)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB4363;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 82rGBRWt4FongdjFmiipP7ACUVYT5F0pmUMbqJtqV6IA63U+lOSvSmltQ3V7HWttXroA4CGAg1O+B9gRfV60tah1DP95AUqvllQrhJyZTcOVdMCWGsaVazbOSKM5bhHzyw1JZxsrFAKn/XGks35R7kwG4inT52kdLvVkST4BKbHhJsdhvDYzg/Rj43BOSZqrUabyw7UAH0F5tUYBsNaCBx3I8GkJD8aeIO0Qlw3t3tFJmqHw9NVvvi6rtn6IDnlWmaIrC19a8XR3fRWUsXrrwkwAUXML2c/rW3x9FhDIMbQUW1FY+h/DX3wStArbtSiTOXreY3JvjUG0EmtNBqeWFp49T0slTD1feAhfQyT2jpprple+nVsa7u4h9P+1S79OzIX+ruH8qSrkpZphN13qc1u0nc4oF2lCTGWMJ0Hp8erWDH28j3ZRP8lLBGAAtN9rIhL6SM58CkOji71TdiQSFMK7Fiq50+kPmFsWvix2CrM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_F52C621B0AEF4BB8BFBAA8E45DDC1947livewarwickacuk_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b0061b1-dea5-4a97-f5a8-08d79371d0e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 13:02:14.0182 (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: nTyi+q14fuzrn7BjtUCV2AM+tq+lNhFrmcWjarumCY7X/Z1tfXMwUKJVpkIU9yHcmmpL0Zm5vcYNbM9t3Wg+x+fGdubcxnnsmWuRCw2FSZ4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB4363
Archived-At: <>
Subject: Re: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available
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: Tue, 07 Jan 2020 13:02:23 -0000

Hi Bjorn,

I have a couple of comments for your consideration.

First of all, it’s not safe to assume the sender must know the receiver’s exact identity before the key exchange. Identities are normally transmitted “in-flow” as part of the key exchange protocol, as each party may not always know the other party’s exact identity beforehand. I understand Watson Ladd is trying to modify SPAKE2 by hashing the user identities before the key exchange to avoid the trusted setup, but that wouldn’t work for the same reason. Also, I suggest you have a look at the SPEKE specification in the IEEE P1363.2 (2006). If you interpret that specification literally, you may find it’s basically the same as the CPace protocol you propose. The trick is how you define the “shared secret”. In IEEE P1363.2, it’s defined as follows (also see [1])

“A password-based octet string which is generally derived from a password or a hashed password, identifiers for one or more entities, an identifier of a communication session if more than one session might execute concurrently, and optionally includes a salt value and/or other data.”

The items you define in the hash-to-curve function include the above. But obviously, the definition above is highly ambitious and makes the incorrect assumption that identities and session identifiers are always known by the other party even before the key exchange. This is addressed in the latest SPEKE specification in ISO/IEC 11770-4:2017, in which the shared secret is defined as “the password only”. No assumption is made about knowing the other party’s precise identity before the key exchange.

Second, some people on this list seem to assume hash-to-curve will provide you with an ideal RO-like mapping with negligible cost at a constant time. I would urge caution on that assumption until the fact is fully established. The use of hash-to-curve is not anything new; people in the PAKE field have been playing with that idea for nearly 2 decodes. There are previous efforts in IEEE P1363 (2000-2008) and ISO/IEC 11770-4 to define and standardize this function. However, over the past many years, hash-to-curve has been known to be notoriously difficult to get right. In fact, the original SPAKE2 protocol was designed with the motivation to avoid hash-to-curve (but it introduces the trusted setup assumption instead). We may need to wait a bit until the ongoing IEFT effort on defining and standardizing hash-to-curve to finish and for that to become a really established secure primitive (which will be a major contribution to the field, but we should not underestimate that this is actually a very tricky and challenging task).



From: Cfrg <> on behalf of Björn Haase <>
Date: Monday, 6 January 2020 at 23:52
To: "" <>
Subject: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

Dear CFRG community,

I have just posted a first version of an RFC-style draft regarding the balanced subcomponent CPace.

Any feedback would be appreciated!

A corresponding draft for the augmented protocol is in preparation.