From nobody Fri Aug 19 12:58:23 2022 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28616C14F723; Fri, 19 Aug 2022 12:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz5TEUIHaKVQ; Fri, 19 Aug 2022 12:58:20 -0700 (PDT) Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 3AE05C157908; Fri, 19 Aug 2022 12:57:43 -0700 (PDT) Received: from LLEX2019-2.mitll.ad.local (llex2019-2.llan.ll.mit.edu [172.25.4.124]) by MX2.LL.MIT.EDU (8.17.1.5/8.17.1.5) with ESMTPS id 27JJvTu4037070 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Aug 2022 15:57:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=m/GUthMUDsMpcjyqcgpFJZe7wZXP0GqFSJscjet9SEZ4ZYVUIuOcvdhvpyTxPhPtDorBDaQ1tfAzkAamyJ6DudfsjBJ580gPJ+uT5fXWYDrbQOpBYjbpWJW5P4OYtvIUbWwdhT+7dPAONns9mrmtgFSMwq3m7b3Kxoibw5MVWUGfpnfOvabwclKZhVpLHMOy0+gXn+QeaShVymJNTbJJEmJqkqV3jHSvbi4crHZZgUSpzXn6Nu8G2IrJE3J1RmPYXa9xkbIlO2mXEE7A4qovmJ9XODuneDutXiyhqkATzO3YChYOhIgPzfZThMi//HmBZy9C/NnI/8MF+YJPjqwyeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ce6XxeduALehzaIhSJXr/m3qFmYzTEUVdYzDUKOlrFg=; b=emx8kM319zd+2AnWebAY8mUOSM44+AKk/62qEi/r1G/YaByOym1d+BfIlbKYFAD29T8sRuknsJV8jcKARU0mW4HLMVGGi3a6FaJLpXtoHzd+pTTyt7OhJzkwcuPdgOw3LsVgQaepQTjKE/g515pOUd6wvJxb8iUPFZjbWiN2Ax77Tio9TgWdcNEzBjZ6mrimEMJttXxiPojhhIL1nJCVolbhUD6rRnw7MGBEiGCIG5vd/4B/Aob+m27INIowhM3aUPFeId6d+y/0Q5Nt7InGzHIHbQm4TgbDh+We9qi8mCOXiMP7twFmQVFql6jaNfPlag0UbaSWyCk1Q8LMLWp/tw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Phillip Hallam-Baker , Mike Ounsworth CC: LAMPS , "cfrg@irtf.org" Thread-Topic: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon? Thread-Index: AdiyWmrrCCvkDLBiTn2DcOMWvaOQ/gABb6NQAAQ+JgAAE/kJgAASGGSwABycwAAAHkI4AAADzCcA///AogA= Date: Fri, 19 Aug 2022 19:57:35 +0000 Message-ID: <0BF867D6-C4E0-4D9C-8B72-E1CE59308A6F@ll.mit.edu> References: <88358933-A540-4000-9C7D-D248F670122F@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.63.22070801 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de46bbdb-5b80-48aa-05cf-08da821d0fa9 x-ms-traffictypediagnostic: BN0P110MB1369:EE_ x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ekGTiw6Jy8uDq7IqyllJnX0Ipt1SSkh3wkIVyFd9L9DcwPYclbjHRzTvhVSOSZjcZT0hBvhIf39Iebny2t+stlXn9zLkkiCBWpDokoAfoRHHZDILyCE7+G6xSVgBE6jbKbBjzQtEXifodk0v3Ehg/aSSrstH5s4P0/4eB+5fjuMtdLu2Dm4w+VXuykMjKEjl+pug0v+UdjskvH7/VynJ/rCSSZNnH8Jf6I1lALyqgoTWiE1TX3r71QZLNJomjDdBYWtP1XAjoadvqb9aLlfBwtbCQhB2FrVOVsvCsL5a7UNexGRTZepuZg7zse+hSAbPK3cx4yswBtOXBmUI/txxAxWvVihg82Qdj2b/K30MNB6jV+I9HPjnk0+OEtUa4HXcLOMdLGItzc6nobiVk/nwbf2pf03SmvyzSG1ChthfJwtvINH+3SrPgK/DtGh9eYGBe1fctMaRlvL7UJGaTHLYTGHgfwM0AWl9W00NuIlmo4FPVM3UE8frfHclWHmvT8KKWW1V5S0EOVlWtyL83QN2S8H3/R50W/uvADRcFeDEQkT/AkbMXY2gm4nQRQwMLTW79SueKwbwppERM6vk2sNyJu3vWfo/dhnvoFzOTY+p9UJMfLvPtR7K2FUDjmyXYMMXLCCl/MxEDsvcbI6UclS6ZI170/h+m3aNar0ND3HjEhVOr11dpPkf9lVTtS2o8nWlCFWiwh6oqSI1uJbTxNkFZEirhdSh4eJ5hi0NDFebXC82Tc05z0Cx2cmINtfdQ3zP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(366004)(966005)(6486002)(71200400001)(498600001)(2906002)(33656002)(54906003)(38070700005)(86362001)(110136005)(75432002)(99936003)(2616005)(186003)(122000001)(166002)(6506007)(26005)(53546011)(6512007)(66574015)(66556008)(8936002)(66946007)(66446008)(76116006)(5660300002)(64756008)(4326008)(8676002)(66476007)(38100700002)(83380400001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: oo8EWJaIB3wAbWmzfNd2jkRTpYyfmESs1QX2rrOYyFrWrVkaW9UiQCNwY7CsW57c7OGIDiLfzVCkF7pFnrPfPhT+wu/5mOmKYO08ctQZLqxVN4hkIvDIWpPh6q3WpdlE923j4kURKtI/nVMR0ft1HvErZkvEQHZdw2yVvMN5OLh03BD9uzWz9L1BlEftUyH/+pYeHr72uWUNaazBxlxUt+zluN5hm5KEcOeWP3INf5mufWaUYZEBZwnxI2adNIMq4IfAvftYX0bs8mQxKHny2W/Pvsy50wbP6VTthCD/pPqYCjtm8nrA+fLkxRsYOtTxn9kcgRWpSs3QwI52j8FtZaRbgS3iKK2n9l0El5ewN6Xkk7hHtVjJQ/1XSDvW9IfP2u0cW+5+9DpEHsluwRw6dpeGPcOTWwFdODJ3bFCGT/c= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3743769454_1036189106" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: de46bbdb-5b80-48aa-05cf-08da821d0fa9 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2022 19:57:35.4119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1369 X-Proofpoint-ORIG-GUID: CMuE5I1-nbaq_qZhMA_3XeLkgZkfWBqr X-Proofpoint-GUID: CMuE5I1-nbaq_qZhMA_3XeLkgZkfWBqr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-19_11,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208190074 Archived-At: Subject: Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2022 19:58:22 -0000 --B_3743769454_1036189106 Content-type: multipart/alternative; boundary="B_3743769454_1786994517" --B_3743769454_1786994517 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Oh right. So far I am up the Kyber pass and have not done Dilithium yet. =20 Me too. =F0=9F=98=83=20 =20 this has the nice property that `r` is generated at signing time by the sig= ner. So should SHAKE develop a collision attack similar to the one we saw fo= r SHA1, then the collision pre-computation as still intractable for the atta= cker because the attacker cannot not know `r` in advance. (Disclaimer: I am = just an engineer trying to wrap my head around this, corrections welcome!). Meh, seems like an unnecessary concern. And I am not sure how this actually= helps against collision attacks in general. =20 It does help against collision attacks (not sure what you meant by =E2=80=9Cin ge= neral=E2=80=9D). But, as you said: =20 If SHAKE is broken, then we are going to have so many problems that the sec= urity of the signature algorithm is irrelevant. =20 I do not think SHAKE (or even SHA2) will be broken in the foreseeable futur= e, but indeed, in the (practically impossible, IMHO) case it is broken =E2=80=93 w= e=E2=80=99ll have many more problems than the signature algorithm security. =20 As a matter of protocol composition, the signature algorithm should not be = trying to fix a potential issue in the digest algorithm because things are g= oing to be breaking all over. So, the concern with hash-then-sign is that if `m` above is itself a messag= e digest, ie `m =3D SHA256(M)`, then you have un-done the collision resistance= that is built in to the Falcon primitive, essentially reducing the security= properties of Falcon. Adding the message digest to the signed content does = not help if the attacker is holding two messages with the same SHA256 hash. If this is a useful approach, then move it out of the signature primitive a= nd push it into the envelope format.=20 =20 It is a useful approach, and it probably does belong to the envelope. =20 TNX =20 From: Phillip Hallam-Baker =20 Sent: August 18, 2022 10:29 PM To: John Gray Cc: Tadahiko Ito ; Massimo, Jake ; Scott Fluhrer (sfluhrer) ; M= ike Ounsworth ; LAMPS ; cfrg@irt= f.org; pqc-forum ; Kampanakis, Panos ; sean@ssn3rd.com; bas@westerbaan.name Subject: Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-= then-sign with Dilithium and Falcon? =20 =20 =20 On Thu, Aug 18, 2022 at 11:29 AM John Gray wrote: Thanks Tadahiko, =20 I read through your paper, and it covers exactly the usability issues we ha= ve come across! We were wondering if it is possible to perform the specifi= c hashing external to the server (which could be an HSM as in your paper, or= timestamp server, etc). For example, for Dilithium the mu :=3D CRH( tr || M= ) and for Falcon it would be c <- HashToPoint(r || m, q, n). Your paper = answers that question, it can be done for Falcon, but not Dilithium (withou= t changing the signature output). So part of our question is whether using= a regular external Hash as we do today for RSA and ECDSA (and what you call= a boundary type B) somehow reduces the security and we shouldn=E2=80=99t recommen= d it. We are interested in this because we are looking at defining composi= te pairs or triples which combine existing signature algorithms like RSAWith= SHA256 and ECDSAWithSHA256 with Falcon or Dilithium. Having to change the= operational paradigm for an HSM or something like a timestamping server wou= ld result in large amounts of data having to be piped across the internet fo= r signatures (as you point out in your paper). =20 =20 For our composite signature use case it brings up similar questions. We c= an support a mode where external hashing is done once, and then individually= signed by the components (this makes it much more efficient) both internall= y and externally for the HSM, timestamping, code signing use-cases. Howeve= r, in the case of Dilithium there would need to be two signature modes Sig =3D= Dilithium (Message) and the other would be Sig =3D Dilithium ( HASH (Message)= ). I don=E2=80=99t think that is necessarily a bad thing as long as it is standa= rdized and secure. Alternatively, we could support independent hashing for= each component, but that gets strange if you are doing an external hash for= ECDSA, but then need to send the whole data for Dilithium. We would likel= y have to end up supporting sending the whole data if external hashing compr= omises security of the PQC composites, but then it is even more inefficient = as each component would need to hash independently. You also covers this = in section 4.3 your paper: =20 =E2=80=9CWe can construct type B cryptographic boundaries by adding one more hash= function before the execution of PQC=E2=80=99s signature generation algorithm=E2=80=A6 = This approach would improve the efficiency of lattice based digital signatur= e schemes deployed in HSM. It would have a greater impact on Dilithium, but = also be applicable to Falcon and other digital signature schemes. Two modes = of PQC algorithms utilizing this approach will be able to exist, namely, a P= QC algorithm without an additional hash (i.e. original PQC algorithm) and a = PQC algorithm with an additional hash. If there are two modes of a digital s= ignature scheme, then the asymmetric operation for those two modes must not = be identical. The reason is that, obtaining a signature from the mode with a= n additional hash function would help attackers who can attack another mode = which is without the additional hash function.=E2=80=9D =20 That is not a new issue and it is one that we discussed at great length for= RSA. The hash of the digest is part of the signature payload to prevent sub= stitution attacks. =20 I am finding the description of the problem here to be making assumptions a= bout what 'formal proofs' are demonstrating that are probably demonstrating = something else. If you assume there is only one true digest function, you 's= olve' the digest substitution problem by pretending it does not exist... =20 =20 In my view, the signature function should be over the payload and the addit= ional authenticated data. Whether this is the OID of the digest algorithm al= one or something more depends on the signature scheme. That is what JOSE etc= . have to sort out.=20 =20 Preventing a digest downgrade attack may be considered the concern of the c= ryptographic envelope format because there may be more than one form of down= grade attack to be considered. But it is also something we have traditionall= y included in the signature... =20 =20 Any email and files/attachments transmitted with it are confidential and ar= e intended solely for the use of the individual or entity to whom they are a= ddressed. If this message has been sent to you in error, you must not copy, = distribute or disclose of the information it contains. Please notify Entrust= immediately and delete the message from your system.=20 --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/CAMm%2BLwihTg8fC17SYLO-iPVj3ahxcaFBX-0mhtYZFMHkU_R= tCA%40mail.gmail.com. --B_3743769454_1786994517 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Oh right. So far I am= up the Kyber pass and have not done Dilithium yet.

 =

Me too. = 😃 <= /o:p>

 

this has the nice = property that `r` is generated at signing time by the signer. So should SHAK= E develop a collision attack similar to the one we saw for SHA1, then the co= llision pre-computation as still intractable for the attacker because the at= tacker cannot not know `r` in advance. (Disclaimer: I am just an engineer tr= ying to wrap my head around this, corrections welcome!).

Meh, seems like an unnecessary concern. = And I am not sure how this actually helps against collision attacks in gener= al.

<= o:p> 

It does help against collision attacks (not sure what = you meant by =E2=80=9Cin general=E2=80=9D). But, as you said:

 

If SHAKE is broken, then we are g= oing to have so many problems that the security of the signature algorithm i= s irrelevant.

 

I do not think SHAKE (or even SHA2) will be broken = in the foreseeable future, but indeed, in the (practically impossible, IMHO)= case it is broken =E2=80=93 we=E2=80=99ll have many more problems than the signature al= gorithm security.

 

As a matter of protocol composition, the signature algorithm shou= ld not be trying to fix a potential issue in the digest algorithm because th= ings are going to be breaking all over.

<= span style=3D'color:#7030A0'>So, the concer= n with hash-then-sign is that if `m` above is itself a message digest, ie `m= =3D SHA256(M)`, then you have un-done the collision resistance that is built = in to the Falcon primitive, essentially reducing the security properties of = Falcon. Adding the message digest to the signed content does not help if the= attacker is holding two messages with the same SHA256 hash.

If this is a useful approach, then m= ove it out of the signature primitive and push it into the envelope format. =

 <= /p>

It is<= /u> a useful approach, and it probably does belong to the envelope.

 

TNX

  

From: Phillip Hallam-Baker <phill@hallambaker.com>
S= ent: August 18, 2022 10:29 PM
To: John Gray <John.Gray=3D40entrust.com@dmar= c.ietf.org>
Cc: Tadahiko Ito <tadahiko.ito.public@gmail.com>; = Massimo, Jake <jakemas=3D40amazon.com@dmarc.ietf.org>; Scott Fluhrer (sfluhrer) <= ;sfluhrer@cisco.com&= gt;; Mike Ounsworth <Mike.Ounsworth@entrust.com>; LAMPS <spasm@ietf.org>; cfrg@irtf.org; pqc-forum <pqc-forum@list.nist.gov>; Kampanak= is, Panos <kpanos@amaz= on.com>; sean@ssn3rd= .com; bas@westerbaa= n.name
Subject: Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] = RE: Whether to hash-then-sign with Dilithium and Falcon?

 

<= span style=3D'font-size:12.0pt'> 

 

On Thu, Aug 1= 8, 2022 at 11:29 AM John Gray <John.Gray=3D40entrust.com@dmarc.ietf.org> wrote:

Thanks Tadahiko,

 

I rea= d through your paper, and it covers exactly the usability issues we have com= e across!   We were wondering if it is possible to perform the spe= cific hashing external to the server (which could be an HSM as in your paper= , or timestamp server, etc).   For example, for Dilithium the mu := =3D CRH( tr || M) and for Falcon it would be  c <- HashToPoint(r || m,= q, n).    Your paper answers that question, it can be done f= or Falcon, but  not Dilithium (without changing the signature output).&= nbsp;  So part of our question is whether using a regular external Hash= as we do today for RSA and ECDSA (and what you call a boundary type B) some= how reduces the security and we shouldn=E2=80=99t recommend it.   We are= interested in this because we are looking at defining composite pairs or tr= iples which combine existing signature algorithms like RSAWithSHA256 and ECD= SAWithSHA256 with Falcon or Dilithium.    Having to change th= e operational paradigm for an HSM or something like a timestamping server wo= uld result in large amounts of data having to be piped across the internet f= or signatures (as you point out in your paper).   

 

For our comp= osite signature use case it brings up similar questions.   We can = support a mode where external hashing is done once, and then individually si= gned by the components (this makes it much more efficient) both internally a= nd externally for the HSM, timestamping, code signing use-cases.  = However, in the case of Dilithium there would need to be two signature mode= s Sig =3D Dilithium (Message) and the other would be Sig =3D Dilithium ( HASH (M= essage)).   I don=E2=80=99t think that is necessarily a bad thing as lon= g as it is standardized and secure.   Alternatively, we could supp= ort independent hashing for each component, but that gets strange if you are= doing an external hash for ECDSA, but then need to send the whole data for = Dilithium.   We would likely have to end up supporting sending the= whole data if external hashing compromises security of the PQC composites, = but then it is even more inefficient as each component would need to hash in= dependently.    You also covers this in section 4.3 your pape= r:

 

= =E2=80=9CWe can construct type B cryptographic boundaries by adding one more hash = function before the execution of PQC=E2=80=99s signature generation algorithm=E2=80=A6 T= his approach would improve the efficiency of lattice based digital signature= schemes deployed in HSM. It would have a greater impact on Dilithium, but a= lso be applicable to Falcon and other digital signature schemes. Two modes o= f PQC algorithms utilizing this approach will be able to exist, namely, a PQ= C algorithm without an additional hash (i.e. original PQC algorithm) and a P= QC algorithm with an additional hash. If there are two modes of a digital si= gnature scheme, then the asymmetric operation for those two modes must not b= e identical. The reason is that, obtaining a signature from the mode with an= additional hash function would help attackers who can attack another mode w= hich is without the additional hash function.=E2=80=9D

<= /blockquote>

 

That is not a new issue and i= t is one that we discussed at great length for RSA. The hash of the digest i= s part of the signature payload to prevent substitution attacks.=

 = ;

I am finding the description of the problem here to be making assump= tions about what 'formal proofs' are demonstrating that are probably demonst= rating something else. If you assume there is only one true digest function,= you 'solve' the digest substitution problem by pretending it does not exist= ...

 

 

In my view, the signature function= should be over the payload and the additional authenticated data. Whether t= his is the OID of the digest algorithm alone or something more depends on th= e signature scheme. That is what JOSE etc. have to sort out. 

&nb= sp;

Preventing a digest downgrade attack may be considered the concern= of the cryptographic envelope format because there may be more than one for= m of downgrade attack to be considered. But it is also something we have tra= ditionally included in the signature...

 

 

Any email and files/attachments transmitted with it are confidential a= nd are intended solely for the use of the individual or entity to whom they = are addressed. If this message has been sent to you in error, you must not c= opy, distribute or disclose of the information it contains. Please notify= Entrust immediately and delete the message from your system. <= /o:p>

--
You received this message because you are subscribed to the G= oogle Groups "pqc-forum" group.
To unsubscribe from this group = and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To = view this discussion on the web visit https://gr= oups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwihTg8fC17SYLO-iPV= j3ahxcaFBX-0mhtYZFMHkU_RtCA%40mail.gmail.com.

--B_3743769454_1786994517-- --B_3743769454_1036189106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCB4DnBPxeWjTrpw90dHbo01DP2P76Mr4wFMjpdb qNxIdDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA4MTkx OTU3MzRaMA0GCSqGSIb3DQEBAQUABIIBAHqt51ZMc/aMxd7zcWugc0/YxbKjJt8E1ukRcX2y gSW96SN+F1pdhbKZFr4P5zSjAYlXmaX9UKGEv5f9PheqaziRKFPxJWt6MNoOpPW0boBz6vV5 ol4ejQhIOrRNoYOL50zfAemslXWsP3cz4QXfcPoL5IemzcSZfZ6UH3BJ92xVhWvkN23k0lY4 oHx4aHtOf3EMb+iITuv/d2JWb9+zxEGu0WEmJHdIKsMxwX3KpTKDnMASsJl+18PnNyQuxWoq DmQSbK/GXkt0ChitTgchVZ0Cei6BQkjZs6wWIop1ucuWsH65znKY2OIs7hWjKQ00KkDKk3nF lX8XNTUYWr/iS30= --B_3743769454_1036189106--