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

Björn Haase <bjoern.haase@endress.com> Fri, 19 June 2020 17:13 UTC

Return-Path: <bjoern.haase@endress.com>
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 50FCC3A0C9C for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 10:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, 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=c6JPABqH; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=qbdtTHvs
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 qhGktw71AyYh for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 10:13:56 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50067.outbound.protection.outlook.com [40.107.5.67]) (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 BC21D3A0C98 for <cfrg@irtf.org>; Fri, 19 Jun 2020 10:13:55 -0700 (PDT)
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=IFpzbmVoEqKXICm61ALXlG3WrbtHyLv7YmQbQhRLkEc=; b=c6JPABqH/Kx7btLOgZ/xLWOEd/LEORGfWdgj1zLrNF9XwVGSYqjOBqOB7l5EBoPTXgL8FS/KOiRFsMyCR+cfHKMhjqfDEt7DE4LWKI+9JGS+nA4wg+lL+IqVkJRJFo6iRH/2Ntz9SEksdaMQVKtCyh8mMOIgzV7HyfTOF15xxFs=
Received: from AM6P193CA0075.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::16) by VI1PR05MB7038.eurprd05.prod.outlook.com (2603:10a6:800:179::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Fri, 19 Jun 2020 17:13:53 +0000
Received: from AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:88:cafe::4d) by AM6P193CA0075.outlook.office365.com (2603:10a6:209:88::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Fri, 19 Jun 2020 17:13:53 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 13.79.242.66) 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 13.79.242.66 as permitted sender) receiver=protection.outlook.com; client-ip=13.79.242.66; helo=iqsuite.endress.com;
Received: from iqsuite.endress.com (13.79.242.66) by AM5EUR03FT029.mail.protection.outlook.com (10.152.16.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 17:13:52 +0000
Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Fri, 19 Jun 2020 19:13:52 +0200
Received: from EUR05-DB8-obe.outbound.protection.outlook.com ([104.47.17.112]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 19 Jun 2020 19:13:51 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XhDe7B8mJI+FcwIAE0Vyhet2L2uKjXQYqKDvYljqfwCohChpzMDHZuVARullZ9bhmi72VUXoCgTWsBp+VCp5wstFaVrgqwG95/XDtSEqCEZwLYyH4Ew8QfyoPYNZLVhPMa48AqAN7OM7CdBJA8KfTRvDOj+huFa8SdQKzX7KW6YYzaIGBwJgCkD9RT/8hUDqNKOtaslscvbof7s58l28xclfK8C/HtSRf6/7Z4Pc0SVlKyg3ycvYw/Q0vLXvdTxsTLn1wpbOqelFpFpZ0eVipdZtd/wZBopoFgML4asmDT1cyL1Yde5xVCZcXPcPNXweBWUmJpJPIReZxqInDQ0EyA==
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=CzE2wZ189OZ9J3AlciwHvxRVNajEF9SthFl0qy0gdMA=; b=knWNy+jud6MGueWqwlj5QNagXXwP5GiB1dHlQXah+a+SFDBQL4QJqWfi4fDOCKihvT+cHnuD0qIAQWjezrJpF424qLUm03Hv69szG2yc3YoM6DUWHCzuTv/OKKNYp34pHmHHdFBAsaX28B+85Yf01XeNxTPDezIDWL3Mr+gJ3B5ezbCb/B/pEGFh0weWG2T8YTatz/LGXL6s0sg1NI8suo6vxF6v7loXsD7+U71JXPK+v1FGJ3sMDaIz+1qEKXm59gbznEZcRd7/TqEIDLmc9gKrCt7oVVXe4AqBbUbVBYc7SJwCTyvnu0ndwm/A/LQxItpz5hSLWoJO7tpxLqB3Hg==
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=CzE2wZ189OZ9J3AlciwHvxRVNajEF9SthFl0qy0gdMA=; b=qbdtTHvsgyOExj3hDiWykAlIPvVPN9ce9zIgAQgBdEQKx/5uj+WjG4Hs23zpzuIu32r6KblutE82PeG3QsVZXbXAhZ7mDnHIzlPny0oIusjvi/Vl9p8jR97RzXKbErmyurW9up6ONR1SaEFzqZMSLO7OpXxZ6p3eymK7kIoVdhM=
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com (2603:10a6:208:b3::15) by AM0PR05MB6836.eurprd05.prod.outlook.com (2603:10a6:20b:144::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 17:13:50 +0000
Received: from AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::e00a:324b:e95c:750f]) by AM0PR05MB4786.eurprd05.prod.outlook.com ([fe80::e00a:324b:e95c:750f%7]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 17:13:50 +0000
From: =?Windows-1252?Q?Bj=F6rn_Haase?= <bjoern.haase@endress.com>
To: Loup Vaillant-David <loup@loup-vaillant.fr>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] CPACE: what the "session id" is for?
Thread-Index: AQHWRldqf1ZKJIwL3E6NfLYSleDQh6jgI08Q
Content-Class:
Date: Fri, 19 Jun 2020 17:13:50 +0000
Message-ID: <AM0PR05MB4786FCB65F850DD7C6528CBE83980@AM0PR05MB4786.eurprd05.prod.outlook.com>
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr>
In-Reply-To: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr>
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-06-19T17:13:48.8450238Z; 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=de373095-324b-4423-877d-ce1a86c72c06; MSIP_Label_2988f0a4-524a-45f2-829d-417725fa4957_Extended_MSFT_Method=Automatic
Authentication-Results-Original: loup-vaillant.fr; dkim=none (message not signed) header.d=none;loup-vaillant.fr; dmarc=none action=none header.from=endress.com;
x-originating-ip: [165.225.72.54]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-Correlation-Id: 3dd64ceb-a5ef-4656-f005-08d814742431
x-ms-traffictypediagnostic: AM0PR05MB6836:|VI1PR05MB7038:
X-Microsoft-Antispam-PRVS: <VI1PR05MB7038197248D037274C90BAF983980@VI1PR05MB7038.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0439571D1D
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: YKW/rwpUHpQNPqHLhPdqdnc3jy5TH+o+Bo0+krVpV9PlmWofkItYnjptw0U3chsvL6G3bdP3jBJAaF5QCUl6gAcYl7V2BViJO3VgDT4qTLE2ulvVPxzT+xo0u1ir/NlzPrRtexVKdKr8IJYgCowC3EaUe/857FiGLp47rPifp26b+I7L7+TCuvNR3cFcGs8spjBzc9aPpSCedl2upUCl/5fMzavVKbNNnYmTQl2CpMa+1amMsKewvyw8+cbXnAZiPEpKCNCTV1kxdxcLJfmg+KNcOYz619Evo/aqaZTGtsUQ9NxE/fBZ8EMwmsjwwSnx1XMY9UBRBCRX1TcgkS9pAP3m9Dp0F6l6lXm1c06NCDAcWtcxfoWh4C45enQy+o1E+W1Rhq+vKsivi2Tb1esQHw==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR05MB4786.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(39860400002)(376002)(396003)(136003)(83380400001)(478600001)(9686003)(76116006)(7696005)(66946007)(45080400002)(5660300002)(110136005)(66556008)(66446008)(64756008)(66476007)(6506007)(86362001)(316002)(55236004)(52536014)(66574015)(186003)(55016002)(26005)(8676002)(71200400001)(33656002)(2906002)(8936002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: bzwGyk/NCDamUvQOUfGwMCKpdRKAttnOg0/2KjAapdgFgl9bDM4Bgll+UYlyXYOHt861snCfQ2PeK04rr6/QSdzh+P0oecKwe3OtEf2SXjbTON+ZZl8YBDyu3Q8qvrpqMtsacxN2WaJcJMfKLVhvxveQyeb8trdKHksCMI7Oc5ZKby2Zo4SIFmttXvxLgbZXpGpOshfaFM7l5Cg5Vt/qXCdJ6XAjOyiT62mev+GJJToPjndGS0J+LWUJF0qrmjBroeepU9k1KAty9C3vmIhhUTKvVFmCIp5XpJyNVAP1gH7g2Vyx0EP4DSR7LO1dZjDk1YNltcZDQOtF4xrhiWoI9mQhIZTBszFXIkiv1kl6J46zlY3BeH6mod9mExJyTWSk+6xU3AaqADSrWiPnmNGY0HDGDD3rPM7DUcT2OdlLYJ7mLny6f99uaNe4gZmdqP0Gahh6KqQLRP+VhrM1tD11nj4N4jI2LkIEdPVPz333NY8=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB6836
X-OriginalArrivalTime: 19 Jun 2020 17:13:51.0600 (UTC) FILETIME=[00F57F00:01D6465D]
X-Trailer: 1
X-GBS-PROC: OT+CgPIUXq1iEofT1igind7ga+SFBCwY4uZmv7Tqen4=
X-GRP-TAN: IQNE02@8B2324613FA84FF9B34DF9151E6F027F
X-iqsuite-process: processed
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:13.79.242.66; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:iqsuite.endress.com; PTR:InfoDomainNonexistent; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(46966005)(33656002)(8936002)(7696005)(8676002)(45080400002)(966005)(110136005)(83380400001)(86362001)(478600001)(55016002)(2906002)(316002)(15974865002)(52536014)(26005)(186003)(5660300002)(70206006)(336012)(47076004)(356005)(70586007)(6506007)(82740400003)(81166007)(66574015)(82310400002)(9686003); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 508a8793-e4ca-463f-6d61-08d8147422e2
X-Forefront-PRVS: 0439571D1D
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: xYus1le7M20p2fnl/+YO/zAloLsLwRBBzHMPA73fgAeQdNi1CaB5NRhFomKlasu/CV67XqT28AeZ2UccbPxyxcIMPdoiPpjSY2dtxiFoplJ3KrKVWSf3cf86tXXCZ+cYNxoiI5+EfeGHHbymA6JDnGgtfuT/WG1aG3/J4hSPpA47zKuHPK+tAzrjizh33qN/npPaEJNpNt+t23gmw0/Fr09jZfXxSfpVlB0S1eavSI6YAUWLMR96pIxrritZR/xQrhwUJYQ+WE35gLQtoPCrTUgiuufCaUh1BR6+LxujrefKquapM3aGtKZx4IO3WW7VuE/5aHsy8hFeEtiFvHoToMkttBCF8549xfVE0MxaIwCNrHOcLLBsPBRJBJkT3nikOSSWygXoCAV12gTbwJRFw1f/EKrid5kLVkZyG3XJ34sP4YEDbUvo1+N+7UANzYsov3oX0xew1qcWP3bDcyueXX37YstST3K4k/jyGLSSbV8=
X-OriginatorOrg: endress.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2020 17:13:52.8359 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3dd64ceb-a5ef-4656-f005-08d814742431
X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[13.79.242.66]; Helo=[iqsuite.endress.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB7038
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/FbP1olNDg7JX8qwinY7MfT75HOw>
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 17:13:58 -0000

Dear Loup,

This is a good question. 

The sid originally came into the design of CPace as sort of an "artifact" and as a consequence of the security analysis in the UC framework, which requires that each independent session.is given a unique session id prior to the protocol start. An analysis in the game-based models such as FTG or ROR would not have required the nonce value.

In my analysis and after discussions with Ralf Küster's group prepending a nonce to hash inputs is important in order to get UC composability guarantees if a global single hash function is to be used, since we really need to avoid any form of "shared state" between different concurrent sessions.

Still IMO, the nonce should not be considered solely as an technicality and artifact of the proof strategy but also as an advantage and security feature.

If one composes a larger protocol which uses CPace as a substep, it needs to provide its sid value to CPace in the course of the composition and make sure that any output that is generated here will be tied to this session id. Any output of a possibly concurrently running other CPace session could not provide any valuable input to the attacker. For such a composed security protocol, the sid could be considered as to form some sort of "glue" linking the individual subblocks of the composed protocol (as e.g. used in AuCPace). 

In my opinion this could be of real-world use when designing APIs for security functionality that is internally composed together by using different subparts, such as suggested by Ran Canetti in https://mailarchive.ietf.org/arch/msg/cfrg/PBMlEarxjp5l1EPfTYamE3Y_0g4/ . 

The sid also serves for making each generator ephemeral for each session and this could be useful for mitigating side-channel analysis since the adversary has essentially only one single trace available. This "ephemeral generator G" feature that comes with the inclusion of the sid is IMO also relevant for the "quantum annoying" property.

There has also be a related post on this list https://mailarchive.ietf.org/arch/msg/cfrg/fgwMYLfaa1ZbF_UgKcurse211KE/ by Ran Canetti.

I have also tried to discuss this topic roughly in slides #53 to #58 in

https://ches.iacr.org/2019/src/slides/Day3/Session13_IOTSec/Paper2_Session13_Presentation_AuCPace_CHES2019.pdf

Your question moreover has been an important topic that Michel Abdalla and Manuel have been discussing last week regarding the security proofs. In the process of the finalization of the proceedings version of their paper https://eprint.iacr.org/2020/320 , they had the plan to discuss this topic more in depth in the text and with their co-authors.

>From this discussion with Michel and Manuel I took with me that we three agreed on the assessment that for UC composability in the Joint-State setting (and a global hash function as RO is some sort of joint state) a nonce value needs to be involved in each hash operation and, thus, also in the calculation of the generator for CPace (and TBPEKE). If I understood correctly, this was also some aspect that they planned to consider in the re-work of their Annex B regarding the TBPEKE proof (which is except for the mapping almost exactly like CPace).

For this reason, I think that it is a good idea to keep the "sid" and not purely some artifact from the proof approach.

Yours,

Björn.







Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

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önlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss 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.
 


-----Ursprüngliche Nachricht-----
Von: Cfrg <cfrg-bounces@irtf.org> Im Auftrag von Loup Vaillant-David
Gesendet: Freitag, 19. Juni 2020 18:33
An: cfrg@irtf.org
Betreff: [Cfrg] CPACE: what the "session id" is for?

>From the latest draft:

  https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-haase-cpace-01&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C919f03384285480aff6e08d8146e8b15%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637281812313363894&amp;sdata=WU6zi7uD9S6%2F9RjhsQBhfKMl6ylHH%2FS58G6rDLMQkyQ%3D&amp;reserved=0

""" Let sid be a session id byte string chosen for each protocol
""" session before protocol execution; The length len(sid) SHOULD be
""" larger or equal to 16 bytes.

""" It is RECOMMENDED sid, is generated by sampling ephemeral random
""" strings.

Unlike ZPAD, The draft doesn't explain this recommendation.
What problem may occur if we omit sid altogether?

Even if G ends up being reused across several sessions, I don't believe
there's any way to tell, because Ya and Yb are uniformly distributed if
ya and yb are indeed random. I feel like I'm missing something.

Loup.


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C919f03384285480aff6e08d8146e8b15%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637281812313363894&amp;sdata=CNbRgqbWTz%2BbifiT%2FvhFv76Z6Yejo0CfTl2gpxV0oQc%3D&amp;reserved=0