Re: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process

"Hao, Feng" <Feng.Hao@warwick.ac.uk> Tue, 09 June 2020 11:16 UTC

Return-Path: <Feng.Hao@warwick.ac.uk>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16E93A0602 for <cfrg@ietfa.amsl.com>; Tue, 9 Jun 2020 04:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 b7TBq4G-Mf1J for <cfrg@ietfa.amsl.com>; Tue, 9 Jun 2020 04:16:04 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (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 95A2B3A05A4 for <cfrg@irtf.org>; Tue, 9 Jun 2020 04:16:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I6OhCiPpU+WTUX94kZmrxUO1nk5G/33pOtD//EtGngLumKEI4hRtVmjGgsMRwoguypNNRD2Nrp/i8Iv7GeeQW0kzNWy/UytGVxWu3DPdhC6i/GVQS/JVPNOywe2CbBJN0Vl+ubHhBpuFgyxqQwSX2WalGMbgEjbmGQQnSV44drB75r7A1mnPOyZk82JeZk2B1xHzuxpyuyU5c4oSWRZuk+vJJfY1XVKJJ9XffEVPvjhfhaDMraWr4ProRUCxdEuLCIafjfZxQ4vjYuYCGjFjqLE8aixU2GHnl0OkYzUW278h3jbiUBieCPLHh9/tfFfCrRlBIM/uKIwGvi1ZDQfU2g==
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=cKmQujBsBjK5jR/7eSURhY4xapblzJxcZprGy1YCgh8=; b=SJbXH/SZOEpTRYYaPA/qZdxcUeM9cp0hr74RpuU14ExikNtYta7vK2nMboLRFIs9byqso8o0lry7bgv0B/q0o+KrpYh4TuGfi5XBjnunPfHx6HTVf3bvjiV/DFuVTwHff6ACPOyPoZzZ/GuO8SoEEsaPY+qTRTI4+YCDZtE69QRi5yrMFgHBcbuD6cd2kopJBJYnznqxaCz76bJ10FHklUwy6myUla+buV+LgxmrPDYUdhNfPO+kz9goF0mlzz/uDyHxnGsucuoQ5Bl/v3Zo0O2AmllsrcfCxk6tQHeSlRH9YKtpkMpIOmBvbhZ3xP5ONMLtKfRiBcS4nnOYsLkoVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=warwick.ac.uk; dmarc=pass action=none header.from=warwick.ac.uk; dkim=pass header.d=warwick.ac.uk; arc=none
Received: from VI1PR01MB4285.eurprd01.prod.exchangelabs.com (2603:10a6:803:65::27) by VI1PR01MB4846.eurprd01.prod.exchangelabs.com (2603:10a6:803:93::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 11:15:59 +0000
Received: from VI1PR01MB4285.eurprd01.prod.exchangelabs.com ([fe80::dd1c:bb47:e1be:cc52]) by VI1PR01MB4285.eurprd01.prod.exchangelabs.com ([fe80::dd1c:bb47:e1be:cc52%6]) with mapi id 15.20.3066.019; Tue, 9 Jun 2020 11:15:59 +0000
From: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
To: =?utf-8?B?QmrDtnJuIEhhYXNl?= <bjoern.m.haase@web.de>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process
Thread-Index: AQHWOGXtLUgimOV9DUK437BW7TS86qjKopMAgAWcFwA=
Date: Tue, 9 Jun 2020 11:15:59 +0000
Message-ID: <07293BD9-6F9E-4048-AE0F-40B272000403@live.warwick.ac.uk>
References: <05097F26-F564-4817-B121-F4C9547DBFCD@ens.fr> <050425a7-de53-18a6-664e-2879da7cf5f4@web.de>
In-Reply-To: <050425a7-de53-18a6-664e-2879da7cf5f4@web.de>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: web.de; dkim=none (message not signed) header.d=none;web.de; dmarc=none action=none header.from=warwick.ac.uk;
x-originating-ip: [86.1.47.16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 75c7c153-f214-43bf-6b84-08d80c667cf8
x-ms-traffictypediagnostic: VI1PR01MB4846:
x-microsoft-antispam-prvs: <VI1PR01MB4846170D23E9B7CF35CBD194D6820@VI1PR01MB4846.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042957ACD7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jmTQRSzAB1poEP0DfZI3OUlnKuAxLpGYBMB+8ieoBGBu54luGQEYNCr7sdXCkvfajLgTRvui4zT+d2xdhF/OF3e+BmcHNcQf6qdmtkyFajRmKBpHiLoneBPo9gm5YqAjVKvNSRRmlV2is3CSV0IKgetdygKqFhMx2Ypx0abuiNAYL50Z4FyY8GTjeCr6IgHW2DryxYQYV5AQvxbJUPfkIQzklwFgrEbdJpLpXjp9W09oTc3DdBK2nTMYvP0vThw0SVQGotlhk1kG9GB5cK1+DmWOSjmb5ve9GrAu3SMg5q+WOfw1k6U46sMHl/zEk+2cggiBqpAQ8TplT6X2+kt4sA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB4285.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(8936002)(4326008)(26005)(71200400001)(8676002)(6486002)(6506007)(86362001)(6512007)(316002)(2906002)(786003)(5660300002)(76116006)(66946007)(66556008)(83380400001)(33656002)(66476007)(91956017)(186003)(6916009)(64756008)(66446008)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +0vqno3eBMZddNMyK1sJzOV3jCCP8yth0kR147aJhS8W/uzazY4/VGaoxQkxAqbQU+w60ptQvPQnqzV8nlkDxsf//eTGukj55h+CCPHTw31yOc2dOF3lOkj6HXEqeTfuL2wc/w0a8HvZ2aD62x6G2MBmDB9e9SFoTchB87ZOKhC4EK08eMKFlj2clG1sywbe3Q2NGDwPpE7bA7aUQkiFDQ42Nctzw+s+BLGnUDN2QlDaSBhKViCqaS9KoOlapT9js2QIj3EnxMCI/7zTH4flZQ42IAwwbWiriQJMtOCp/S0uG9AAz/j1lKA05LBd4W8vDaDXpn03aBe24SCnTlv4xkxDKxvMGsYzvWpuJ/JYkXeeqVDajPiU99iPAIIR9G8Hpy7ZyadvieIJsZ1rcSc6y90FqEB+pRajqTenwlw//ZVRsKtmJEYjIMUOG55IWAsof1k27CSv4AEhS8AmtyrbBWq1qWI5WfRrLUe2s4kZ0LY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <B01709FCC9B4A04F8EB32C3BB85A454D@eurprd01.prod.exchangelabs.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: warwick.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 75c7c153-f214-43bf-6b84-08d80c667cf8
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 11:15:59.4688 (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: cX1HwNp2NjE+USmgc3CLkNkPleXzrRMRD/yosABuEWLUBBeHLIg8pwu3tMDr/DZBqNCt6YQWUJhM5VZJrPhCyc8QztmtlSqeqSSVeMsjBpM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB4846
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6EzB_NkAEVsCw7Qq4818zq6cSeg>
Subject: Re: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 11:16:07 -0000

Dear Bjorn (and CFRG),

I hope you are all well.

I raised one question about CPace during the selection process, however I don't think it has been properly addressed. Also I don't know whether the selection panel have actually taken this into account. Given that the selection process has finished and that CPace will likely be fielded, I feel we (everyone on CRFG) still have the responsibility to make sure all the technical claims in CPace are accurate and that the protocol can indeed be implemented securely and efficiently.

CPace modifies SPEKE by adding a random string (session ID) in the first flow. It claims to be one-round and UC-Secure.

However, the design of CPace is based on an "unusual" assumption: namely, each party should know the shared password and the other party's identity even before any communication in key exchange takes place. I say this is "unusual" as no other PAKE protocols make the same assumption, as far as I can tell. 

The "standard" assumption (e.g., as defined in ISO/IEC 11770-4) in PAKE is that a user only needs to memorize a shared password. The identities are established in-flow as part of the key exchange process and are verified based on the equality of the two passwords supplied by the two parties. This is reflected in all the PAKE designs that I know - but with exception of CPace.

One implication for the "unusual" assumption in CPace is that now a user not only needs to memorize a password, but also memorize the other party's "exact" identity which is to going to be used in the key exchange. However, when a key exchange session fails, it's simply impossible to distinguish whether the failure is due to the use of the wrong password or the user mis-remembering the other party's identity. This will impose severe difficulties in the implementation, e.g., defending against online dictionary attacks.
 
The other issue I raised in the earlier discussion in this list is that from the protocol design perspective, CPace is under-specified: there is no specification in the discrete logarithm setting, and several critical efficiency/security questions have been abstracted away by the idealization of hash-to-curve (which is yet to be established). 

Best regards,
Feng