Re: [Cfrg] CPACE: what the "session id" is for?

Björn Haase <bjoern.m.haase@web.de> Fri, 19 June 2020 23:18 UTC

Return-Path: <bjoern.m.haase@web.de>
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 1AFEF3A0F2B for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 16:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
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 6es0G7YQPBtU for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 16:18:01 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) (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 54A463A0F29 for <cfrg@irtf.org>; Fri, 19 Jun 2020 16:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1592608679; bh=BJsO5W6gGgRQL3wkDXFUmnj+Z9MMJtvlC8ZQzctRKrQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=C1Dw9FvnvEdTpRXmQfl3AhFXulDceNeECHojeZGfXRWrwn78MvTkbUAGmPH9hB8Ss nbRgV6CAHfzuFMea27mboNgiPXIJeN5wSjCahLYWrPQnpJ8wklbPwiYy9XQHvvUyIE W81HrWjBWqyUdGg06X4f+5y04Cm9mmXicCD9IIC8=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [192.168.2.133] ([188.110.241.197]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MXGOI-1jNewr0Vvq-00YfL2 for <cfrg@irtf.org>; Sat, 20 Jun 2020 01:17:59 +0200
To: cfrg@irtf.org
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr> <AM0PR05MB4786FCB65F850DD7C6528CBE83980@AM0PR05MB4786.eurprd05.prod.outlook.com> <573119cc053b78d7878f42918b38d5c1b499b213.camel@loup-vaillant.fr>
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <bjoern.m.haase@web.de>
Message-ID: <4bdcfd27-6ec4-2aaa-a687-47854a162424@web.de>
Date: Sat, 20 Jun 2020 01:17:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <573119cc053b78d7878f42918b38d5c1b499b213.camel@loup-vaillant.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:Idom3sGEeFf2qklwbUqBPZYnq0Hu/0IwaZCyN77hChNHsuq/gdE oNoMK0LGzionBY9drA8dhYKpQwk8UK1xuYPee51MW+3aogYlLFibHjXKGY5yTSoUaBv+Tr4 RS9CK7ah4rVCkJtctGUTlhSvPooOC55fUJJus8DL8N80i08Co5BVzINKI+dCyDGszQlVBtl k0KheOL+uBoitzEjmXCDg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:JYukMTCbRQ8=:SssCesD7REYIL/fbVsGhCO u2RRIew7IDIlB5Kz3fEdMH2hT2CZ6CiLmiUg9+xwxOI+3JTgnuUECzYbobv74YBWvdozEKyne LUI8pGXyBdttEFvcQqecHCqCE/vc7pNCwzB9+mLuuDpyQvYkd6RoN4R5+ZwdF+qDCXyslmB0i 0ovOH9zTRwnSJOjk1yQRreFmDZHWJ11KRDwBpwcyYUQb6ch8Oa0i/10PqMCO4CErSNOm7HSWZ F0r3hr1SOTfcEkFtTMc9ado9dLhUgturZQw4IKGXxii9ahaiNgUtxlCmmsXuU/PWy9QJr3MdX rGbG8BkVOlXv52ffyT0FEz4EQoGQJs7Ac04q95bgxaIxa/oym4pH+U61uNA6Q3pUxRgylmgjK P1v+oFt7Fg30Co1OmNMciIcyE5cCUJiIiEVN7IRBfPOBtYywSevV/KTwHxUrl+jj4EfKas4mp QMWO/hPoU2LSr42aelKvzlYQ8vrMcSq/Jgq3zEdLl0F+9LNsYNZQpz/j3aQjis1ALTQCUwaPz lXb1uTZM0ZoqfIO8IvzB3nypL2WgMmqIkk4QBgs8q7iocJ1BpXGtZjn76gAi5/w2Nccf8ZEMX m5EiGqDe1x2FCYHdKSiN4iBxdNhep5t3NBIdoiIxhC8kX7VWJkfGVCHNfR0mrF9//XCbeWUe+ p+pTB+ByznyulnV42BJ34HdZIOcUSP5eVTt705cDqKKbbT3ICf+c8urt7gC7f/T/J0vAxbSXW lCO1P24ir6I+Dru2lkq4XGyJPdxRJg6envLR4tvhn/q2W60GFNZHUKiyN6BVr3mKHFvmY5x6Q esyz/XekV9/uw1A2o/sqn9v2kEDPF2Vj08IUSwH4DqAsGFYo4qCqF504fR5b3UT+wBGDOFxJ7 /T4mkr1sEhIbeja9U6/+FOrd0DqXQUeJyi/r+kHJfBLXmtfXY7q3dNMjNJcs44uz+BDsR52oF rNHiddk6WKOnxqBgDRiHXFFKQ+OCzEEh6NLnMdfS5gTE1BxkKr/GkGed4LMrWC1a6U3gP2wCj bJ3aECDQnLBmXgnVuf7WO+q3nTj4GIW+pr54sGO/OU96Yszur/99XlDVzGLWmzHVphTJiHUIZ M9NVDH0RC9zEUoqfBF7Ki8kOBFsW9EIWn+H2rox7bvjXWS1uY15uLD5EocvjKIhGQGQ9S31iC Y9MNfCp4OkUWt4LU8vJboMp/1svmJKpLpkOq9tEn3A5SX6GF4ToJhA3OcTLNXYEBN+3PMHBzt EwDnaINmtrKvMsnlC
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZVCzQrDg-ytBK1QSBBw6JjtYIxg>
Subject: Re: [Cfrg] CPACE: what the "session id" is for?
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: Fri, 19 Jun 2020 23:18:03 -0000

Dear Loup,

 >The current draft does not match those slides. The slides says *both*

Yes. This is a change that came in in the final round of the selection
process after the feedback of Ran Canetti on this list regarding the sid
and the reviewers, together with the added full communication transcript.

> The parties should transmit a random string, and the sid is then a hash of
> the two (or, if sid is always the input of a hash, they may be just
> concatenated together?). The draft instead says:
>
> """ If no such ssid is available from a higher-level protocol, a
> """ suitable approach is including ssid in the first message from B to
> """ A as shown in the figure below.
>
> That may not be what you intended: with that method, the client is free
> to repeat the sid, and the generator would now be only as ephemeral as
> the x/X key pair.
>
> If I may, the server *can* contribute to the sid without increasing the
> number of messages:
>
>      Client sends Csid, name, U
>      Server sends Ssid, salt/UQ, X, sigma, Ya
>
>      sid = H(Csid || Ssid)  -- safe
>      sid =   Csid || Ssid   -- maybe that would work too?
>
> Maybe for the next draft?

Yes, I am aware of this and this approach works for the AuCPace case and
what you describe is also what I had in mind when writing the slides of
the TCHES talk. I did focus on the full AuCPace there.

Unfortunately, this does not work as nicely for CPace, where the sid is
already required for the initiator's message.

It is true that if the CPace sid is chosen by the initiator alone, the
same generator could be re-used in several sessions. This aspect causes
a situation where we need to consider possible simulation problems in
the proof. Simulation would fail if the simulator needs to program the
RO to some specified value for an input that has previously been queried
in a different session. Fortunately, this problem does not show up in
the hash query H_1 of CPace where no such re-programming conflict
occurs. We could safely re-use the previously programmed value in later
sessions in the simulator. So this is not an issue for the security
proof, at least for a single-session setting.  Still after discussion
with others with more knowledge on UC than me, I think that this
"sid"-re-use aspect might generate some problems for a rigid proof for
*composability* in the joint-state setting. I believe that for CPace
with a single-side-generated sid, the UC security guarantees might not
rigidly cover composability (at least not without adaptions to the
model), so that the security guarantees fall back to a level comparable
to what one gets from the game-based models.

Note, however that for the setting where the sid is generated by one
side only, it is also very helpful to have the full transcript included
in the final hash. Having the transcript included makes sure that
re-programming problems for the simulator regarding the hash used for
the final session key could be ruled out (because ephemeral data from
both sides is included in form of Ya and Yb).

Yours,

Björn