From nobody Mon Oct 5 01:04:01 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA653A0E21; Mon, 5 Oct 2020 01:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=2.331, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=st.com 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 9Xot1ydNK2OC; Mon, 5 Oct 2020 01:03:56 -0700 (PDT) Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (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 E77DC3A0EB7; Mon, 5 Oct 2020 01:03:28 -0700 (PDT) Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09581ctV005045; Mon, 5 Oct 2020 10:03:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=STMicroelectronics; bh=BcaNu8rNizykCKstN/wKGVNn7IOYo/rcuP7kQfmZ0rQ=; b=DYf3NDrguiM68y7LPbLHGgUMYsQQcSi7qHTFZR2cAzjPpDbqYR6xfRjBQitUMxwva52X 6b3ydLYX1YRS8IiOV7eybE+kfeYJp06BvbbX+QhFHgNi/VFNYQzxhhRLj7MHVZaR8x4Q xDI4AWBq7C1g7HBRaO3o6Wg053IRPLxiGFcmY4MnL6R7eML4VY1ZflGmX5BJrWy3RIGA TYKc+DpYt/Gkd7IQgbRaGefzzshPw0GF/GXloJnvWepfMXGiyy0DqVpalLQmK7pnj/0T oFwO0C8a+OG6uJ8BvkPnlegYoejnePm+9koHkTwNABAO7dVaG/l66C7vZ8yXRpUGlqil Vg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 33xg6g8uhv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Oct 2020 10:03:24 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 26A3610002A; Mon, 5 Oct 2020 10:03:23 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag6node1.st.com [10.75.127.16]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id EAB41212FA8; Mon, 5 Oct 2020 10:03:22 +0200 (CEST) Received: from SFHDAG6NODE2.st.com (10.75.127.17) by SFHDAG6NODE1.st.com (10.75.127.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Oct 2020 10:03:22 +0200 Received: from SFHDAG6NODE2.st.com ([fe80::a56f:c186:bab7:13d6]) by SFHDAG6NODE2.st.com ([fe80::a56f:c186:bab7:13d6%20]) with mapi id 15.00.1473.003; Mon, 5 Oct 2020 10:03:22 +0200 From: Gilles VAN ASSCHE To: Alexey Melnikov , Thomas Pornin , "crypto-panel@irtf.org" CC: =?utf-8?B?QmVub8OudCBWaWd1aWVy?= , "draft-irtf-cfrg-kangarootwelve@ietf.org" Thread-Topic: EXTERNAL: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-kangarootwelve-02 Thread-Index: AQHWgG6/n+64LNGupU6Cu86uX1Nc36lzIYsAgBW43XA= Date: Mon, 5 Oct 2020 08:03:22 +0000 Message-ID: <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> References: <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> In-Reply-To: <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> Accept-Language: en-US, fr-BE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.51] Content-Type: multipart/alternative; boundary="_000_619ed4c1210c4502802583e19c6f6c4bSFHDAG6NODE2stcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-05_06:2020-10-02, 2020-10-05 signatures=0 Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:03:59 -0000 --_000_619ed4c1210c4502802583e19c6f6c4bSFHDAG6NODE2stcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGV4ZXksDQoNClRoYW5rcyB0byBKZWFuLVBoaWxpcHBlIGFuZCBUaG9tYXMgZm9yIHRo ZWlyIGNvbW1lbnRzLg0KDQpXZSB0aGluayBhbGwgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3Nl ZC4gKE1heWJlLCBKZWFuLVBoaWxpcHBlIGNvdWxkIHlvdSBjb25maXJtPykgSWYgaW5kZWVkIHRo ZSBjYXNlLCBjYW4geW91IGhlbHAgdG8gbW92ZSB0aGUgZG9jdW1lbnQgZm9yd2FyZCA/DQoNClRo YW5rcyAmIGtpbmQgcmVnYXJkcywNCkJlbm/DrnQsIERhdmlkLCBHaWxsZXMsIEpvYW4gYW5kIFF1 eW5oDQoNCg0KRnJvbTogVGhvbWFzIFBvcm5pbiA8dGhvbWFzLnBvcm5pbkBuY2Nncm91cC5jb20+ DQpTZW50OiBNb25kYXksIDIxIFNlcHRlbWJlciAyMDIwIDE2OjE4DQpUbzogQmVub8OudCBWaWd1 aWVyIDxiLnZpZ3VpZXJAY3MucnUubmw+OyBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtv dkBpc29kZS5jb20+OyBkcmFmdC1pcnRmLWNmcmcta2FuZ2Fyb290d2VsdmVAaWV0Zi5vcmc7IGNy eXB0by1wYW5lbEBpcnRmLm9yZw0KU3ViamVjdDogUmU6IEVYVEVSTkFMOiBSZTogW0NyeXB0by1w YW5lbF0gUmVxdWVzdCBmb3IgcmV2aWV3OiBkcmFmdC1pcnRmLWNmcmcta2FuZ2Fyb290d2VsdmUt MDINCg0KSSBhbSBub3QgaW4gYSBnb29kIHBvc2l0aW9uIHRvIG1ha2UgY29tbWVudHMgb24gZGVs YXlzLCBzaW5jZSBJIGFsc28gbGV0IHRoaXMgZW1haWwgc2xlZXAgZm9yIHRocmVlIHdlZWtzLi4u DQoNCllvdXIgY2hhbmdlcyBsb29rIGdvb2QgdG8gbWUuDQoNCkkgbGlrZSB0aGUgaWRlYSB0aGF0 IHRoZSBidWxrIG9mIHRoZSBkYXRhIHByb2Nlc3NpbmcgaW4gSG9wTUFDIGhhcyBubyBkZXBlbmRl bmN5IG9uIHRoZSBrZXk7IGl0IGhhcyBpbmRlZWQgc3Ryb25nIGJlbmVmaXRzIHdpdGggcmVnYXJk IHRvIHNpZGUgY2hhbm5lbCBhdHRhY2tzLiBPZiBjb3Vyc2UsIGl0IHVuYXZvaWRhYmx5IGltcGxp ZXMgdGhhdCBIb3BNQUMgcmVsaWVzIG9uIHRoZSBjb2xsaXNpb24gcmVzaXN0YW5jZSBvZiB0aGUg a2V5bGVzcyBoYXNoIGZ1bmN0aW9uLiBJbiB0aGUgYWZ0ZXJtYXRoIG9mIHRoZSBNRDUgYW5kIFNI QS0xIGF0dGFja3MgKGluIHRoZSAyMDAwcyksIHRoZXJlIGhhcyBiZWVuIGEgdHJlbmQgb2Ygc2h1 bm5pbmcgY29sbGlzaW9uIHJlc2lzdGFuY2UsIGFuZCBpbnNpc3Rpbmcgb24gdXNpbmcgb25seSAo c2Vjb25kLSlwcmVpbWFnZSByZXNpc3RhbmNlOyB0aGF0J3MgaG93LCBmb3IgaW5zdGFuY2UsIEVk MjU1MTkgc2lnbmF0dXJlcyBpbiAicHVyZSIgbW9kZSBpbnNpc3Qgb24gZ2VuZXJhdGluZyB0aGUg Y2hhbGxlbmdlIGFzIEgocGtleStSK21lc3NhZ2UpIGFuZCBub3QgSChwa2V5K1IrSChtZXNzYWdl KSkuIFRoaXMgdHJlbmQgaW1wbGllcyBzb21lIHByYWN0aWNhbCBsaW1pdGF0aW9ucyAoZS5nLiAi cHVyZSIgRWQyNTUxOSBzaWduYXR1cmVzIG1ha2UgaXQgbXVjaCBtb3JlIGRpZmZpY3VsdCB0byBw cm9jZXNzIFguNTA5IGNlcnRpZmljYXRlcyBpbiBtZW1vcnktY29uc3RyYWluZWQgZW52aXJvbm1l bnRzKS4gSSB0aGluayB5b3VyIGNob2ljZSBpbiBIb3BNQUMgaXMgYSBiZXR0ZXIgdHJhZGUtb2Zm OyBrZXlsZXNzIHByb2Nlc3Npbmcgb2YgdGhlIGJ1bGsgb2YgdGhlIGRhdGEgaGFzIHRhbmdpYmxl IHByYWN0aWNhbCBiZW5lZml0cywgYW5kIGlmIEsxMiBpcyBub3QgY29sbGlzaW9uLXJlc2lzdGFu dCB0aGVuIHRoZSBmb3VuZGF0aW9uIG9mIGl0cyBvdGhlciBzZWN1cml0eSBwcm9wZXJ0aWVzIGJl Y29tZXMgcXVpdGUgZmxha3kuDQoNClRob21hcw0KDQpGcm9tOiBCZW5vw650IFZpZ3VpZXIgPGIu dmlndWllckBjcy5ydS5ubDxtYWlsdG86Yi52aWd1aWVyQGNzLnJ1Lm5sPj4NCkRhdGU6IFR1ZXNk YXksIFNlcHRlbWJlciAxLCAyMDIwIGF0IDEwOjM4DQpUbzogVGhvbWFzIFBvcm5pbiA8dGhvbWFz LnBvcm5pbkBuY2Nncm91cC5jb208bWFpbHRvOnRob21hcy5wb3JuaW5AbmNjZ3JvdXAuY29tPj4s IEFsZXhleSBNZWxuaWtvdiA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbTxtYWlsdG86YWxleGV5 Lm1lbG5pa292QGlzb2RlLmNvbT4+LCAiZHJhZnQtaXJ0Zi1jZnJnLWthbmdhcm9vdHdlbHZlQGll dGYub3JnPG1haWx0bzpkcmFmdC1pcnRmLWNmcmcta2FuZ2Fyb290d2VsdmVAaWV0Zi5vcmc+IiA8 ZHJhZnQtaXJ0Zi1jZnJnLWthbmdhcm9vdHdlbHZlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pcnRm LWNmcmcta2FuZ2Fyb290d2VsdmVAaWV0Zi5vcmc+PiwgImNyeXB0by1wYW5lbEBpcnRmLm9yZzxt YWlsdG86Y3J5cHRvLXBhbmVsQGlydGYub3JnPiIgPGNyeXB0by1wYW5lbEBpcnRmLm9yZzxtYWls dG86Y3J5cHRvLXBhbmVsQGlydGYub3JnPj4NClN1YmplY3Q6IFJlOiBFWFRFUk5BTDogUmU6IFtD cnlwdG8tcGFuZWxdIFJlcXVlc3QgZm9yIHJldmlldzogZHJhZnQtaXJ0Zi1jZnJnLWthbmdhcm9v dHdlbHZlLTAyDQoNCkRlYXIgVGhvbWFzLCBEZWFyIEFsZXhleSwgRGVhciBDcnlwdG8gUGFuZWwg bWVtYmVycywNCg0KV2Ugd291bGQgbGlrZSB0byB0aGFuayB5b3UgZm9yIHlvdXIgdGltZSBpbnRv IHJldmlld2luZyBvdXIgZHJhZnQNCmFuZCBwcm92aWRpbmcgdXMgd2l0aCB5b3VyIGNvbnN0cnVj dGl2ZSBjb21tZW50cy4NCg0KV2UgYXBvbG9naXplIGZvciB0aGUgZGVsYXlzIChjb3JvbmEgJiB2 YWNhdGlvbnMuLi4pIGFuZCBwcm92aWRlIHlvdSBoZXJlIHdpdGgNCm91ciBtb2RpZmljYXRpb25z IHRvIHRoZSBkcmFmdDogaHR0cHM6Ly9naXRodWIuY29tL2NmcmcvZHJhZnQtaXJ0Zi1jZnJnLWth bmdhcm9vdHdlbHZlL2NvbW1pdC83MGVmZjQyM2FhNTdlOWUzNDEyMTk1MWRhMjc2NGI1ZWQ3M2Rm OTg4PGh0dHBzOi8vZ2JyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjZnJnJTJGZHJhZnQtaXJ0Zi1jZnJnLWthbmdhcm9v dHdlbHZlJTJGY29tbWl0JTJGNzBlZmY0MjNhYTU3ZTllMzQxMjE5NTFkYTI3NjRiNWVkNzNkZjk4 OCZkYXRhPTAyJTdDMDElN0N0aG9tYXMucG9ybmluJTQwbmNjZ3JvdXAuY29tJTdDZTFlMzQ2ZDU5 Yzc4NDM5OWFkNmIwOGQ4NGU4NGEzZTclN0NhNDExMTFiZTQ4NmI0NWY2OGJkMGVlMDFhNjJmMzY4 ZSU3QzAlN0MwJTdDNjM3MzQ1Njc4ODgxMDYyMTc2JnNkYXRhPXM0UGMxMnR1bUJDTnhxaExHUkVQ eGNwVHZEVSUyRjVleVY2YXd2OWE5ZlFtRSUzRCZyZXNlcnZlZD0wPiAuDQpPbiA3LzE3LzIwIDEx OjU3IFBNLCBUaG9tYXMgUG9ybmluIHdyb3RlOg0KDQpIZXJlIGlzIG15IHJldmlldyBvZiBkcmFm dC1pcnRmLWNmcmcta2FuZ2Fyb290d2VsdmUtMDI6DQoNCg0KDQpHZW5lcmFsIGNvbW1lbnRzOg0K DQoNCg0KVGhlIGZ1bmN0aW9uIGlzIHdlbGwgZGVzY3JpYmVkLiBUaGUgc3BlY2lmaWNhdGlvbiBp cyBub3Qgc2VsZi1jb250YWluZWQNCg0Kc2luY2UgaXQgcmVsaWVzIG9uIEZJUFMgMjAyLCBidXQg dGhhdCdzIG5vdCBhIHByb2JsZW0gaW4gbXkgb3BpbmlvbiAodGhlcmUNCg0KYWxyZWFkeSBhcmUg b3RoZXIgUkZDcyB0aGF0IHJlZmVyZW5jZSBGSVBTIDIwMikuDQoNCg0KDQpUaGUgZnVuY3Rpb24g YWxyZWFkeSBleGlzdHMgYW5kIGlzIHNwZWNpZmllZCBpbiBhIG5vdGUgcHVibGlzaGVkIG9uDQoN CmVwcmludCBzaW5jZSAyMDE2LCBzbyB0aGVyZSBpcyBubyBwb2ludCBpbiBjaGFuZ2luZyBpdCBu b3c7IHRoaXMgaXMgYW4NCg0KUkZDIHRoYXQgZGVzY3JpYmVzIGFuIGV4aXN0aW5nIHNpdHVhdGlv biwgbm90IG9uZSB0aGF0IGludHJvZHVjZXMgbmV3DQoNCnN0dWZmIChvdGhlcndpc2UsIEkgd291 bGQgaW5zaXN0LCBmb3IgYWVzdGhldGljYWwgcmVhc29ucywgb24gbWFraW5nDQoNCmxlbmd0aF9l bmNvZGUoKSB1c2UgbGl0dGxlLWVuZGlhbiBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IGJpZy1lbmRp YW4pLg0KQWRkaXRpb25hbGx5IHdlIGFkZGVkIGxpbmtzIHRvIHRoZSBwdWJsaWNhdGlvbnMgYXQg dGhlIEFDTlMNCmNvbmZlcmVuY2UgMjAxNCBhbmQgMjAxOCBmb3IgS2FuZ2Fyb29Ud2VsdmUgYW5k IHRoZSBTYWt1cmEgdHJlZSBoYXNoaW5nLg0KDQpTb21lIHBvb3Igc291bCwgc29tZXdoZXJlLCB3 aWxsIHdhbnQgdG8gbWFrZSBhIE1BQyBvdXQgb2YgSzEyIGFuZCB3aWxsDQoNCnRyeSB0byB1c2Ug aXQgaW4gSE1BQy4gVGhpcyBpcyBwcm9iYWJseSBub3QgYSB2ZXJ5IGdvb2QgaWRlYSwgdGhvdWdo DQoNCml0IHdvbid0IGJlIHdlYWsuIEhNQUMgcmVxdWlyZXMga25vd2xlZGdlIG9mIHRoZSAiYmxv Y2sgc2l6ZSIgb2YgdGhlDQoNCmFsZ29yaXRobSwgc28gdGhhdCBibG9jayBzaXplIHNob3VsZCBi ZSBzcGVjaWZpZWQgc29tZXdoZXJlLiBJbnR1aXRpdmVseSwNCg0KSSBzdXBwb3NlIHRoZSAiYmxv Y2sgc2l6ZSIgaXMgMTY4IGJ5dGVzLCBidXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHN0YXRlDQoN Cml0IGV4cGxpY2l0bHkgc29tZXdoZXJlLg0KDQoNCg0KQWxzbywgc29tZSBndWlkYW5jZSBhYm91 dCBhIGJldHRlciB3YXkgdG8gdHVybiBLMTIgaW50byBhIE1BQyB3b3VsZCBiZQ0KDQpoZWxwZnVs LiBOb3JtYWxseSwgYSBzaW1wbGUgSzEyKGtleSB8fCBkYXRhKSB3b3VsZCBiZSBlbm91Z2gsIHBy b3ZpZGVkDQoNCnRoYXQgdGhlIGNvbmNhdGVuYXRpb24gb2YgJ2tleScgYW5kICdkYXRhJyBpcyB1 bmFtYmlndW91cy4gSXQgaXMNCg0KdGVtcHRpbmcgdG8gdXNlIHRoZSBrZXkgYXMgY3VzdG9taXph dGlvbiBzdHJpbmcsIGJ1dCB0aGVuLCB5b3UgZG8gbm90DQoNCmhhdmUgYSBjdXN0b21pemF0aW9u IHN0cmluZyBhbnltb3JlLiBBIHJlbGF0ZWQgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUNCg0KTUFD IG91dHB1dCBsZW5ndGggc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGlucHV0L2N1c3RvbWl6YXRpb24g c3RyaW5nLg0KV2UgYWRkZWQgYSBwYXJhZ3JhcGggb24gdGhhdCBzdWJqZWN0IGluIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9uIHNlY3Rpb24uDQpXZSBwcmVzZW50IEhvcE1BQyhLLCBNLCBDLCBM KSA9IEsxMiggS2V5LCBLMTIoTSwgQywgMzIpLCBMKSB0byBkZXNjcmliZQ0KYSB3YXkgdG8gYnVp bGQgYSBNQUMgZnJvbSBLMTIuDQoNCg0KUGFydGljdWxhciBjb21tZW50czoNCg0KDQoNCnBhZ2Ug MjogInNwbGl0cyB0aGUgaW5wdXQgbWVzc2FnZSBpbiBmcmFnbWVudHMiIC0+ICJzcGxpdHMgLi4u IGludG8gZnJhZ21lbnRzIg0KDQooYWxzbyBwYWdlIDMpDQpFZGl0ZWQuDQoNCiBwYWdlIDM6ICJk b2VzIG5vdCBoYXZlIG92ZXJoZWFkIjogdGhpcyBpcyBhIGJvbGQgc3RhdGVtZW50LiBXaGF0IGlz IG1lYW50DQoNCmhlcmUgaXMgdGhhdCB0aGUgdHJlZSBoYXNoaW5nIG1vZGUgb2YgSzEyIGRvZXMg bm90IGludHJvZHVjZSBfYWRkaXRpb25hbF8NCg0Kb3ZlcmhlYWQgKGR1ZSB0byB0aGUgdHJlZSBo YXNoaW5nIG1vZGUpIGNvbXBhcmVkIHdpdGgsIHNheSwgU0hBS0U7IGJ1dA0KDQp0aGVyZSByZW1h aW5zIHRoZSBlbGVtZW50YXJ5IG92ZXJoZWFkIHdoaWNoIG1ha2VzIGl0IHNvIHRoYXQsIGZvciBp bnN0YW5jZSwNCg0KaGFzaGluZyAxMCBieXRlcyBpcyBub3QgbGVzcyBleHBlbnNpdmUgdGhhbiBo YXNoaW5nIDEyMCBieXRlcy4NCg0KDQoNClNwZWFraW5nIG9mIG92ZXJoZWFkLCBpdCBtYXkgYmUg d29ydGggcG9pbnRpbmcgb3V0IHRoYXQgdGhlIHRyZWUgbW9kZQ0KDQppbXBsaWVzIG1haW50YWlu aW5nIHR3byBzZXBhcmF0ZSBLZWNjYWsgY29udGV4dHMgKGF0IGxlYXN0IGZvciBpbnB1dHMNCg0K bG9uZ2VyIHRoYW4gODE5MiBieXRlcyksIGhlbmNlIGRvdWJsZSB0aGUgUkFNIHVzYWdlOyB0aGlz IG1heSBtYXR0ZXINCg0KZm9yIGNvbnN0cmFpbmVkIGVtYmVkZGVkIGRldmljZXMgKGkuZS4gbG93 LWVuZCBzbWFydGNhcmRzIGFuZA0KDQptaWNyb2NvbnRyb2xsZXJzLCB3aGVyZSAyMDAgYnl0ZXMg b2YgUkFNIGFyZSBhIGxvdCkuDQoNCg0KDQpwYWdlIDQ6ICJmcm9tIG4gdG8gbSBleGNsdXNpdmUi IGlzIGEgYml0IGNvbmZ1c2luZyBzaW5jZSBieXRlIGF0IGluZGV4IG0NCg0KaXMgZXhjbHVkZWQs IGJ1dCBieXRlIGF0IGluZGV4IG4gaXMgaW5jbHVkZWQuIE1heWJlOiAic2VsZWN0aW9uIG9mIGJ5 dGVzIGZyb20NCg0KaW5kZXggbiAoaW5jbHVzaXZlKSB0byBtIChleGNsdXNpdmUpIj8gQWxzbyBz YXkgc29tZXdoZXJlIHRoYXQgdGhlIGZpcnN0DQoNCmJ5dGUgb2YgYSBzdHJpbmcgaGFzIGluZGV4 IDAgKGkuZS4gdGhpcyBpcyBDL1J1c3QsIG5vdCBQYXNjYWwpLg0KRWRpdGVkLg0KDQpwYWdlIDQ6 ICJ4Kip5IGRlbm90ZXMgeCBtdWx0aXBsaWVkIGJ5IGl0c2VsZiB5IHRpbWVzIiAtPiB0aGlzIHdv dWxkDQoNCmFjdHVhbGx5IGJlIHgqKih5KzEpIChpZiB5b3UgbXVsdGlwbHkgeCBieSBpdHNlbGYg X29uY2VfLCB5b3UgZ2V0IHgqeCkuDQpFZGl0ZWQuDQoNCnBhZ2UgNDogInRoZSBudW1iZXIgb2Yg b3V0cHV0IGJ5dGVzIHJlcXVlc3RlZCIgLT4gdGhpcyBsYWNrcyBhIHZlcmI7DQoNCnByb2JhYmx5 OiAiaXMgdGhlIHJlcXVlc3RlZCBudW1iZXIgb2Ygb3V0cHV0IGJ5dGVzIg0KRWRpdGVkLg0KDQpw YWdlIDU6ICJGaXJzdCB0aGUgbWVzc2FnZSBpcyBwYWRkZWQgd2l0aCB6ZXJvZXMgdG8gdGhlIGNs b3Nlc3QgbXVsdGlwbGUgb2YNCg0KMTY4IGJ5dGVzLiAgVGhlbiBhIGJ5dGUgYDgwYCBpcyBYT1Jl ZCB0byB0aGUgbGFzdCBieXRlIG9mIHRoZSBwYWRkZWQNCg0KbWVzc2FnZS4gIGFuZCB0aGUgcmVz dWx0aW5nIHN0cmluZyBpcyBzcGxpdCBpbnRvIGEgc2VxdWVuY2Ugb2YgMTY4LWJ5dGUNCg0KYmxv Y2tzLiINCg0KLT4gVGhpcyBjb3VsZCBiZSBtYWRlIGNsZWFyZXIsIGZpcnN0IHRvIGluZGljYXRl IHRoYXQgaXQgaXMgdGhlIGxlbmd0aCwNCg0KaW4gYnl0ZXMsIG9mIHRoZSBwYWRkZWQgbWVzc2Fn ZSB3aGljaCBpcyB0byBiZSBhIG11bHRpcGxlIG9mIDE2ODsgYWxzbywNCg0KdGhhdCB0aGUgImNs b3Nlc3QiIGlzIHJlYWxseSBhIHJvdW5kaW5nLXVwIChlLmcuIHdpdGggYSAxNjktYnl0ZSBpbnB1 dCwNCg0Kd2UgcmVhbGx5IG5lZWQgdG8gYXBwZW5kIDE2NyBvdGhlciBieXRlcywgZXZlbiB0aG91 Z2ggMTY4IGlzIGFyZ3VhYmx5DQoNCm11Y2ggY2xvc2VyIHRvIDE2OSB0aGFuIDMzNikuIFRoZXJl IHNob3VsZCBiZSBhbiBleHBsaWNpdCBzcGVjaWZpY2F0aW9uDQoNCmFib3V0IHdoYXQgdG8gZG8g aWYgdGhlIGlucHV0IHNpemUgYWxyZWFkeSBoYXMgYSBzaXplIG11bHRpcGxlIG9mIDE2ODoNCg0K c2hvdWxkIHdlIGFkZCAxNjggZXh0cmEgYnl0ZXMgb2YgdmFsdWUgemVybywgb3Igbm9uZSBhdCBh bGw/IE5vdGUgdGhhdCwNCg0KaW4gdGhlIGxhdHRlciBjYXNlLCB0aGVyZSBtdXN0IGJlIGEgc3Bl Y2lhbCBjYXNlIGZvciBhbiBpbnB1dCBvZiBsZW5ndGgNCg0KMDogaWYgdGhlIHBhZGRlZCBpbnB1 dCBjb25zaXN0cyBvZiBubyBieXRlIGF0IGFsbCwgdGhlbiBpdCBiZWNvbWVzDQoNCmRpZmZpY3Vs dCB0byBYT1IgMHg4MCBpbnRvICJ0aGUgbGFzdCBieXRlIi4NCldlIGNsYXJpZnkgdGhhdCB0aGUg bGVuZ3RoIG9mIHRoZSBGIGZ1bmN0aW9uIGlzIHBvc2l0aXZlLg0KVGhpcyByZXNvbHZlIHRoZSBw cm9ibGVtIG9mIGlucHV0cyBjb25zaXN0aW5nIG9mIG5vIGJ5dGVzLg0KSW4gdGhlIGRlZmluaXRp b24gb2YgS2FuZ2Fyb29Ud2VsdmUgaW4gc2VjdGlvbiAyLjIsIHRoZXJlIGFyZSBubyBjYWxscyB0 byBGDQp3aXRoIGlucHV0IG9mIGxlbmd0aCAwLg0KDQpXZSBjbGFyaWZ5IHRoZSByb3VuZGluZyB1 cCB0byB0aGUgbmV4dCBtdWx0aXBsZSBvZiAxNjguDQoNCihUaHJlZSBwYXJhZ3JhcGhzIGxhdGVy LCB3ZSBsZWFybiB0aGF0IHRoZSBpbnB1dCBsZW5ndGggaXMgYXQgbGVhc3QNCg0KMSBieXRlLCB3 aGljaCBhdm9pZHMgYW55IGlzc3VlIHJlbGF0ZWQgdG8gYSB6ZXJvLWxlbmd0aCBpbnB1dDsgdGhp cw0KDQpzaG91bGQgcHJvYmFibHkgYmUgZXhwbGFpbmVkIGEgYml0IGVhcmxpZXIgaW4gdGhlIHRl eHQuKQ0KRWRpdGVkLg0KDQogcGFnZSAxMTogImFnYWluc3QgYWxsIGF0dGFja3MiIChlbmQgb2Yg Zmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNSk6DQoNCnRoaXMgbGFja3MgYSBmaW5hbCBkb3Qu DQpFZGl0ZWQuDQoNCg0KDQpUaG9tYXMNCg0KV2UgYXJlIG9wZW4gdG8gYW55IGFkZGl0aW9uYWwg ZmVlZGJhY2suDQoNCi0tDQoNCktpbmQgcmVnYXJkcywNCg0KDQoNCkJlbm/DrnQgVmlndWllcg0K DQpTb2Z0d2FyZSBFbmdpbmVlciAtIFBoRCBTdHVkZW50IHwgQ3J5cHRvZ3JhcGh5ICYgRm9ybWFs IE1ldGhvZHMNCg0KUmFkYm91ZCBVbml2ZXJzaXR5IHwgTWVyY2F0b3IgMSwgVG9lcm5vb2l2ZWxk IDIxMg0KDQo2NTI1IEVDIE5pam1lZ2VuLCB0aGUgTmV0aGVybGFuZHMgfCB3d3cudmlndWllci5u bDxodHRwczovL2dicjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzQSUyRiUyRnd3dy52aWd1aWVyLm5sJTJGJmRhdGE9MDIlN0MwMSU3Q3Rob21hcy5wb3JuaW4l NDBuY2Nncm91cC5jb20lN0NlMWUzNDZkNTljNzg0Mzk5YWQ2YjA4ZDg0ZTg0YTNlNyU3Q2E0MTEx MWJlNDg2YjQ1ZjY4YmQwZWUwMWE2MmYzNjhlJTdDMCU3QzAlN0M2MzczNDU2Nzg4ODEwNjcxNTcm c2RhdGE9YnhaUlRCNUlXSVVwcXJCZ1ZCUnJYdmd1QmptQmdKJTJGbDl3dGtjMDlhQVBvJTNEJnJl c2VydmVkPTA+DQo= --_000_619ed4c1210c4502802583e19c6f6c4bSFHDAG6NODE2stcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA1Mjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNTIiPkRlYXIgQWxleGV5LDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA1MiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDUyIj5UaGFua3MgdG8gSmVhbi1QaGlsaXBwZSBh bmQgVGhvbWFzIGZvciB0aGVpciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNTIiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA1MiI+V2UgdGhpbmsgYWxsIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQuIChN YXliZSwgSmVhbi1QaGlsaXBwZSBjb3VsZCB5b3UgY29uZmlybT8pIElmIGluZGVlZCB0aGUgY2Fz ZSwgY2FuIHlvdSBoZWxwIHRvIG1vdmUgdGhlIGRvY3VtZW50IGZvcndhcmQgPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA1MiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDUyIj5UaGFua3MgJmFtcDsga2luZCByZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA1MiI+QmVub8OudCwgRGF2aWQsIEdpbGxlcywgSm9hbiBhbmQgUXV5bmg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNTIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA1MiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBUaG9tYXMgUG9ybmluICZsdDt0aG9tYXMu cG9ybmluQG5jY2dyb3VwLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIDIxIFNl cHRlbWJlciAyMDIwIDE2OjE4PGJyPg0KPGI+VG86PC9iPiBCZW5vw650IFZpZ3VpZXIgJmx0O2Iu dmlndWllckBjcy5ydS5ubCZndDs7IEFsZXhleSBNZWxuaWtvdiAmbHQ7YWxleGV5Lm1lbG5pa292 QGlzb2RlLmNvbSZndDs7IGRyYWZ0LWlydGYtY2ZyZy1rYW5nYXJvb3R3ZWx2ZUBpZXRmLm9yZzsg Y3J5cHRvLXBhbmVsQGlydGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFWFRFUk5BTDog UmU6IFtDcnlwdG8tcGFuZWxdIFJlcXVlc3QgZm9yIHJldmlldzogZHJhZnQtaXJ0Zi1jZnJnLWth bmdhcm9vdHdlbHZlLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgYW0gbm90IGluIGEgZ29vZCBw b3NpdGlvbiB0byBtYWtlIGNvbW1lbnRzIG9uIGRlbGF5cywgc2luY2UgSSBhbHNvIGxldCB0aGlz IGVtYWlsIHNsZWVwIGZvciB0aHJlZSB3ZWVrcy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+WW91ciBjaGFuZ2VzIGxvb2sgZ29vZCB0byBtZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgbGlrZSB0aGUgaWRlYSB0aGF0IHRo ZSBidWxrIG9mIHRoZSBkYXRhIHByb2Nlc3NpbmcgaW4gSG9wTUFDIGhhcyBubyBkZXBlbmRlbmN5 IG9uIHRoZSBrZXk7IGl0IGhhcyBpbmRlZWQgc3Ryb25nIGJlbmVmaXRzIHdpdGggcmVnYXJkIHRv IHNpZGUgY2hhbm5lbCBhdHRhY2tzLiBPZiBjb3Vyc2UsIGl0IHVuYXZvaWRhYmx5IGltcGxpZXMg dGhhdCBIb3BNQUMNCiByZWxpZXMgb24gdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNlIG9mIHRoZSBr ZXlsZXNzIGhhc2ggZnVuY3Rpb24uIEluIHRoZSBhZnRlcm1hdGggb2YgdGhlIE1ENSBhbmQgU0hB LTEgYXR0YWNrcyAoaW4gdGhlIDIwMDBzKSwgdGhlcmUgaGFzIGJlZW4gYSB0cmVuZCBvZiBzaHVu bmluZyBjb2xsaXNpb24gcmVzaXN0YW5jZSwgYW5kIGluc2lzdGluZyBvbiB1c2luZyBvbmx5IChz ZWNvbmQtKXByZWltYWdlIHJlc2lzdGFuY2U7IHRoYXQncyBob3csIGZvcg0KIGluc3RhbmNlLCBF ZDI1NTE5IHNpZ25hdHVyZXMgaW4gJnF1b3Q7cHVyZSZxdW90OyBtb2RlIGluc2lzdCBvbiBnZW5l cmF0aW5nIHRoZSBjaGFsbGVuZ2UgYXMgSChwa2V5JiM0MztSJiM0MzttZXNzYWdlKSBhbmQgbm90 IEgocGtleSYjNDM7UiYjNDM7SChtZXNzYWdlKSkuIFRoaXMgdHJlbmQgaW1wbGllcyBzb21lIHBy YWN0aWNhbCBsaW1pdGF0aW9ucyAoZS5nLiAmcXVvdDtwdXJlJnF1b3Q7IEVkMjU1MTkgc2lnbmF0 dXJlcyBtYWtlIGl0IG11Y2ggbW9yZSBkaWZmaWN1bHQgdG8gcHJvY2VzcyBYLjUwOSBjZXJ0aWZp Y2F0ZXMNCiBpbiBtZW1vcnktY29uc3RyYWluZWQgZW52aXJvbm1lbnRzKS4gSSB0aGluayB5b3Vy IGNob2ljZSBpbiBIb3BNQUMgaXMgYSBiZXR0ZXIgdHJhZGUtb2ZmOyBrZXlsZXNzIHByb2Nlc3Np bmcgb2YgdGhlIGJ1bGsgb2YgdGhlIGRhdGEgaGFzIHRhbmdpYmxlIHByYWN0aWNhbCBiZW5lZml0 cywgYW5kIGlmIEsxMiBpcyBub3QgY29sbGlzaW9uLXJlc2lzdGFudCB0aGVuIHRoZSBmb3VuZGF0 aW9uIG9mIGl0cyBvdGhlciBzZWN1cml0eSBwcm9wZXJ0aWVzDQogYmVjb21lcyBxdWl0ZSBmbGFr eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRob21hczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2siPkJlbm/DrnQgVmlndWllciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmIu dmlndWllckBjcy5ydS5ubCI+Yi52aWd1aWVyQGNzLnJ1Lm5sPC9hPiZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgU2VwdGVtYmVyIDEsIDIwMjAgYXQgMTA6Mzg8YnI+DQo8Yj5UbzogPC9i PlRob21hcyBQb3JuaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMucG9ybmluQG5jY2dyb3Vw LmNvbSI+dGhvbWFzLnBvcm5pbkBuY2Nncm91cC5jb208L2E+Jmd0OywgQWxleGV5IE1lbG5pa292 ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSI+YWxleGV5Lm1l bG5pa292QGlzb2RlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaXJ0 Zi1jZnJnLWthbmdhcm9vdHdlbHZlQGlldGYub3JnIj5kcmFmdC1pcnRmLWNmcmcta2FuZ2Fyb290 d2VsdmVAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pcnRm LWNmcmcta2FuZ2Fyb290d2VsdmVAaWV0Zi5vcmciPmRyYWZ0LWlydGYtY2ZyZy1rYW5nYXJvb3R3 ZWx2ZUBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y3J5cHRvLXBhbmVs QGlydGYub3JnIj5jcnlwdG8tcGFuZWxAaXJ0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86Y3J5cHRvLXBhbmVsQGlydGYub3JnIj5jcnlwdG8tcGFuZWxAaXJ0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogRVhURVJOQUw6IFJlOiBbQ3J5cHRvLXBhbmVsXSBS ZXF1ZXN0IGZvciByZXZpZXc6IGRyYWZ0LWlydGYtY2ZyZy1rYW5nYXJvb3R3ZWx2ZS0wMjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+RGVhciBUaG9tYXMsIERlYXIgQWxleGV5LCBEZWFyIENyeXB0byBQYW5lbCBtZW1iZXJz LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIj5X ZSB3b3VsZCBsaWtlIHRvIHRoYW5rIHlvdSBmb3IgeW91ciB0aW1lIGludG8gcmV2aWV3aW5nIG91 ciBkcmFmdDxicj4NCmFuZCBwcm92aWRpbmcgdXMgd2l0aCB5b3VyIGNvbnN0cnVjdGl2ZSBjb21t ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSI+V2UgYXBv bG9naXplIGZvciB0aGUgZGVsYXlzIChjb3JvbmEgJmFtcDsgdmFjYXRpb25zLi4uKSBhbmQgcHJv dmlkZSB5b3UgaGVyZSB3aXRoPGJyPg0Kb3VyIG1vZGlmaWNhdGlvbnMgdG8gdGhlIGRyYWZ0OiA8 YSBocmVmPSJodHRwczovL2dicjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGY2ZyZyUyRmRyYWZ0LWlydGYtY2ZyZy1rYW5n YXJvb3R3ZWx2ZSUyRmNvbW1pdCUyRjcwZWZmNDIzYWE1N2U5ZTM0MTIxOTUxZGEyNzY0YjVlZDcz ZGY5ODgmYW1wO2RhdGE9MDIlN0MwMSU3Q3Rob21hcy5wb3JuaW4lNDBuY2Nncm91cC5jb20lN0Nl MWUzNDZkNTljNzg0Mzk5YWQ2YjA4ZDg0ZTg0YTNlNyU3Q2E0MTExMWJlNDg2YjQ1ZjY4YmQwZWUw MWE2MmYzNjhlJTdDMCU3QzAlN0M2MzczNDU2Nzg4ODEwNjIxNzYmYW1wO3NkYXRhPXM0UGMxMnR1 bUJDTnhxaExHUkVQeGNwVHZEVSUyRjVleVY2YXd2OWE5ZlFtRSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+ DQpodHRwczovL2dpdGh1Yi5jb20vY2ZyZy9kcmFmdC1pcnRmLWNmcmcta2FuZ2Fyb290d2VsdmUv Y29tbWl0LzcwZWZmNDIzYWE1N2U5ZTM0MTIxOTUxZGEyNzY0YjVlZDczZGY5ODg8L2E+IC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPk9uIDcvMTcvMjAgMTE6NTcgUE0sIFRob21hcyBQb3JuaW4gd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlcmUg aXMgbXkgcmV2aWV3IG9mIGRyYWZ0LWlydGYtY2ZyZy1rYW5nYXJvb3R3ZWx2ZS0wMjo8c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkdlbmVyYWwgY29tbWVudHM6PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGUgZnVuY3Rpb24gaXMgd2VsbCBkZXNjcmliZWQuIFRoZSBzcGVjaWZpY2F0aW9uIGlz IG5vdCBzZWxmLWNvbnRhaW5lZDxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zaW5jZSBpdCByZWxpZXMgb24gRklQUyAyMDIs IGJ1dCB0aGF0J3Mgbm90IGEgcHJvYmxlbSBpbiBteSBvcGluaW9uICh0aGVyZTxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5h bHJlYWR5IGFyZSBvdGhlciBSRkNzIHRoYXQgcmVmZXJlbmNlIEZJUFMgMjAyKS48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlRoZSBmdW5jdGlvbiBhbHJlYWR5IGV4aXN0cyBhbmQgaXMgc3BlY2lm aWVkIGluIGEgbm90ZSBwdWJsaXNoZWQgb248c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZXByaW50IHNpbmNlIDIwMTYsIHNv IHRoZXJlIGlzIG5vIHBvaW50IGluIGNoYW5naW5nIGl0IG5vdzsgdGhpcyBpcyBhbjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5SRkMgdGhhdCBkZXNjcmliZXMgYW4gZXhpc3Rpbmcgc2l0dWF0aW9uLCBub3Qgb25lIHRoYXQg aW50cm9kdWNlcyBuZXc8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c3R1ZmYgKG90aGVyd2lzZSwgSSB3b3VsZCBpbnNpc3Qs IGZvciBhZXN0aGV0aWNhbCByZWFzb25zLCBvbiBtYWtpbmc8c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+bGVuZ3RoX2VuY29k ZSgpIHVzZSBsaXR0bGUtZW5kaWFuIGluc3RlYWQgb2YgdGhlIGN1cnJlbnQgYmlnLWVuZGlhbiku PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QWRkaXRpb25hbGx5IHdlIGFkZGVkIGxpbmtzIHRvIHRoZSBwdWJsaWNhdGlvbnMg YXQgdGhlIEFDTlM8YnI+DQpjb25mZXJlbmNlIDIwMTQgYW5kIDIwMTggZm9yIEthbmdhcm9vVHdl bHZlIGFuZCB0aGUgU2FrdXJhIHRyZWUgaGFzaGluZy4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tb21lIHBvb3Igc291bCwgc29tZXdoZXJlLCB3aWxs IHdhbnQgdG8gbWFrZSBhIE1BQyBvdXQgb2YgSzEyIGFuZCB3aWxsPHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRyeSB0byB1 c2UgaXQgaW4gSE1BQy4gVGhpcyBpcyBwcm9iYWJseSBub3QgYSB2ZXJ5IGdvb2QgaWRlYSwgdGhv dWdoPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPml0IHdvbid0IGJlIHdlYWsuIEhNQUMgcmVxdWlyZXMga25vd2xlZGdlIG9m IHRoZSAmcXVvdDtibG9jayBzaXplJnF1b3Q7IG9mIHRoZTxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hbGdvcml0aG0sIHNv IHRoYXQgYmxvY2sgc2l6ZSBzaG91bGQgYmUgc3BlY2lmaWVkIHNvbWV3aGVyZS4gSW50dWl0aXZl bHksPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkgc3VwcG9zZSB0aGUgJnF1b3Q7YmxvY2sgc2l6ZSZxdW90OyBpcyAxNjgg Ynl0ZXMsIGJ1dCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gc3RhdGU8c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aXQgZXhwbGlj aXRseSBzb21ld2hlcmUuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbHNvLCBzb21lIGd1aWRh bmNlIGFib3V0IGEgYmV0dGVyIHdheSB0byB0dXJuIEsxMiBpbnRvIGEgTUFDIHdvdWxkIGJlPHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPmhlbHBmdWwuIE5vcm1hbGx5LCBhIHNpbXBsZSBLMTIoa2V5IHx8IGRhdGEpIHdvdWxk IGJlIGVub3VnaCwgcHJvdmlkZWQ8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhhdCB0aGUgY29uY2F0ZW5hdGlvbiBvZiAn a2V5JyBhbmQgJ2RhdGEnIGlzIHVuYW1iaWd1b3VzLiBJdCBpczxzcGFuIGxhbmc9IkVOLUNBIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij50ZW1wdGluZyB0 byB1c2UgdGhlIGtleSBhcyBjdXN0b21pemF0aW9uIHN0cmluZywgYnV0IHRoZW4sIHlvdSBkbyBu b3Q8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+aGF2ZSBhIGN1c3RvbWl6YXRpb24gc3RyaW5nIGFueW1vcmUuIEEgcmVsYXRl ZCBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZTxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NQUMgb3V0cHV0IGxlbmd0aCBzaG91 bGQgYmUgcGFydCBvZiB0aGUgaW5wdXQvY3VzdG9taXphdGlvbiBzdHJpbmcuPHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSBhZGRlZCBhIHBhcmFncmFwaCBvbiB0aGF0IHN1 YmplY3QgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbi48YnI+DQpXZSBwcmVz ZW50IEhvcE1BQyhLLCBNLCBDLCBMKSA9IEsxMiggS2V5LCBLMTIoTSwgQywgMzIpLCBMKSB0byBk ZXNjcmliZTxicj4NCmEgd2F5IHRvIGJ1aWxkIGEgTUFDIGZyb20gSzEyLjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFydGljdWxh ciBjb21tZW50czo8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBhZ2UgMjogJnF1b3Q7c3BsaXRz IHRoZSBpbnB1dCBtZXNzYWdlIGluIGZyYWdtZW50cyZxdW90OyAtJmd0OyAmcXVvdDtzcGxpdHMg Li4uIGludG8gZnJhZ21lbnRzJnF1b3Q7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPihhbHNvIHBhZ2UgMyk8c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkVkaXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwO3BhZ2UgMzogJnF1b3Q7ZG9lcyBub3Qg aGF2ZSBvdmVyaGVhZCZxdW90OzogdGhpcyBpcyBhIGJvbGQgc3RhdGVtZW50LiBXaGF0IGlzIG1l YW50PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmhlcmUgaXMgdGhhdCB0aGUgdHJlZSBoYXNoaW5nIG1vZGUgb2YgSzEyIGRv ZXMgbm90IGludHJvZHVjZSBfYWRkaXRpb25hbF88c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+b3ZlcmhlYWQgKGR1ZSB0byB0 aGUgdHJlZSBoYXNoaW5nIG1vZGUpIGNvbXBhcmVkIHdpdGgsIHNheSwgU0hBS0U7IGJ1dDxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij50aGVyZSByZW1haW5zIHRoZSBlbGVtZW50YXJ5IG92ZXJoZWFkIHdoaWNoIG1ha2VzIGl0 IHNvIHRoYXQsIGZvciBpbnN0YW5jZSw8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aGFzaGluZyAxMCBieXRlcyBpcyBub3Qg bGVzcyBleHBlbnNpdmUgdGhhbiBoYXNoaW5nIDEyMCBieXRlcy48c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNwZWFraW5nIG9mIG92ZXJoZWFkLCBpdCBtYXkgYmUgd29ydGggcG9pbnRpbmcgb3V0 IHRoYXQgdGhlIHRyZWUgbW9kZTxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5pbXBsaWVzIG1haW50YWluaW5nIHR3byBzZXBh cmF0ZSBLZWNjYWsgY29udGV4dHMgKGF0IGxlYXN0IGZvciBpbnB1dHM8c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+bG9uZ2Vy IHRoYW4gODE5MiBieXRlcyksIGhlbmNlIGRvdWJsZSB0aGUgUkFNIHVzYWdlOyB0aGlzIG1heSBt YXR0ZXI8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Zm9yIGNvbnN0cmFpbmVkIGVtYmVkZGVkIGRldmljZXMgKGkuZS4gbG93 LWVuZCBzbWFydGNhcmRzIGFuZDxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5taWNyb2NvbnRyb2xsZXJzLCB3aGVyZSAyMDAg Ynl0ZXMgb2YgUkFNIGFyZSBhIGxvdCkuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5wYWdlIDQ6 ICZxdW90O2Zyb20gbiB0byBtIGV4Y2x1c2l2ZSZxdW90OyBpcyBhIGJpdCBjb25mdXNpbmcgc2lu Y2UgYnl0ZSBhdCBpbmRleCBtPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmlzIGV4Y2x1ZGVkLCBidXQgYnl0ZSBhdCBpbmRl eCBuIGlzIGluY2x1ZGVkLiBNYXliZTogJnF1b3Q7c2VsZWN0aW9uIG9mIGJ5dGVzIGZyb208c3Bh biBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+aW5kZXggbiAoaW5jbHVzaXZlKSB0byBtIChleGNsdXNpdmUpJnF1b3Q7PyBBbHNvIHNh eSBzb21ld2hlcmUgdGhhdCB0aGUgZmlyc3Q8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Ynl0ZSBvZiBhIHN0cmluZyBoYXMg aW5kZXggMCAoaS5lLiB0aGlzIGlzIEMvUnVzdCwgbm90IFBhc2NhbCkuPHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5FZGl0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5wYWdlIDQ6ICZxdW90O3gqKnkgZGVub3RlcyB4IG11bHRp cGxpZWQgYnkgaXRzZWxmIHkgdGltZXMmcXVvdDsgLSZndDsgdGhpcyB3b3VsZDxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5h Y3R1YWxseSBiZSB4KiooeSYjNDM7MSkgKGlmIHlvdSBtdWx0aXBseSB4IGJ5IGl0c2VsZiBfb25j ZV8sIHlvdSBnZXQgeCp4KS48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkVk aXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBh Z2UgNDogJnF1b3Q7dGhlIG51bWJlciBvZiBvdXRwdXQgYnl0ZXMgcmVxdWVzdGVkJnF1b3Q7IC0m Z3Q7IHRoaXMgbGFja3MgYSB2ZXJiOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5wcm9iYWJseTogJnF1b3Q7aXMgdGhlIHJl cXVlc3RlZCBudW1iZXIgb2Ygb3V0cHV0IGJ5dGVzJnF1b3Q7PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5FZGl0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5wYWdlIDU6ICZxdW90O0ZpcnN0IHRoZSBtZXNzYWdlIGlzIHBhZGRl ZCB3aXRoIHplcm9lcyB0byB0aGUgY2xvc2VzdCBtdWx0aXBsZSBvZjxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xNjggYnl0 ZXMuJm5ic3A7IFRoZW4gYSBieXRlIGA4MGAgaXMgWE9SZWQgdG8gdGhlIGxhc3QgYnl0ZSBvZiB0 aGUgcGFkZGVkPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPm1lc3NhZ2UuJm5ic3A7IGFuZCB0aGUgcmVzdWx0aW5nIHN0cmlu ZyBpcyBzcGxpdCBpbnRvIGEgc2VxdWVuY2Ugb2YgMTY4LWJ5dGU8c3BhbiBsYW5nPSJFTi1DQSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YmxvY2tzLiZx dW90OzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4tJmd0OyBUaGlzIGNvdWxkIGJlIG1hZGUgY2xlYXJlciwgZmlyc3QgdG8g aW5kaWNhdGUgdGhhdCBpdCBpcyB0aGUgbGVuZ3RoLDxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5pbiBieXRlcywgb2YgdGhl IHBhZGRlZCBtZXNzYWdlIHdoaWNoIGlzIHRvIGJlIGEgbXVsdGlwbGUgb2YgMTY4OyBhbHNvLDxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij50aGF0IHRoZSAmcXVvdDtjbG9zZXN0JnF1b3Q7IGlzIHJlYWxseSBhIHJvdW5kaW5n LXVwIChlLmcuIHdpdGggYSAxNjktYnl0ZSBpbnB1dCw8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+d2UgcmVhbGx5IG5lZWQg dG8gYXBwZW5kIDE2NyBvdGhlciBieXRlcywgZXZlbiB0aG91Z2ggMTY4IGlzIGFyZ3VhYmx5PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPm11Y2ggY2xvc2VyIHRvIDE2OSB0aGFuIDMzNikuIFRoZXJlIHNob3VsZCBiZSBhbiBl eHBsaWNpdCBzcGVjaWZpY2F0aW9uPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmFib3V0IHdoYXQgdG8gZG8gaWYgdGhlIGlu cHV0IHNpemUgYWxyZWFkeSBoYXMgYSBzaXplIG11bHRpcGxlIG9mIDE2ODo8c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c2hv dWxkIHdlIGFkZCAxNjggZXh0cmEgYnl0ZXMgb2YgdmFsdWUgemVybywgb3Igbm9uZSBhdCBhbGw/ IE5vdGUgdGhhdCw8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+aW4gdGhlIGxhdHRlciBjYXNlLCB0aGVyZSBtdXN0IGJlIGEg c3BlY2lhbCBjYXNlIGZvciBhbiBpbnB1dCBvZiBsZW5ndGg8c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MDogaWYgdGhlIHBh ZGRlZCBpbnB1dCBjb25zaXN0cyBvZiBubyBieXRlIGF0IGFsbCwgdGhlbiBpdCBiZWNvbWVzPHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPmRpZmZpY3VsdCB0byBYT1IgMHg4MCBpbnRvICZxdW90O3RoZSBsYXN0IGJ5dGUmcXVv dDsuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+V2UgY2xhcmlmeSB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIEYgZnVuY3Rpb24g aXMgcG9zaXRpdmUuPGJyPg0KVGhpcyByZXNvbHZlIHRoZSBwcm9ibGVtIG9mIGlucHV0cyBjb25z aXN0aW5nIG9mIG5vIGJ5dGVzLjxicj4NCkluIHRoZSBkZWZpbml0aW9uIG9mIEthbmdhcm9vVHdl bHZlIGluIHNlY3Rpb24gMi4yLCB0aGVyZSBhcmUgbm8gY2FsbHMgdG8gRjxicj4NCndpdGggaW5w dXQgb2YgbGVuZ3RoIDAuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUNBIj5XZSBjbGFyaWZ5IHRoZSByb3VuZGluZyB1cCB0byB0aGUgbmV4dCBtdWx0aXBsZSBvZiAx NjguPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oVGhy ZWUgcGFyYWdyYXBocyBsYXRlciwgd2UgbGVhcm4gdGhhdCB0aGUgaW5wdXQgbGVuZ3RoIGlzIGF0 IGxlYXN0PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjEgYnl0ZSwgd2hpY2ggYXZvaWRzIGFueSBpc3N1ZSByZWxhdGVkIHRv IGEgemVyby1sZW5ndGggaW5wdXQ7IHRoaXM8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c2hvdWxkIHByb2JhYmx5IGJlIGV4 cGxhaW5lZCBhIGJpdCBlYXJsaWVyIGluIHRoZSB0ZXh0Lik8c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkVkaXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwO3BhZ2UgMTE6ICZxdW90O2FnYWluc3QgYWxsIGF0dGFja3Mm cXVvdDsgKGVuZCBvZiBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA1KTo8c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhp cyBsYWNrcyBhIGZpbmFsIGRvdC48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkVkaXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaG9tYXM8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiPldlIGFyZSBvcGVu IHRvIGFueSBhZGRpdGlvbmFsIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tQ0EiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1DQSI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLUNBIj5CZW5vw650IFZpZ3VpZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPlNvZnR3YXJlIEVuZ2luZWVyIC0gUGhEIFN0dWRl bnQgfCBDcnlwdG9ncmFwaHkgJmFtcDsgRm9ybWFsIE1ldGhvZHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tQ0EiPlJhZGJvdWQgVW5pdmVyc2l0eSB8IE1lcmNh dG9yIDEsIFRvZXJub29pdmVsZCAyMTI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tQ0EiPjY1MjUgRUMgTmlqbWVnZW4sIHRoZSBOZXRoZXJsYW5kcyB8IDxhIGhy ZWY9Imh0dHBzOi8vZ2JyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwJTNBJTJGJTJGd3d3LnZpZ3VpZXIubmwlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3Rob21hcy5w b3JuaW4lNDBuY2Nncm91cC5jb20lN0NlMWUzNDZkNTljNzg0Mzk5YWQ2YjA4ZDg0ZTg0YTNlNyU3 Q2E0MTExMWJlNDg2YjQ1ZjY4YmQwZWUwMWE2MmYzNjhlJTdDMCU3QzAlN0M2MzczNDU2Nzg4ODEw NjcxNTcmYW1wO3NkYXRhPWJ4WlJUQjVJV0lVcHFyQmdWQlJyWHZndUJqbUJnSiUyRmw5d3RrYzA5 YUFQbyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+d3d3LnZpZ3VpZXIubmw8L2E+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_619ed4c1210c4502802583e19c6f6c4bSFHDAG6NODE2stcom_-- From nobody Mon Oct 12 06:56:11 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF523A14F6 for ; Mon, 12 Oct 2020 06:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=2.331, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LJRF-5V5zK58 for ; Mon, 12 Oct 2020 06:56:07 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB533A14F7 for ; Mon, 12 Oct 2020 06:56:06 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id ce10so23307676ejc.5 for ; Mon, 12 Oct 2020 06:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ydEsiZJjyU4v+2lJdQcoHtYt3eDMzR3l2FkqBCd/xFE=; b=QmRpJBh3gf8pEG75U/X3NLSo3pSf2m5RvoMwe60HkGUOBKPhFILuS4+Hc9vcTBsEvm vPyGLwXRgZ92POGmmhKUXGV28J889f04YsMr5AvnQdub/kfu29g69cQ9gTq2FN7C8u4U lwtls/h82FaajHKnVbmgeTFDb+ALd/KdZWTkrYM46jSlbanqUS6ar1kx4xzLrH6bmR8K GYg83a7YEQxOOrOdmACF9YVyz93pIyxqJEdimyC+F0OqurNCj7qZqsHLaoNMMpkaQ9mw ExL9W8OJzvkSZzptMkLX/rGQ4TDhHof6P5fGiE6WT4Dsa9peX7i2f6oNx6sn3MZApbBE ezdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ydEsiZJjyU4v+2lJdQcoHtYt3eDMzR3l2FkqBCd/xFE=; b=DKIJ3Vb7mAevJuWwYZBqe2ZjqWuURaugVmh5sPIE705Oq9P+GezkqJHN9JNlqRaz50 JeuVhMoC7e7+udx2TIRNHKKPnQoZDcvOyVzVTQydgryPL6so9tmpW7vecW3ewsV1N9Tq KgajPkQlUrVVl1mxG2iiDVXPvhgX67Uqvs4wzJHTJzKHVwcJqzPdGyR68fjibMxML/4J jcqOl+DLAmBeeHErUsqdBvbmCzWx7GlyW2dRDbhEBvHOeUy26VNqCJlkUMIqCwMsXDSJ ChT4ZL89mtrwTk3gkP9+uaHLX07DWpB0JOrQtQncsOeG3LicB8zVqRgVR8TdmEU7QX/O E61w== X-Gm-Message-State: AOAM532j+P1vFyC9fhHX00eWfy9Nx25f+cGn0XnioTJDAhYqhnKVCTx+ 4qORwWdRGd31QmoDD5MRqY4wfNgsvw/lGIl3nXs= X-Google-Smtp-Source: ABdhPJz0pzUJNyaP+chvIFAQf46tgFkspQ+qHg3nnckak0I+0Bthh4QnFBCHg4x/yv907SkBpbijGbaxPJ3wnGQeVcw= X-Received: by 2002:a17:906:934d:: with SMTP id p13mr29576432ejw.532.1602510964949; Mon, 12 Oct 2020 06:56:04 -0700 (PDT) MIME-Version: 1.0 References: <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> In-Reply-To: <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> From: "Stanislav V. Smyshlyaev" Date: Mon, 12 Oct 2020 16:58:53 +0300 Message-ID: To: Gilles VAN ASSCHE , Jean-Philippe Aumasson Cc: Alexey Melnikov , Thomas Pornin , "crypto-panel@irtf.org" , =?UTF-8?Q?Beno=C3=AEt_Viguier?= , "draft-irtf-cfrg-kangarootwelve@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d0865005b179a8de" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 13:56:10 -0000 --000000000000d0865005b179a8de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jean-Philippe, >> (Maybe, Jean-Philippe could you confirm? Could you please confirm that you are happy with the changes?.. Regards, Stanislav On Mon, 5 Oct 2020 at 11:04, Gilles VAN ASSCHE wrote: > Dear Alexey, > > > > Thanks to Jean-Philippe and Thomas for their comments. > > > > We think all comments have been addressed. (Maybe, Jean-Philippe could yo= u > confirm?) If indeed the case, can you help to move the document forward ? > > > > Thanks & kind regards, > > Beno=C3=AEt, David, Gilles, Joan and Quynh > > > > > > *From:* Thomas Pornin > *Sent:* Monday, 21 September 2020 16:18 > *To:* Beno=C3=AEt Viguier ; Alexey Melnikov < > alexey.melnikov@isode.com>; draft-irtf-cfrg-kangarootwelve@ietf.org; > crypto-panel@irtf.org > *Subject:* Re: EXTERNAL: Re: [Crypto-panel] Request for review: > draft-irtf-cfrg-kangarootwelve-02 > > > > I am not in a good position to make comments on delays, since I also let > this email sleep for three weeks... > > > > Your changes look good to me. > > > > I like the idea that the bulk of the data processing in HopMAC has no > dependency on the key; it has indeed strong benefits with regard to side > channel attacks. Of course, it unavoidably implies that HopMAC relies on > the collision resistance of the keyless hash function. In the aftermath o= f > the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of > shunning collision resistance, and insisting on using only > (second-)preimage resistance; that's how, for instance, Ed25519 signature= s > in "pure" mode insist on generating the challenge as H(pkey+R+message) an= d > not H(pkey+R+H(message)). This trend implies some practical limitations > (e.g. "pure" Ed25519 signatures make it much more difficult to process > X.509 certificates in memory-constrained environments). I think your choi= ce > in HopMAC is a better trade-off; keyless processing of the bulk of the da= ta > has tangible practical benefits, and if K12 is not collision-resistant th= en > the foundation of its other security properties becomes quite flaky. > > > > Thomas > > > > *From: *Beno=C3=AEt Viguier > *Date: *Tuesday, September 1, 2020 at 10:38 > *To: *Thomas Pornin , Alexey Melnikov < > alexey.melnikov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org" < > draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org" < > crypto-panel@irtf.org> > *Subject: *Re: EXTERNAL: Re: [Crypto-panel] Request for review: > draft-irtf-cfrg-kangarootwelve-02 > > > > Dear Thomas, Dear Alexey, Dear Crypto Panel members, > > We would like to thank you for your time into reviewing our draft > and providing us with your constructive comments. > > We apologize for the delays (corona & vacations...) and provide you here > with > our modifications to the draft: > https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa5= 7e9e34121951da2764b5ed73df988 > > . > > On 7/17/20 11:57 PM, Thomas Pornin wrote: > > Here is my review of draft-irtf-cfrg-kangarootwelve-02: > > > > General comments: > > > > The function is well described. The specification is not self-contained > > since it relies on FIPS 202, but that's not a problem in my opinion (ther= e > > already are other RFCs that reference FIPS 202). > > > > The function already exists and is specified in a note published on > > eprint since 2016, so there is no point in changing it now; this is an > > RFC that describes an existing situation, not one that introduces new > > stuff (otherwise, I would insist, for aesthetical reasons, on making > > length_encode() use little-endian instead of the current big-endian). > > Additionally we added links to the publications at the ACNS > conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing. > > Some poor soul, somewhere, will want to make a MAC out of K12 and will > > try to use it in HMAC. This is probably not a very good idea, though > > it won't be weak. HMAC requires knowledge of the "block size" of the > > algorithm, so that block size should be specified somewhere. Intuitively, > > I suppose the "block size" is 168 bytes, but it would be better to state > > it explicitly somewhere. > > > > Also, some guidance about a better way to turn K12 into a MAC would be > > helpful. Normally, a simple K12(key || data) would be enough, provided > > that the concatenation of 'key' and 'data' is unambiguous. It is > > tempting to use the key as customization string, but then, you do not > > have a customization string anymore. A related question is whether the > > MAC output length should be part of the input/customization string. > > We added a paragraph on that subject in the Security Consideration sectio= n. > We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to describe > a way to build a MAC from K12. > > Particular comments: > > > > page 2: "splits the input message in fragments" -> "splits ... into > fragments" > > (also page 3) > > Edited. > > page 3: "does not have overhead": this is a bold statement. What is mean= t > > here is that the tree hashing mode of K12 does not introduce _additional_ > > overhead (due to the tree hashing mode) compared with, say, SHAKE; but > > there remains the elementary overhead which makes it so that, for instanc= e, > > hashing 10 bytes is not less expensive than hashing 120 bytes. > > > > Speaking of overhead, it may be worth pointing out that the tree mode > > implies maintaining two separate Keccak contexts (at least for inputs > > longer than 8192 bytes), hence double the RAM usage; this may matter > > for constrained embedded devices (i.e. low-end smartcards and > > microcontrollers, where 200 bytes of RAM are a lot). > > > > page 4: "from n to m exclusive" is a bit confusing since byte at index m > > is excluded, but byte at index n is included. Maybe: "selection of bytes > from > > index n (inclusive) to m (exclusive)"? Also say somewhere that the first > > byte of a string has index 0 (i.e. this is C/Rust, not Pascal). > > Edited. > > page 4: "x**y denotes x multiplied by itself y times" -> this would > > actually be x**(y+1) (if you multiply x by itself _once_, you get x*x). > > Edited. > > page 4: "the number of output bytes requested" -> this lacks a verb; > > probably: "is the requested number of output bytes" > > Edited. > > page 5: "First the message is padded with zeroes to the closest multiple = of > > 168 bytes. Then a byte `80` is XORed to the last byte of the padded > > message. and the resulting string is split into a sequence of 168-byte > > blocks." > > -> This could be made clearer, first to indicate that it is the length, > > in bytes, of the padded message which is to be a multiple of 168; also, > > that the "closest" is really a rounding-up (e.g. with a 169-byte input, > > we really need to append 167 other bytes, even though 168 is arguably > > much closer to 169 than 336). There should be an explicit specification > > about what to do if the input size already has a size multiple of 168: > > should we add 168 extra bytes of value zero, or none at all? Note that, > > in the latter case, there must be a special case for an input of length > > 0: if the padded input consists of no byte at all, then it becomes > > difficult to XOR 0x80 into "the last byte". > > We clarify that the length of the F function is positive. > This resolve the problem of inputs consisting of no bytes. > In the definition of KangarooTwelve in section 2.2, there are no calls to= F > with input of length 0. > > We clarify the rounding up to the next multiple of 168. > > (Three paragraphs later, we learn that the input length is at least > > 1 byte, which avoids any issue related to a zero-length input; this > > should probably be explained a bit earlier in the text.) > > Edited. > > page 11: "against all attacks" (end of first paragraph of section 5): > > this lacks a final dot. > > Edited. > > > > Thomas > > We are open to any additional feedback. > > -- > > Kind regards, > > > > Beno=C3=AEt Viguier > > Software Engineer - PhD Student | Cryptography & Formal Methods > > Radboud University | Mercator 1, Toernooiveld 212 > > 6525 EC Nijmegen, the Netherlands | www.viguier.nl > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --000000000000d0865005b179a8de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jean-Philippe,

>>=C2=A0(Maybe, Jean-Philippe could you confirm?
Co= uld you please confirm that you are happy with the changes?..
<= div>
Regards,
Stanislav


On Mon, 5 Oct 2020 at 11:04, Gille= s VAN ASSCHE <gilles.vanassche@st.com> wrote:

Dear Alexey,

=C2=A0

Thanks to Jean-Philippe and Thomas for their com= ments.

=C2=A0

We think all comments have been addressed. (Mayb= e, Jean-Philippe could you confirm?) If indeed the case, can you help to mo= ve the document forward ?

=C2=A0

Thanks & kind regards,<= /p>

Beno=C3=AEt, David, Gilles, Joan and Quynh

=C2=A0

=C2=A0

From: Thomas Pornin <thomas.pornin@nccgroup.com>
Sent: Monday, 21 September 2020 16:18
To: Beno=C3=AEt Viguier <b.viguier@cs.ru.nl>; Alexey Melnikov <alexey.melnikov@isode.c= om>; draft-irtf-cfrg-kangarootwelve@ietf.org; crypto-panel@irtf.org
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

I am not in a good po= sition to make comments on delays, since I also let this email sleep for th= ree weeks...

=C2=A0<= /span>

Your changes look goo= d to me.

=C2=A0<= /span>

I like the idea that = the bulk of the data processing in HopMAC has no dependency on the key; it = has indeed strong benefits with regard to side channel attacks. Of course, = it unavoidably implies that HopMAC relies on the collision resistance of the keyless hash function. In the af= termath of the MD5 and SHA-1 attacks (in the 2000s), there has been a trend= of shunning collision resistance, and insisting on using only (second-)pre= image resistance; that's how, for instance, Ed25519 signatures in "pure" mode insist on generating= the challenge as H(pkey+R+message) and not H(pkey+R+H(message)). This tren= d implies some practical limitations (e.g. "pure" Ed25519 signatu= res make it much more difficult to process X.509 certificates in memory-constrained environments). I think your choice in HopMAC is a be= tter trade-off; keyless processing of the bulk of the data has tangible pra= ctical benefits, and if K12 is not collision-resistant then the foundation = of its other security properties becomes quite flaky.

=C2=A0<= /span>

Thomas<= /span>

=C2=A0<= /span>

From: = Beno=C3=AEt Viguier &= lt;b.viguier@cs.ru.= nl>
Date: Tuesday, September 1, 2020 at 10:38
To: Thomas Pornin <thomas.pornin@nccgroup.com>, Alexey Melnikov <<= a href=3D"mailto:alexey.melnikov@isode.com" target=3D"_blank">alexey.melnik= ov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org&q= uot; <draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org&quo= t; <crypto-pa= nel@irtf.org>
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

Dear Thomas, Dear Alexey, Dear = Crypto Panel members,

We would like to thank you for your time into revie= wing our draft
and providing us with your constructive comments.

We apologize for the delays (corona & vacations= ...) and provide you here with
our modifications to the draft: https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e= 9e34121951da2764b5ed73df988 .

On 7/17/20 11:57 PM, Thomas Por= nin wrote:

Here is my review of draft-irtf-cfrg-kangarootwelve-02:

=C2=A0

General comments:

=C2=A0

The function is well described. The specification is not self-contained<= span lang=3D"EN-CA">

since it relies on FIPS 202, but that's not a problem in my opinion = (there

already are other RFCs that reference FIPS 202).=

=C2=A0

The function already exists and is specified in a note published on

eprint since 2016, so there is no point in changing it now; this is an

RFC that describes an existing situation, not one that introduces new

stuff (otherwise, I would insist, for aesthetical reasons, on making

length_encode() use little-endian instead of the current big-endian).

Additi= onally we added links to the publications at the ACNS
conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing.

Some poor soul, somewhere, will want to make a MAC out of K12 and will

try to use it in HMAC. This is probably not a very good idea, though

it won't be weak. HMAC requires knowledge of the "block size&qu= ot; of the

algorithm, so that block size should be specified somewhere. Intuitively= ,

I suppose the "block size" is 168 bytes, but it would be bette= r to state

it explicitly somewhere.

=C2=A0

Also, some guidance about a better way to turn K12 into a MAC would be

helpful. Normally, a simple K12(key || data) would be enough, provided

that the concatenation of 'key' and 'data' is unambiguou= s. It is

tempting to use the key as customization string, but then, you do not

have a customization string anymore. A related question is whether the

MAC output length should be part of the input/customization string.

We added a paragraph on that subject in the Security= Consideration section.
We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to describe a way to build a MAC from K12.

Particular comments:

=C2=A0

page 2: "splits the input message in fragments" -> "sp= lits ... into fragments"

(also page 3)

Edited.

=C2=A0page 3: "does not have overhead": this is a bold stateme= nt. What is meant

here is that the tree hashing mode of K12 does not introduce _additional= _

overhead (due to the tree hashing mode) compared with, say, SHAKE; but

there remains the elementary overhead which makes it so that, for instan= ce,

hashing 10 bytes is not less expensive than hashing 120 bytes.

=C2=A0

Speaking of overhead, it may be worth pointing out that the tree mode

implies maintaining two separate Keccak contexts (at least for inputs

longer than 8192 bytes), hence double the RAM usage; this may matter

for constrained embedded devices (i.e. low-end smartcards and

microcontrollers, where 200 bytes of RAM are a lot).

=C2=A0

page 4: "from n to m exclusive" is a bit confusing since byte = at index m

is excluded, but byte at index n is included. Maybe: "selection of = bytes from

index n (inclusive) to m (exclusive)"? Also say somewhere that the = first

byte of a string has index 0 (i.e. this is C/Rust, not Pascal).

Edited.

page 4: "x**y denotes x multiplied by itself y times" -> th= is would

actually be x**(y+1) (if you multiply x by itself _once_, you get x*x).<= span lang=3D"EN-CA">

Edited.

page 4: "the number of output bytes requested" -> this lack= s a verb;

probably: "is the requested number of output bytes"

Edited.

page 5: "First the message is padded with zeroes to the closest mul= tiple of

168 bytes.=C2=A0 Then a byte `80` is XORed to the last byte of the padde= d

message.=C2=A0 and the resulting string is split into a sequence of 168-= byte

blocks."

-> This could be made clearer, first to indicate that it is the lengt= h,

in bytes, of the padded message which is to be a multiple of 168; also,<= span lang=3D"EN-CA">

that the "closest" is really a rounding-up (e.g. with a 169-by= te input,

we really need to append 167 other bytes, even though 168 is arguably

much closer to 169 than 336). There should be an explicit specification<= span lang=3D"EN-CA">

about what to do if the input size already has a size multiple of 168:

should we add 168 extra bytes of value zero, or none at all? Note that,<= span lang=3D"EN-CA">

in the latter case, there must be a special case for an input of length<= span lang=3D"EN-CA">

0: if the padded input consists of no byte at all, then it becomes

difficult to XOR 0x80 into "the last byte".

We cla= rify that the length of the F function is positive.
This resolve the problem of inputs consisting of no bytes.
In the definition of KangarooTwelve in section 2.2, there are no calls to F=
with input of length 0.

We clarify the rounding up to the next multiple of = 168.

(Three paragraphs later, we learn that the input length is at least

1 byte, which avoids any issue related to a zero-length input; this

should probably be explained a bit earlier in the text.)

Edited.

=C2=A0page 11: "against all attacks" (end of first paragraph o= f section 5):

this lacks a final dot.

Edited.

=C2=A0

Thomas

We are open to any additional feedback.

-- 
Kind regards,
=C2=A0
Beno=C3=AEt Viguier
Software Engineer - PhD Student | Cryptography &a=
mp; Formal Methods
Radboud University | Mercator 1, Toernooiveld 212=

6525 EC Nijmegen, the Netherlands | www.viguier.nl
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--000000000000d0865005b179a8de-- From nobody Mon Oct 12 07:02:24 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF43A14F8 for ; Mon, 12 Oct 2020 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=2.331, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9Vv9sgeNtUpS for ; Mon, 12 Oct 2020 07:02:20 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02383A1500 for ; Mon, 12 Oct 2020 07:02:19 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id b8so6111793wrn.0 for ; Mon, 12 Oct 2020 07:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NdLkXWxH1y+tWqSmAORbaNOWvGhsokJP0cJxxZjsczc=; b=lvuLsEiljRVN09FkdFGNgrJwned3pg2824oRUbM5UpnYCkKHUM3WgsIDjAWViGMWPI haX7ks3gIVXNwDDSfn9EVZRE5A51vCITRrtoSGSIEK0svz/TswlRq22RP6cPvGkx89Qm NPk/XgHWQzCDCJGT/OM9+2xQgHjKHoI6Xsis7P+mH2MFkPgy+2vvMH4no3ayLUOSooKP cPgH3du+NoF6uOT+AHDGwQn4OiA6z/P6FgF2isQV/WJ7G0UtGzy/BO3ooWme//I+XNaZ juSgwGiUZ3sTEQ+QwDUqJ0q+LGaZDWUisAik+MKZ7zSNwtTwEWVkEqQ8yHLzDXOl0t5+ Hyhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NdLkXWxH1y+tWqSmAORbaNOWvGhsokJP0cJxxZjsczc=; b=qjNLbVJBRgYQ0Vh9aA7hPwpOay4yVqOqNy5jfAd9YZSz2COVLxtm92o9i5b60Eh01n 7+ZYQ3QRGnV64i0Qqe2GI9G3b/AvHulDwEscFpmipWq/MCLX4c/+FoSJxwABZPGc5Ism teWUnrrF2TSX1tuylzJanfIATdPQM/HWlrR7T480VUY8KQI3QdF4FJD064BSmOgurTXt WX47UBZIORG5xTSADdQq2m6Dn7utTRgyjtwwvIejPaPl/Rob20C2CkWVpPgvpW8N5K2Q Jt3NzG0deRRFaSapM9vyVAqwoOx0mfUPM0nDcrTPjm85YamDZuyGD74C8WlagB6fr2tk vC/g== X-Gm-Message-State: AOAM5307vPWFMy9hNSje9lHH8aWd3EqCKKmOrQ5NbdI6clctfHrvEwaw bfam3BksEbNXDROD+rs6fUC20s8rKJoupeUi6Cc= X-Google-Smtp-Source: ABdhPJwLaek6xWoE12CuH/Kov8ukAMcuUaegvKELidNPxvlZ2FNZPX/pAEQdqawWeH5kWqwp1Ly/3CJvTpK4K1+YnL8= X-Received: by 2002:a5d:5701:: with SMTP id a1mr8600161wrv.414.1602511337903; Mon, 12 Oct 2020 07:02:17 -0700 (PDT) MIME-Version: 1.0 References: <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> In-Reply-To: From: Jean-Philippe Aumasson Date: Mon, 12 Oct 2020 16:02:06 +0200 Message-ID: To: "Stanislav V. Smyshlyaev" Cc: Gilles VAN ASSCHE , Alexey Melnikov , Thomas Pornin , "crypto-panel@irtf.org" , =?UTF-8?Q?Beno=C3=AEt_Viguier?= , "draft-irtf-cfrg-kangarootwelve@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b5aa305b179bfca" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:02:23 -0000 --0000000000000b5aa305b179bfca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes looks good to me, thanks for asking! On Mon, Oct 12, 2020 at 3:56 PM Stanislav V. Smyshlyaev wrote: > Dear Jean-Philippe, > > >> (Maybe, Jean-Philippe could you confirm? > Could you please confirm that you are happy with the changes?.. > > Regards, > Stanislav > > > On Mon, 5 Oct 2020 at 11:04, Gilles VAN ASSCHE > wrote: > >> Dear Alexey, >> >> >> >> Thanks to Jean-Philippe and Thomas for their comments. >> >> >> >> We think all comments have been addressed. (Maybe, Jean-Philippe could >> you confirm?) If indeed the case, can you help to move the document forw= ard >> ? >> >> >> >> Thanks & kind regards, >> >> Beno=C3=AEt, David, Gilles, Joan and Quynh >> >> >> >> >> >> *From:* Thomas Pornin >> *Sent:* Monday, 21 September 2020 16:18 >> *To:* Beno=C3=AEt Viguier ; Alexey Melnikov < >> alexey.melnikov@isode.com>; draft-irtf-cfrg-kangarootwelve@ietf.org; >> crypto-panel@irtf.org >> *Subject:* Re: EXTERNAL: Re: [Crypto-panel] Request for review: >> draft-irtf-cfrg-kangarootwelve-02 >> >> >> >> I am not in a good position to make comments on delays, since I also let >> this email sleep for three weeks... >> >> >> >> Your changes look good to me. >> >> >> >> I like the idea that the bulk of the data processing in HopMAC has no >> dependency on the key; it has indeed strong benefits with regard to side >> channel attacks. Of course, it unavoidably implies that HopMAC relies on >> the collision resistance of the keyless hash function. In the aftermath = of >> the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of >> shunning collision resistance, and insisting on using only >> (second-)preimage resistance; that's how, for instance, Ed25519 signatur= es >> in "pure" mode insist on generating the challenge as H(pkey+R+message) a= nd >> not H(pkey+R+H(message)). This trend implies some practical limitations >> (e.g. "pure" Ed25519 signatures make it much more difficult to process >> X.509 certificates in memory-constrained environments). I think your cho= ice >> in HopMAC is a better trade-off; keyless processing of the bulk of the d= ata >> has tangible practical benefits, and if K12 is not collision-resistant t= hen >> the foundation of its other security properties becomes quite flaky. >> >> >> >> Thomas >> >> >> >> *From: *Beno=C3=AEt Viguier >> *Date: *Tuesday, September 1, 2020 at 10:38 >> *To: *Thomas Pornin , Alexey Melnikov < >> alexey.melnikov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org" < >> draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org" < >> crypto-panel@irtf.org> >> *Subject: *Re: EXTERNAL: Re: [Crypto-panel] Request for review: >> draft-irtf-cfrg-kangarootwelve-02 >> >> >> >> Dear Thomas, Dear Alexey, Dear Crypto Panel members, >> >> We would like to thank you for your time into reviewing our draft >> and providing us with your constructive comments. >> >> We apologize for the delays (corona & vacations...) and provide you here >> with >> our modifications to the draft: >> https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa= 57e9e34121951da2764b5ed73df988 >> >> . >> >> On 7/17/20 11:57 PM, Thomas Pornin wrote: >> >> Here is my review of draft-irtf-cfrg-kangarootwelve-02: >> >> >> >> General comments: >> >> >> >> The function is well described. The specification is not self-contained >> >> since it relies on FIPS 202, but that's not a problem in my opinion (the= re >> >> already are other RFCs that reference FIPS 202). >> >> >> >> The function already exists and is specified in a note published on >> >> eprint since 2016, so there is no point in changing it now; this is an >> >> RFC that describes an existing situation, not one that introduces new >> >> stuff (otherwise, I would insist, for aesthetical reasons, on making >> >> length_encode() use little-endian instead of the current big-endian). >> >> Additionally we added links to the publications at the ACNS >> conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing. >> >> Some poor soul, somewhere, will want to make a MAC out of K12 and will >> >> try to use it in HMAC. This is probably not a very good idea, though >> >> it won't be weak. HMAC requires knowledge of the "block size" of the >> >> algorithm, so that block size should be specified somewhere. Intuitively= , >> >> I suppose the "block size" is 168 bytes, but it would be better to state >> >> it explicitly somewhere. >> >> >> >> Also, some guidance about a better way to turn K12 into a MAC would be >> >> helpful. Normally, a simple K12(key || data) would be enough, provided >> >> that the concatenation of 'key' and 'data' is unambiguous. It is >> >> tempting to use the key as customization string, but then, you do not >> >> have a customization string anymore. A related question is whether the >> >> MAC output length should be part of the input/customization string. >> >> We added a paragraph on that subject in the Security Consideration >> section. >> We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to describ= e >> a way to build a MAC from K12. >> >> Particular comments: >> >> >> >> page 2: "splits the input message in fragments" -> "splits ... into >> fragments" >> >> (also page 3) >> >> Edited. >> >> page 3: "does not have overhead": this is a bold statement. What is mea= nt >> >> here is that the tree hashing mode of K12 does not introduce _additional= _ >> >> overhead (due to the tree hashing mode) compared with, say, SHAKE; but >> >> there remains the elementary overhead which makes it so that, for >> instance, >> >> hashing 10 bytes is not less expensive than hashing 120 bytes. >> >> >> >> Speaking of overhead, it may be worth pointing out that the tree mode >> >> implies maintaining two separate Keccak contexts (at least for inputs >> >> longer than 8192 bytes), hence double the RAM usage; this may matter >> >> for constrained embedded devices (i.e. low-end smartcards and >> >> microcontrollers, where 200 bytes of RAM are a lot). >> >> >> >> page 4: "from n to m exclusive" is a bit confusing since byte at index m >> >> is excluded, but byte at index n is included. Maybe: "selection of bytes >> from >> >> index n (inclusive) to m (exclusive)"? Also say somewhere that the first >> >> byte of a string has index 0 (i.e. this is C/Rust, not Pascal). >> >> Edited. >> >> page 4: "x**y denotes x multiplied by itself y times" -> this would >> >> actually be x**(y+1) (if you multiply x by itself _once_, you get x*x). >> >> Edited. >> >> page 4: "the number of output bytes requested" -> this lacks a verb; >> >> probably: "is the requested number of output bytes" >> >> Edited. >> >> page 5: "First the message is padded with zeroes to the closest multiple >> of >> >> 168 bytes. Then a byte `80` is XORed to the last byte of the padded >> >> message. and the resulting string is split into a sequence of 168-byte >> >> blocks." >> >> -> This could be made clearer, first to indicate that it is the length, >> >> in bytes, of the padded message which is to be a multiple of 168; also, >> >> that the "closest" is really a rounding-up (e.g. with a 169-byte input, >> >> we really need to append 167 other bytes, even though 168 is arguably >> >> much closer to 169 than 336). There should be an explicit specification >> >> about what to do if the input size already has a size multiple of 168: >> >> should we add 168 extra bytes of value zero, or none at all? Note that, >> >> in the latter case, there must be a special case for an input of length >> >> 0: if the padded input consists of no byte at all, then it becomes >> >> difficult to XOR 0x80 into "the last byte". >> >> We clarify that the length of the F function is positive. >> This resolve the problem of inputs consisting of no bytes. >> In the definition of KangarooTwelve in section 2.2, there are no calls t= o >> F >> with input of length 0. >> >> We clarify the rounding up to the next multiple of 168. >> >> (Three paragraphs later, we learn that the input length is at least >> >> 1 byte, which avoids any issue related to a zero-length input; this >> >> should probably be explained a bit earlier in the text.) >> >> Edited. >> >> page 11: "against all attacks" (end of first paragraph of section 5): >> >> this lacks a final dot. >> >> Edited. >> >> >> >> Thomas >> >> We are open to any additional feedback. >> >> -- >> >> Kind regards, >> >> >> >> Beno=C3=AEt Viguier >> >> Software Engineer - PhD Student | Cryptography & Formal Methods >> >> Radboud University | Mercator 1, Toernooiveld 212 >> >> 6525 EC Nijmegen, the Netherlands | www.viguier.nl >> >> _______________________________________________ >> Crypto-panel mailing list >> Crypto-panel@irtf.org >> https://www.irtf.org/mailman/listinfo/crypto-panel >> > --0000000000000b5aa305b179bfca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes looks good to me, thanks for asking!

On Mon, Oct 12, 20= 20 at 3:56 PM Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Dear Jean-Philippe,

>>=C2=A0(Maybe, Jean-Philippe could you confirm?
Could you please confirm that you are happy with the chang= es?..

Regards,
Stanislav


On Mon, 5 Oct 2= 020 at 11:04, Gilles VAN ASSCHE <gilles.vanassche@st.com> wrote:

Dear Alexey,

=C2=A0

Thanks to Jean-Philippe and Thomas for their com= ments.

=C2=A0

We think all comments have been addressed. (Mayb= e, Jean-Philippe could you confirm?) If indeed the case, can you help to mo= ve the document forward ?

=C2=A0

Thanks & kind regards,<= /p>

Beno=C3=AEt, David, Gilles, Joan and Quynh

=C2=A0

=C2=A0

From: Thomas Pornin <thomas.pornin@nccgroup.com>
Sent: Monday, 21 September 2020 16:18
To: Beno=C3=AEt Viguier <b.viguier@cs.ru.nl>; Alexey Melnikov <alexey.melnikov@isode.c= om>; draft-irtf-cfrg-kangarootwelve@ietf.org; crypto-panel@irtf.org
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

I am not in a good po= sition to make comments on delays, since I also let this email sleep for th= ree weeks...

=C2=A0<= /span>

Your changes look goo= d to me.

=C2=A0<= /span>

I like the idea that = the bulk of the data processing in HopMAC has no dependency on the key; it = has indeed strong benefits with regard to side channel attacks. Of course, = it unavoidably implies that HopMAC relies on the collision resistance of the keyless hash function. In the af= termath of the MD5 and SHA-1 attacks (in the 2000s), there has been a trend= of shunning collision resistance, and insisting on using only (second-)pre= image resistance; that's how, for instance, Ed25519 signatures in "pure" mode insist on generating= the challenge as H(pkey+R+message) and not H(pkey+R+H(message)). This tren= d implies some practical limitations (e.g. "pure" Ed25519 signatu= res make it much more difficult to process X.509 certificates in memory-constrained environments). I think your choice in HopMAC is a be= tter trade-off; keyless processing of the bulk of the data has tangible pra= ctical benefits, and if K12 is not collision-resistant then the foundation = of its other security properties becomes quite flaky.

=C2=A0<= /span>

Thomas<= /span>

=C2=A0<= /span>

From: = Beno=C3=AEt Viguier &= lt;b.viguier@cs.ru.= nl>
Date: Tuesday, September 1, 2020 at 10:38
To: Thomas Pornin <thomas.pornin@nccgroup.com>, Alexey Melnikov <<= a href=3D"mailto:alexey.melnikov@isode.com" target=3D"_blank">alexey.melnik= ov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org&q= uot; <draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org&quo= t; <crypto-pa= nel@irtf.org>
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

Dear Thomas, Dear Alexey, Dear = Crypto Panel members,

We would like to thank you for your time into revie= wing our draft
and providing us with your constructive comments.

We apologize for the delays (corona & vacations= ...) and provide you here with
our modifications to the draft: https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e= 9e34121951da2764b5ed73df988 .

On 7/17/20 11:57 PM, Thomas Por= nin wrote:

Here is my review of draft-irtf-cfrg-kangarootwelve-02:

=C2=A0

General comments:

=C2=A0

The function is well described. The specification is not self-contained<= span lang=3D"EN-CA">

since it relies on FIPS 202, but that's not a problem in my opinion = (there

already are other RFCs that reference FIPS 202).=

=C2=A0

The function already exists and is specified in a note published on

eprint since 2016, so there is no point in changing it now; this is an

RFC that describes an existing situation, not one that introduces new

stuff (otherwise, I would insist, for aesthetical reasons, on making

length_encode() use little-endian instead of the current big-endian).

Additi= onally we added links to the publications at the ACNS
conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing.

Some poor soul, somewhere, will want to make a MAC out of K12 and will

try to use it in HMAC. This is probably not a very good idea, though

it won't be weak. HMAC requires knowledge of the "block size&qu= ot; of the

algorithm, so that block size should be specified somewhere. Intuitively= ,

I suppose the "block size" is 168 bytes, but it would be bette= r to state

it explicitly somewhere.

=C2=A0

Also, some guidance about a better way to turn K12 into a MAC would be

helpful. Normally, a simple K12(key || data) would be enough, provided

that the concatenation of 'key' and 'data' is unambiguou= s. It is

tempting to use the key as customization string, but then, you do not

have a customization string anymore. A related question is whether the

MAC output length should be part of the input/customization string.

We added a paragraph on that subject in the Security= Consideration section.
We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to describe a way to build a MAC from K12.

Particular comments:

=C2=A0

page 2: "splits the input message in fragments" -> "sp= lits ... into fragments"

(also page 3)

Edited.

=C2=A0page 3: "does not have overhead": this is a bold stateme= nt. What is meant

here is that the tree hashing mode of K12 does not introduce _additional= _

overhead (due to the tree hashing mode) compared with, say, SHAKE; but

there remains the elementary overhead which makes it so that, for instan= ce,

hashing 10 bytes is not less expensive than hashing 120 bytes.

=C2=A0

Speaking of overhead, it may be worth pointing out that the tree mode

implies maintaining two separate Keccak contexts (at least for inputs

longer than 8192 bytes), hence double the RAM usage; this may matter

for constrained embedded devices (i.e. low-end smartcards and

microcontrollers, where 200 bytes of RAM are a lot).

=C2=A0

page 4: "from n to m exclusive" is a bit confusing since byte = at index m

is excluded, but byte at index n is included. Maybe: "selection of = bytes from

index n (inclusive) to m (exclusive)"? Also say somewhere that the = first

byte of a string has index 0 (i.e. this is C/Rust, not Pascal).

Edited.

page 4: "x**y denotes x multiplied by itself y times" -> th= is would

actually be x**(y+1) (if you multiply x by itself _once_, you get x*x).<= span lang=3D"EN-CA">

Edited.

page 4: "the number of output bytes requested" -> this lack= s a verb;

probably: "is the requested number of output bytes"

Edited.

page 5: "First the message is padded with zeroes to the closest mul= tiple of

168 bytes.=C2=A0 Then a byte `80` is XORed to the last byte of the padde= d

message.=C2=A0 and the resulting string is split into a sequence of 168-= byte

blocks."

-> This could be made clearer, first to indicate that it is the lengt= h,

in bytes, of the padded message which is to be a multiple of 168; also,<= span lang=3D"EN-CA">

that the "closest" is really a rounding-up (e.g. with a 169-by= te input,

we really need to append 167 other bytes, even though 168 is arguably

much closer to 169 than 336). There should be an explicit specification<= span lang=3D"EN-CA">

about what to do if the input size already has a size multiple of 168:

should we add 168 extra bytes of value zero, or none at all? Note that,<= span lang=3D"EN-CA">

in the latter case, there must be a special case for an input of length<= span lang=3D"EN-CA">

0: if the padded input consists of no byte at all, then it becomes

difficult to XOR 0x80 into "the last byte".

We cla= rify that the length of the F function is positive.
This resolve the problem of inputs consisting of no bytes.
In the definition of KangarooTwelve in section 2.2, there are no calls to F=
with input of length 0.

We clarify the rounding up to the next multiple of = 168.

(Three paragraphs later, we learn that the input length is at least

1 byte, which avoids any issue related to a zero-length input; this

should probably be explained a bit earlier in the text.)

Edited.

=C2=A0page 11: "against all attacks" (end of first paragraph o= f section 5):

this lacks a final dot.

Edited.

=C2=A0

Thomas

We are open to any additional feedback.

-- 
Kind regards,
=C2=A0
Beno=C3=AEt Viguier
Software Engineer - PhD Student | Cryptography &a=
mp; Formal Methods
Radboud University | Mercator 1, Toernooiveld 212=

6525 EC Nijmegen, the Netherlands | www.viguier.nl
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000000b5aa305b179bfca-- From nobody Mon Oct 12 07:03:39 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36A3A153C for ; Mon, 12 Oct 2020 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=2.331, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 V-ArnXgJgJjh for ; Mon, 12 Oct 2020 07:03:29 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FAE3A1511 for ; Mon, 12 Oct 2020 07:03:29 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id dt13so23345163ejb.12 for ; Mon, 12 Oct 2020 07:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZShOaKOVSvNS0E96uXY8o22wKaVm1eXx8qd9sWMAIGg=; b=EQNYOc/pQEAuCCLYF88Cm7jkb4zmGPv5nKfXrFacIXl+pzzOzu1E3slTB/dyIkDSe9 69G7q6AHyJ4GIiBNLro34GO2J+75tx3jsJv4ccKkUp3oXHSNlzb37UJ8dXyiA9siALtX g59d8KZHXOx0Z8LleguZbyz34wGs+Xfy9SnEAdXb5E91rCCKfF8uSkSSdOyFjSv3TDCn 42TDA7kQPCC/logvFKMRJcJ3ClUCxMyPOyV2cNwKiiZoQVApmUbBhARUQxvaUVl7X7ot DgkFiZB/AtWI8UUKspM0JDHCk/chDzuwGN3v9PRjnAzz7KTBs7u1RDxVA1JW+eNiqQG8 OPuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZShOaKOVSvNS0E96uXY8o22wKaVm1eXx8qd9sWMAIGg=; b=dGUXNReIZHzV8tXZwTBdTEPJbC9NP5QQxeHKg8wpd3n3FsRbCie6mzr3b7cXpHzVC5 4NY65BZslc9c0HxKeuyhpKNvzm5OvpGtxqyRZpAFvSseAdMAXdjI6pqR+IPOBLaKu7At h6H5DSs1AZxcaq7L5/4GFzjfeNlmoXDMQvtjY6CkrbdgFtgCVAQIXtmF3M8uo+QKpp9G mVBiQp0tNk2m/w+OZB/ZOEL7lmnslsjTaF0Lpaa7/bIsU1xfZQWpLh4ORXAXf/64lfP9 M6a2vqBw32z2yjjbiIys5e62d3z6Y4pu8G+uqt4Kb5kOCoiAebmHxjuZlS4G/txbUhRM I2/w== X-Gm-Message-State: AOAM531tiywNd15SQBYzCGAYYJYZucy0ptbW28D9vvP3dqTOgwV3ZSwj DD6mmc+wH1RlUwCnrMsUjlaGelCJhxQEBLQCiJc= X-Google-Smtp-Source: ABdhPJxzgRVNUuT3tg7hMsZSBnRQkHLyOSOma5clndqMdQmFMP7IRRRJxG6zpFc4fmfJGf7zBF2mHTpEVgl+zB0xzKY= X-Received: by 2002:a17:906:4316:: with SMTP id j22mr3009893ejm.405.1602511407646; Mon, 12 Oct 2020 07:03:27 -0700 (PDT) MIME-Version: 1.0 References: <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 12 Oct 2020 17:06:15 +0300 Message-ID: To: Jean-Philippe Aumasson Cc: Gilles VAN ASSCHE , Alexey Melnikov , Thomas Pornin , "crypto-panel@irtf.org" , =?UTF-8?Q?Beno=C3=AEt_Viguier?= , "draft-irtf-cfrg-kangarootwelve@ietf.org" Content-Type: multipart/alternative; boundary="000000000000338d1705b179c3d2" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:03:38 -0000 --000000000000338d1705b179c3d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great, thanks a lot! On Mon, 12 Oct 2020 at 17:02, Jean-Philippe Aumasson < jeanphilippe.aumasson@gmail.com> wrote: > Yes looks good to me, thanks for asking! > > On Mon, Oct 12, 2020 at 3:56 PM Stanislav V. Smyshlyaev > wrote: > >> Dear Jean-Philippe, >> >> >> (Maybe, Jean-Philippe could you confirm? >> Could you please confirm that you are happy with the changes?.. >> >> Regards, >> Stanislav >> >> >> On Mon, 5 Oct 2020 at 11:04, Gilles VAN ASSCHE >> wrote: >> >>> Dear Alexey, >>> >>> >>> >>> Thanks to Jean-Philippe and Thomas for their comments. >>> >>> >>> >>> We think all comments have been addressed. (Maybe, Jean-Philippe could >>> you confirm?) If indeed the case, can you help to move the document for= ward >>> ? >>> >>> >>> >>> Thanks & kind regards, >>> >>> Beno=C3=AEt, David, Gilles, Joan and Quynh >>> >>> >>> >>> >>> >>> *From:* Thomas Pornin >>> *Sent:* Monday, 21 September 2020 16:18 >>> *To:* Beno=C3=AEt Viguier ; Alexey Melnikov < >>> alexey.melnikov@isode.com>; draft-irtf-cfrg-kangarootwelve@ietf.org; >>> crypto-panel@irtf.org >>> *Subject:* Re: EXTERNAL: Re: [Crypto-panel] Request for review: >>> draft-irtf-cfrg-kangarootwelve-02 >>> >>> >>> >>> I am not in a good position to make comments on delays, since I also le= t >>> this email sleep for three weeks... >>> >>> >>> >>> Your changes look good to me. >>> >>> >>> >>> I like the idea that the bulk of the data processing in HopMAC has no >>> dependency on the key; it has indeed strong benefits with regard to sid= e >>> channel attacks. Of course, it unavoidably implies that HopMAC relies o= n >>> the collision resistance of the keyless hash function. In the aftermath= of >>> the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of >>> shunning collision resistance, and insisting on using only >>> (second-)preimage resistance; that's how, for instance, Ed25519 signatu= res >>> in "pure" mode insist on generating the challenge as H(pkey+R+message) = and >>> not H(pkey+R+H(message)). This trend implies some practical limitations >>> (e.g. "pure" Ed25519 signatures make it much more difficult to process >>> X.509 certificates in memory-constrained environments). I think your ch= oice >>> in HopMAC is a better trade-off; keyless processing of the bulk of the = data >>> has tangible practical benefits, and if K12 is not collision-resistant = then >>> the foundation of its other security properties becomes quite flaky. >>> >>> >>> >>> Thomas >>> >>> >>> >>> *From: *Beno=C3=AEt Viguier >>> *Date: *Tuesday, September 1, 2020 at 10:38 >>> *To: *Thomas Pornin , Alexey Melnikov < >>> alexey.melnikov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org" < >>> draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org" < >>> crypto-panel@irtf.org> >>> *Subject: *Re: EXTERNAL: Re: [Crypto-panel] Request for review: >>> draft-irtf-cfrg-kangarootwelve-02 >>> >>> >>> >>> Dear Thomas, Dear Alexey, Dear Crypto Panel members, >>> >>> We would like to thank you for your time into reviewing our draft >>> and providing us with your constructive comments. >>> >>> We apologize for the delays (corona & vacations...) and provide you her= e >>> with >>> our modifications to the draft: >>> https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423a= a57e9e34121951da2764b5ed73df988 >>> >>> . >>> >>> On 7/17/20 11:57 PM, Thomas Pornin wrote: >>> >>> Here is my review of draft-irtf-cfrg-kangarootwelve-02: >>> >>> >>> >>> General comments: >>> >>> >>> >>> The function is well described. The specification is not self-contained >>> >>> since it relies on FIPS 202, but that's not a problem in my opinion >>> (there >>> >>> already are other RFCs that reference FIPS 202). >>> >>> >>> >>> The function already exists and is specified in a note published on >>> >>> eprint since 2016, so there is no point in changing it now; this is an >>> >>> RFC that describes an existing situation, not one that introduces new >>> >>> stuff (otherwise, I would insist, for aesthetical reasons, on making >>> >>> length_encode() use little-endian instead of the current big-endian). >>> >>> Additionally we added links to the publications at the ACNS >>> conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing= . >>> >>> Some poor soul, somewhere, will want to make a MAC out of K12 and will >>> >>> try to use it in HMAC. This is probably not a very good idea, though >>> >>> it won't be weak. HMAC requires knowledge of the "block size" of the >>> >>> algorithm, so that block size should be specified somewhere. Intuitivel= y, >>> >>> I suppose the "block size" is 168 bytes, but it would be better to stat= e >>> >>> it explicitly somewhere. >>> >>> >>> >>> Also, some guidance about a better way to turn K12 into a MAC would be >>> >>> helpful. Normally, a simple K12(key || data) would be enough, provided >>> >>> that the concatenation of 'key' and 'data' is unambiguous. It is >>> >>> tempting to use the key as customization string, but then, you do not >>> >>> have a customization string anymore. A related question is whether the >>> >>> MAC output length should be part of the input/customization string. >>> >>> We added a paragraph on that subject in the Security Consideration >>> section. >>> We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to descri= be >>> a way to build a MAC from K12. >>> >>> Particular comments: >>> >>> >>> >>> page 2: "splits the input message in fragments" -> "splits ... into >>> fragments" >>> >>> (also page 3) >>> >>> Edited. >>> >>> page 3: "does not have overhead": this is a bold statement. What is >>> meant >>> >>> here is that the tree hashing mode of K12 does not introduce _additiona= l_ >>> >>> overhead (due to the tree hashing mode) compared with, say, SHAKE; but >>> >>> there remains the elementary overhead which makes it so that, for >>> instance, >>> >>> hashing 10 bytes is not less expensive than hashing 120 bytes. >>> >>> >>> >>> Speaking of overhead, it may be worth pointing out that the tree mode >>> >>> implies maintaining two separate Keccak contexts (at least for inputs >>> >>> longer than 8192 bytes), hence double the RAM usage; this may matter >>> >>> for constrained embedded devices (i.e. low-end smartcards and >>> >>> microcontrollers, where 200 bytes of RAM are a lot). >>> >>> >>> >>> page 4: "from n to m exclusive" is a bit confusing since byte at index = m >>> >>> is excluded, but byte at index n is included. Maybe: "selection of byte= s >>> from >>> >>> index n (inclusive) to m (exclusive)"? Also say somewhere that the firs= t >>> >>> byte of a string has index 0 (i.e. this is C/Rust, not Pascal). >>> >>> Edited. >>> >>> page 4: "x**y denotes x multiplied by itself y times" -> this would >>> >>> actually be x**(y+1) (if you multiply x by itself _once_, you get x*x). >>> >>> Edited. >>> >>> page 4: "the number of output bytes requested" -> this lacks a verb; >>> >>> probably: "is the requested number of output bytes" >>> >>> Edited. >>> >>> page 5: "First the message is padded with zeroes to the closest multipl= e >>> of >>> >>> 168 bytes. Then a byte `80` is XORed to the last byte of the padded >>> >>> message. and the resulting string is split into a sequence of 168-byte >>> >>> blocks." >>> >>> -> This could be made clearer, first to indicate that it is the length, >>> >>> in bytes, of the padded message which is to be a multiple of 168; also, >>> >>> that the "closest" is really a rounding-up (e.g. with a 169-byte input, >>> >>> we really need to append 167 other bytes, even though 168 is arguably >>> >>> much closer to 169 than 336). There should be an explicit specification >>> >>> about what to do if the input size already has a size multiple of 168: >>> >>> should we add 168 extra bytes of value zero, or none at all? Note that, >>> >>> in the latter case, there must be a special case for an input of length >>> >>> 0: if the padded input consists of no byte at all, then it becomes >>> >>> difficult to XOR 0x80 into "the last byte". >>> >>> We clarify that the length of the F function is positive. >>> This resolve the problem of inputs consisting of no bytes. >>> In the definition of KangarooTwelve in section 2.2, there are no calls >>> to F >>> with input of length 0. >>> >>> We clarify the rounding up to the next multiple of 168. >>> >>> (Three paragraphs later, we learn that the input length is at least >>> >>> 1 byte, which avoids any issue related to a zero-length input; this >>> >>> should probably be explained a bit earlier in the text.) >>> >>> Edited. >>> >>> page 11: "against all attacks" (end of first paragraph of section 5): >>> >>> this lacks a final dot. >>> >>> Edited. >>> >>> >>> >>> Thomas >>> >>> We are open to any additional feedback. >>> >>> -- >>> >>> Kind regards, >>> >>> >>> >>> Beno=C3=AEt Viguier >>> >>> Software Engineer - PhD Student | Cryptography & Formal Methods >>> >>> Radboud University | Mercator 1, Toernooiveld 212 >>> >>> 6525 EC Nijmegen, the Netherlands | www.viguier.nl >>> >>> _______________________________________________ >>> Crypto-panel mailing list >>> Crypto-panel@irtf.org >>> https://www.irtf.org/mailman/listinfo/crypto-panel >>> >> --000000000000338d1705b179c3d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, thanks a lot!

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, 12 Oct 2020 at 17:02, Jean-Phi= lippe Aumasson <jeanp= hilippe.aumasson@gmail.com> wrote:
Yes looks good to me, thanks for= asking!

On Mon, Oct 12, 2020 at 3:56 PM Stanislav V. Smyshlyaev <smyshsv@gmail.com> w= rote:
Dear Jean-Philippe,

>>=C2=A0(M= aybe, Jean-Philippe could you confirm?
Could you = please confirm that you are happy with the changes?..

Regards,
St= anislav


On Mon, 5 Oct 2020 at 11:04, Gilles VAN = ASSCHE <gil= les.vanassche@st.com> wrote:

Dear Alexey,

=C2=A0

Thanks to Jean-Philippe and Thomas for their com= ments.

=C2=A0

We think all comments have been addressed. (Mayb= e, Jean-Philippe could you confirm?) If indeed the case, can you help to mo= ve the document forward ?

=C2=A0

Thanks & kind regards,<= /p>

Beno=C3=AEt, David, Gilles, Joan and Quynh

=C2=A0

=C2=A0

From: Thomas Pornin <thomas.pornin@nccgroup.com>
Sent: Monday, 21 September 2020 16:18
To: Beno=C3=AEt Viguier <b.viguier@cs.ru.nl>; Alexey Melnikov <alexey.melnikov@isode.c= om>; draft-irtf-cfrg-kangarootwelve@ietf.org; crypto-panel@irtf.org
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

I am not in a good po= sition to make comments on delays, since I also let this email sleep for th= ree weeks...

=C2=A0<= /span>

Your changes look goo= d to me.

=C2=A0<= /span>

I like the idea that = the bulk of the data processing in HopMAC has no dependency on the key; it = has indeed strong benefits with regard to side channel attacks. Of course, = it unavoidably implies that HopMAC relies on the collision resistance of the keyless hash function. In the af= termath of the MD5 and SHA-1 attacks (in the 2000s), there has been a trend= of shunning collision resistance, and insisting on using only (second-)pre= image resistance; that's how, for instance, Ed25519 signatures in "pure" mode insist on generating= the challenge as H(pkey+R+message) and not H(pkey+R+H(message)). This tren= d implies some practical limitations (e.g. "pure" Ed25519 signatu= res make it much more difficult to process X.509 certificates in memory-constrained environments). I think your choice in HopMAC is a be= tter trade-off; keyless processing of the bulk of the data has tangible pra= ctical benefits, and if K12 is not collision-resistant then the foundation = of its other security properties becomes quite flaky.

=C2=A0<= /span>

Thomas<= /span>

=C2=A0<= /span>

From: = Beno=C3=AEt Viguier &= lt;b.viguier@cs.ru.= nl>
Date: Tuesday, September 1, 2020 at 10:38
To: Thomas Pornin <thomas.pornin@nccgroup.com>, Alexey Melnikov <<= a href=3D"mailto:alexey.melnikov@isode.com" target=3D"_blank">alexey.melnik= ov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org&q= uot; <draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org&quo= t; <crypto-pa= nel@irtf.org>
Subject: Re: EXTERNAL: Re: [Crypto-panel] Request for review: draft-= irtf-cfrg-kangarootwelve-02

=C2=A0

Dear Thomas, Dear Alexey, Dear = Crypto Panel members,

We would like to thank you for your time into revie= wing our draft
and providing us with your constructive comments.

We apologize for the delays (corona & vacations= ...) and provide you here with
our modifications to the draft: https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e= 9e34121951da2764b5ed73df988 .

On 7/17/20 11:57 PM, Thomas Por= nin wrote:

Here is my review of draft-irtf-cfrg-kangarootwelve-02:

=C2=A0

General comments:

=C2=A0

The function is well described. The specification is not self-contained<= span lang=3D"EN-CA">

since it relies on FIPS 202, but that's not a problem in my opinion = (there

already are other RFCs that reference FIPS 202).=

=C2=A0

The function already exists and is specified in a note published on

eprint since 2016, so there is no point in changing it now; this is an

RFC that describes an existing situation, not one that introduces new

stuff (otherwise, I would insist, for aesthetical reasons, on making

length_encode() use little-endian instead of the current big-endian).

Additi= onally we added links to the publications at the ACNS
conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing.

Some poor soul, somewhere, will want to make a MAC out of K12 and will

try to use it in HMAC. This is probably not a very good idea, though

it won't be weak. HMAC requires knowledge of the "block size&qu= ot; of the

algorithm, so that block size should be specified somewhere. Intuitively= ,

I suppose the "block size" is 168 bytes, but it would be bette= r to state

it explicitly somewhere.

=C2=A0

Also, some guidance about a better way to turn K12 into a MAC would be

helpful. Normally, a simple K12(key || data) would be enough, provided

that the concatenation of 'key' and 'data' is unambiguou= s. It is

tempting to use the key as customization string, but then, you do not

have a customization string anymore. A related question is whether the

MAC output length should be part of the input/customization string.

We added a paragraph on that subject in the Security= Consideration section.
We present HopMAC(K, M, C, L) =3D K12( Key, K12(M, C, 32), L) to describe a way to build a MAC from K12.

Particular comments:

=C2=A0

page 2: "splits the input message in fragments" -> "sp= lits ... into fragments"

(also page 3)

Edited.

=C2=A0page 3: "does not have overhead": this is a bold stateme= nt. What is meant

here is that the tree hashing mode of K12 does not introduce _additional= _

overhead (due to the tree hashing mode) compared with, say, SHAKE; but

there remains the elementary overhead which makes it so that, for instan= ce,

hashing 10 bytes is not less expensive than hashing 120 bytes.

=C2=A0

Speaking of overhead, it may be worth pointing out that the tree mode

implies maintaining two separate Keccak contexts (at least for inputs

longer than 8192 bytes), hence double the RAM usage; this may matter

for constrained embedded devices (i.e. low-end smartcards and

microcontrollers, where 200 bytes of RAM are a lot).

=C2=A0

page 4: "from n to m exclusive" is a bit confusing since byte = at index m

is excluded, but byte at index n is included. Maybe: "selection of = bytes from

index n (inclusive) to m (exclusive)"? Also say somewhere that the = first

byte of a string has index 0 (i.e. this is C/Rust, not Pascal).

Edited.

page 4: "x**y denotes x multiplied by itself y times" -> th= is would

actually be x**(y+1) (if you multiply x by itself _once_, you get x*x).<= span lang=3D"EN-CA">

Edited.

page 4: "the number of output bytes requested" -> this lack= s a verb;

probably: "is the requested number of output bytes"

Edited.

page 5: "First the message is padded with zeroes to the closest mul= tiple of

168 bytes.=C2=A0 Then a byte `80` is XORed to the last byte of the padde= d

message.=C2=A0 and the resulting string is split into a sequence of 168-= byte

blocks."

-> This could be made clearer, first to indicate that it is the lengt= h,

in bytes, of the padded message which is to be a multiple of 168; also,<= span lang=3D"EN-CA">

that the "closest" is really a rounding-up (e.g. with a 169-by= te input,

we really need to append 167 other bytes, even though 168 is arguably

much closer to 169 than 336). There should be an explicit specification<= span lang=3D"EN-CA">

about what to do if the input size already has a size multiple of 168:

should we add 168 extra bytes of value zero, or none at all? Note that,<= span lang=3D"EN-CA">

in the latter case, there must be a special case for an input of length<= span lang=3D"EN-CA">

0: if the padded input consists of no byte at all, then it becomes

difficult to XOR 0x80 into "the last byte".

We cla= rify that the length of the F function is positive.
This resolve the problem of inputs consisting of no bytes.
In the definition of KangarooTwelve in section 2.2, there are no calls to F=
with input of length 0.

We clarify the rounding up to the next multiple of = 168.

(Three paragraphs later, we learn that the input length is at least

1 byte, which avoids any issue related to a zero-length input; this

should probably be explained a bit earlier in the text.)

Edited.

=C2=A0page 11: "against all attacks" (end of first paragraph o= f section 5):

this lacks a final dot.

Edited.

=C2=A0

Thomas

We are open to any additional feedback.

-- 
Kind regards,
=C2=A0
Beno=C3=AEt Viguier
Software Engineer - PhD Student | Cryptography &a=
mp; Formal Methods
Radboud University | Mercator 1, Toernooiveld 212=

6525 EC Nijmegen, the Netherlands | www.viguier.nl
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--000000000000338d1705b179c3d2-- From nobody Mon Oct 26 11:23:47 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A453A0C21 for ; Mon, 26 Oct 2020 11:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BKFGGv6ygVH0 for ; Mon, 26 Oct 2020 11:23:45 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2C83A0D17 for ; Mon, 26 Oct 2020 11:23:44 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id n142so8476566ybf.7 for ; Mon, 26 Oct 2020 11:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f7YoZs8alQFeEC4Y03ETAUNQCrBD53ScNNlAehT2SrU=; b=gLaHi6xafoc0ClADtRJejOhEQaGhqPnuXR9wiMKF0OG2OWV/cN4/Z67vjrFkTCKJ+x y5bANaIBmyVTHGnRLhF765nCrbbUa2GFSe0OUPUU8a3woXZdnMmqkU42DNhYuHPaeN5e rGJgXLh5u4scRg2MJHhMgPODKVofNMNlruc8gKCBN4IY17mxnwS0dvE9CYw1UvbTPMtq uMzjJN0KP/w29ZH+2YdDjZD6mH+bOf/8BmRYwjEe7WYAnCeZP55EIxVyNoP5SxIx/QR2 eSo58EisWMGY9tCTizWGKb/ad0CI5NZjBuV8lIb9OceXl6xjB0SKRohBSZBG1ZejIDrm GDkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f7YoZs8alQFeEC4Y03ETAUNQCrBD53ScNNlAehT2SrU=; b=AKTZ+Qt79Sc4duR9Db22snDJphQNUs/A799lvpI7yBVQaXnHzB1WtKU/gL68uvv/nk teuTHm6KPQ++oMe0oCHhErFl8G8zzn8aWSPwyXFl7ca7ReA/FbyqXIagx6BWFUlWSKoY OcdaZndh+BwXa+gAjkj1C1e/41y1CdtRjLsfFlL7+1Y5gIWMHGNGQssdD0h1hUdr32/s KgEpMy+f+edvOX8JifCu6NeOTlTz2xs8mRXVgG0oPkNlNV3Y2PJx+m4QNgtK+f3jUZ60 kPhGyUgeCqZuA2/OSJcbTgcPR6wd/boMMc5tUzNtygQrxlEDNH2NNJYedE2VeELs2DE8 RcOQ== X-Gm-Message-State: AOAM531mSq3kRD/4om8SW8zn7e71Zp5nENQmEm9ZjI2+M2ZKq7bA129C Lca3uYyTZWw5TDlVHrvUGH4aMJHoU77LROW509U= X-Google-Smtp-Source: ABdhPJzJ/Q+yGoVeuad6sx9qWIzWZObmXEwZwzi+bss411K6bpOLABiMgdAtjDzrnoZsOBjKvNBmQE1nYWOEBS9w7Cc= X-Received: by 2002:a25:3303:: with SMTP id z3mr25355705ybz.9.1603736623966; Mon, 26 Oct 2020 11:23:43 -0700 (PDT) MIME-Version: 1.0 References: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> In-Reply-To: From: Chloe Martindale Date: Mon, 26 Oct 2020 18:23:32 +0000 Message-ID: To: Leonid Reyzin Cc: Alexey Melnikov , crypto-panel@irtf.org, draft-irtf-cfrg-vrf@ietf.org Content-Type: multipart/mixed; boundary="000000000000c910cd05b29707d9" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-vrf-07 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 18:23:47 -0000 --000000000000c910cd05b29707d9 Content-Type: multipart/alternative; boundary="000000000000c910ca05b29707d7" --000000000000c910ca05b29707d7 Content-Type: text/plain; charset="UTF-8" Hi all, apologies again for the delay, my review is now attached. Thanks for your patience! All the best, Chloe On Mon, 14 Sep 2020 at 13:25, Leonid Reyzin wrote: > Thank you, Chloe! I hope you are feeling better! > > Best, > > Leo > > > On Mon, Sep 14, 2020 at 7:36 AM Chloe Martindale < > chloemartindale@gmail.com> wrote: > >> I'm sorry this is on me. I had promised to review it but I've been off >> for several weeks (and wasn't able to work much before that) for health >> reasons. I'm back today and naturally have a bit of a backlog but should be >> able to get to this before the end of the month if that's ok. >> >> All the best, >> Chloe >> >> On Tue, 8 Sep 2020 at 14:19, Leonid Reyzin wrote: >> >>> Hi Everyone, >>> >>> Just a ping on this -- the VRF draft has been waiting for the >>> Crypto Review Panel. I don't know if there's been any progress? Thanks in >>> advance! >>> >>> Leo >>> >>> >>> On Fri, Jun 19, 2020 at 1:04 PM Chloe Martindale < >>> chloemartindale@gmail.com> wrote: >>> >>>> I can do it, but I won't be able to look at it until 2 weeks from now >>>> because of deadlines - I hope that's not too late? >>>> >>>> All the best, >>>> Chloe >>>> >>>> On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, >>>> wrote: >>>> >>>>> Dear Crypto Panel members, >>>>> >>>>> Nick, Stanislav and I would like to ask Crypto Review Panel members >>>>> for >>>>> a review of >>>>> >>>>> >>>>> ("Verifiable Random Functions"). >>>>> >>>>> Chairs are about to start RGLC on the document, so we would like to >>>>> solicit some reviews before that. >>>>> >>>>> >>>>> One or two reviews would be appreciated. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Alexey (on behalf of chairs) >>>>> >>>>> _______________________________________________ >>>>> Crypto-panel mailing list >>>>> Crypto-panel@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/crypto-panel >>>>> >>>> --000000000000c910ca05b29707d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

apologies again for = the delay, my review is now attached. Thanks for your patience!
<= br>
All the best,
Chloe

On Mon, 14 Sep 2020 = at 13:25, Leonid Reyzin <reyzin@cs.b= u.edu> wrote:
Thank you, Chloe! I hope you are feeling better!
=
Best,

=C2=A0Leo


On Mon, Sep 14, 2020 at 7:36 AM Chloe Martindale <chloemartindale@gmail.com>= wrote:
I'm sorry this is on me. I had promised to review it but = I've been off for several weeks (and wasn't able to work much befor= e that) for health reasons. I'm back today and naturally have a bit of = a backlog but should be able to get to this before the end of the month if = that's ok.

All the best,
Chloe

On Tue, 8 Sep 2020 at 14:19, Leonid Reyzin <reyzin@cs.bu.edu> wrote:
Hi Everyone,=

Just a ping on this -- the VRF draft has been waiting f= or the Crypto=C2=A0Review Panel. I don't know if there's been any p= rogress? Thanks in advance!

=C2=A0Leo

On Fri, Jun 19, 2020 at 1:04 PM Chloe Martindale <chloemartindale@gmail.com<= /a>> wrote:
<= div dir=3D"auto">I can do it, but I won't be able to look at it until 2= weeks from now because of deadlines - I hope that's not too late?

All=C2=A0the best,
Chloe

On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, <alexey.melnikov@is= ode.com> wrote:
Dear Crypto Panel members,

Nick, Stanislav and I would like to ask Crypto Review Panel members for a review of
<https://datatra= cker.ietf.org/doc/draft-irtf-cfrg-vrf/?include_text=3D1>
("Verifiable Random Functions").

Chairs are about to start RGLC on the document, so we would like to
solicit some reviews before that.


One or two reviews would be appreciated.


Thank you,

Alexey (on behalf of chairs)

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/c= rypto-panel
--000000000000c910ca05b29707d7-- --000000000000c910cd05b29707d9 Content-Type: application/octet-stream; name=VRF Content-Disposition: attachment; filename=VRF Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kgqvd7q70 T3ZlcmFsbCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhIHZlcnkgd2VsbCB3cml0dGVuIGRvY3VtZW50 LCBwcmVjaXNlIGFuZCBlYXN5IHRvIHJlYWQsIGFuZCBtb3N0bHkgY292ZXJpbmcgZXZlcnl0aGlu ZyB0aGF0IG5lZWRzIHRvIGJlIHRoZXJlLiBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIGl0IGZv ciBjb250aW51aW5nIG9uIGluIHRoZSBDRlJHIHByb2Nlc3MsIG9uY2UgdGhlIHNtYWxsIHRoaW5n cyBpbiB0aGlzIHJldmlldyBhcmUgYWRkcmVzc2VkLiBNeSBvbmx5IHBlcnNvbmFsIHdpc2hlcyBm b3IgYWRkaXRpb25zIHdvdWxkIGJlIChhKSBpbmNsdWRpbmcgc29tZSB0ZWNobmljYWwgZGV0YWls cyBvbiBSU0FWUkYgYW5kIChiKSBhIHN1YnNlY3Rpb24gZGlzY3Vzc2luZyBwcm9zIGFuZCBjb25z IG9mIFJTQVZSRiB2cy4gRUNWUkYuCgpCZWxvdyBhcmUgc29tZSBzbWFsbCBjb21tZW50czoKCkFi c3RyYWN0CgpFbGlwdGljIC0+IEVsbGlwdGljCgoyLgoKIlRoZSBWUkZfaGFzaCBhbGdvcml0aG0g aXMgZGV0ZXJtaW5pc3RpYywgaW4gdGhlIHNlbnNlIHRoYXQgaXQgYWx3YXlzCiAgIHByb2R1Y2Vz IHRoZSBzYW1lIG91dHB1dCBiZXRhIGdpdmVuIGEgcGFpciBvZiBpbnB1dHMgKFNLLCBhbHBoYSku IgotPgoiVGhlIFZSRl9oYXNoIGFsZ29yaXRobSBpcyBkZXRlcm1pbmlzdGljLCBpbiB0aGUgc2Vu c2UgdGhhdCBpdCBhbHdheXMKICAgcHJvZHVjZXMgdGhlIHNhbWUgb3V0cHV0IGJldGEgZ2l2ZW4g dGhlIHNhbWUgcGFpciBvZiBpbnB1dHMgKFNLLCBhbHBoYSkuIgoKCiJOb3RpY2UgdGhhdCB0aGlz IG1lYW5zIHRoYXQKICAgICAgVlJGX2hhc2goU0ssIGFscGhhKSA9IFZSRl9wcm9vZl90b19oYXNo KFZSRl9wcm92ZShTSywgYWxwaGEpKQogICBhbmQgdGh1cyB0aGlzIGRvY3VtZW50IHdpbGwgc3Bl Y2lmeSBWUkZfcHJvdmUgYW5kIFZSRl9wcm9vZl90b19oYXNoCiAgIHJhdGhlciB0aGFuIFZSRl9o YXNoLiIKOiBJIGZpbmQgdGhpcyBsb2dpY2FsIGltcGxpY2F0aW9uIGNvbmZ1c2luZy4gRG8geW91 IG1lYW4gImFuZCBpbiBmYWN0IFZSRl9oYXNoIGlzIGFsd2F5cyBjb21wdXRlZCBpbiB0aGlzIHdh eSwgdGh1cy4uIj8KCjMuMQoKc3VmZmljaWVzIC0+IHN1ZmZpY2VzCgozLjMKCiJBbHNvLCB0aGUg VlJGIG91dHB1dCBiZXRhIGRvZXMgbm90IGxvb2sgcmFuZG9tIHRvIGFueSBwYXJ0eSB0aGF0CiAg IGtub3dzIHZhbGlkIFZSRiBwcm9vZiBwaSBjb3JyZXNwb25kaW5nIHRvIHRoZSBWUkYgaW5wdXQg YWxwaGEiCi0+CiJBbHNvLCB0aGUgVlJGIG91dHB1dCBiZXRhIGRvZXMgbm90IGxvb2sgcmFuZG9t IHRvIGFueSBwYXJ0eSB0aGF0CiAgIGtub3dzIHRoZSB2YWxpZCBWUkYgcHJvb2YgcGkgY29ycmVz cG9uZGluZyB0byB0aGUgVlJGIGlucHV0IGFscGhhIgoKMy40CgoiUHNldWRvcmFuZG9tbmVzcywg YXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMywgZG9lcyBub3QgaG9sZCBpZiB0aGUgVlJGCiAgIGtl eXMgd2VyZSBnZW5lcmF0ZWQgYWR2ZXJzYXJpYWxseS4iCjogVGhpcyBzdGF0ZW1lbnQgaXMgc3Ry b25nZXIgdGhhbiB5b3UgaW50ZW5kLCBJIHRoaW5rLiBTdHJpY3RseSBzcGVha2luZywgdGhpcyBy ZWFkcyBhcyAnYW55IGF0dGFjayBnaXZlcyByaXNlIHRvIG5vbi1wc2V1ZG9yYW5kb20ga2V5cycu IEknbSBub3Qgc3VyZSB3aGF0IHlvdSB3YW50IHRvIHNheSBoZXJlLiBQZXJoYXBzICdBbGdvcml0 aG1zIGZvciBnZW5lcmF0aW5nIHBzZXVkb3JhbmRvbSBrZXlzIGFsbG93IGZvciB0cmFuc3BhcmVu Y3kgaW4gVlJGIGtleSBnZW5lcmF0aW9uLCBlbnN1cmluZyB0aGF0IGtleXMgYXJlIG5vdCBnZW5l cmF0ZWQgYnkgYW4gYWR2ZXJzYXJ5Jz8KCnNhdGlzaWZ5IC0+IHNhdGlzZnkKCjQuIAoKSSBhcHBy ZWNpYXRlIHlvdSBkb24ndCB3YW50IHRvIHJlcGVhdCB0aGluZ3MgZnJvbSBlbHNld2hlcmUsIGJ1 dCBJIHRoaW5rIGl0IHdvdWxkIGFkZCB0byB0aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGRvY3VtZW50 IGlmIHlvdSBhZGRlZCBhIHN1YnNlY3Rpb24gLyBhcHBlbmRpeCBicmllZmx5IHJlY2FsbGluZyB0 aGUgUlNBU1AxIGFuZCBSU0FWUDEgcHJpbWl0aXZlcy4gCgpkZWZpbml0aW9uIG9mIEkyT1NQOiBw ZXJzb25hbGx5IEkgd291bGQgc2F5IHdoYXQgYm90aCBpbnB1dHMgYXJlIGhlcmUuCgo1LgoKVW5k ZXIgJ1R5cGUgY29udmVyc2lvbnMnOiAiaW50ZWdlciBhIHRvIHRvIG9jdGV0IiAtPiAiaW50ZWdl ciBhIHRvIG9jdGV0IgoKNS40LjEuMS4KClVuZGVyIHN0ZXAgNiwgIm9yIEggaXMgRUMgcG9pbnQg YXQgaW5maW5pdHkiOiBJIHRoaW5rIHlvdSBtZWFuICJvciBIIGlzIHRoZSBpZGVudGl0eSBvZiB0 aGUgZWxsaXB0aWMgY3VydmUgZ3JvdXAiIChzaW5jZSB5b3Ugd2FudCB0aGlzIHRvIGJlIGluZGVw ZW5kZW50IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBjaG9pY2UgaGVyZSwgYW5kIHRoZSBwb2ludCBh dCBpbmZpbml0eSBpcyBub3QgdGhlIGlkZW50aXR5IGZvciBhbGwgZm9ybXMgb2YgZWxsaXB0aWMg Y3VydmVzLS1lc3BlY2lhbGx5IHJlbGV2YW50IGlzIHRoYXQgdGhlIGlkZW50aXR5IG9uIEVkd2Fy ZHMgY3VydmVzIGlzICgwLGMpLCBub3QgYSBwb2ludCBhdCBpbmZpbml0eSEpLgoKNS42LjEuCgot SSB0aGluayB0aGF0IHRoZSBkZWZpbml0aW9uIG9mICh0aGlzKSBjb2ZhY3RvciBpcyBub3QgbWVu dGlvbmVkIGFib3ZlIGFueXdoZXJlLgotVW5kZXIgc3RlcCAzLCBhZ2FpbiAicG9pbnQgYXQgaW5m aW5pdHkiIGlzIHVzZWQgaW5zdGVhZCBvZiB0aGUgbW9yZSBnZW5lcmFsIChhbmQgc28gYWx3YXlz IGNvcnJlY3QpICJpZGVudGl0eSIuCi1BbHNvIGZpeCB0aGUgcmVmZXJlbmNlIHRvICJ0aGUgcG9p bnQgYXQgaW5maW5pdHkiIGluIHRoZSBwYXJhZ3JhcGggZm9sbG93aW5nIHRoZSBzdGVwcyAxLTQu Cgo2LCBwYXJhZ3JhcGggMTogImVmZmVjaWVudCIgLT4gImVmZmljaWVudCIKCjY6IGxpbmsgaHR0 cHM6Ly9naXRodWIuY29tL2dvb2dsZS9rZXl0cmFuc3BhcmVuY3kvYmxvYi9tYXN0ZXIvY29yZS92 cmYvdnJmLmdvIGxlYWRzIG5vd2hlcmUKCjcuMSAiKGUuZy4sIGlmIFJTQSBpcyBub3QgcGVybXV0 YXRpb24pIi4gRG8geW91IG1lYW4gbm90IHBlcm11dGF0aW9uLWludmFyaWFudD8KCjcuMS4yICJE aWZmaWUgSGVsbG1hbiIgLT4gIkRpZmZpZS0tSGVsbG1hbiIKCjcuMi4gCgotInRoZSB0aGUgVlJG cyIgLT4gInRoYXQgdGhlIFZSRnMiCi1mb3IgdGhlIHNlY29uZCBidWxsZXQgcG9pbnQsIGRvIHlv dSBoYXZlIC8ga25vdyBvZiBhIHJlZmVyZW5jZSB0byBwb2ludCByZWFkZXJzIHRvd2FyZHMgd2hl cmUgdGhpcyBpcyB3b3JrZWQgb3V0IGluIG1vcmUgZGV0YWlsPwoKNy4zICJ0aGUgZmFjdCB0aGF0 IG5vbmNlIiAtPiAidGhlIGZhY3QgdGhhdCB0aGUgbm9uY2UiCgo3LjQgInByaW1hdGl2ZXMiIC0+ ICJwcmltaXRpdmVzIgoKNy41IHN1YnNlY3Rpb24gdGl0bGUgaXMgY2FwaXRhbGl6ZWQsIHVubGlr ZSB0aGUgb3RoZXIgc3Vic2VjdGlvbiB0aXRsZXMgaW4gdGhlIGRvY3VtZW50Cgo3LjcgZmlyc3Qg dHdvIGJ1bGxldHMgbWlzc2luZyBhIGZ1bGwgc3RvcCBhdCB0aGUgZW5kLgoKRGlzY2xhaW1lcjog SSBoYXZlbid0IGNoZWNrZWQgdGhlIGNhbGN1bGF0aW9ucyBpbiB0aGUgQXBwZW5kaXguCg== --000000000000c910cd05b29707d9-- From nobody Mon Oct 26 12:20:51 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4EF3A0BA0 for ; Mon, 26 Oct 2020 12:20:49 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eWS_SQKuO07L for ; Mon, 26 Oct 2020 12:20:45 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EA63A0E3E for ; Mon, 26 Oct 2020 12:20:45 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id p93so269722edd.7 for ; Mon, 26 Oct 2020 12:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bwU+d/SMbsOImruAZSMh+kQW/wZ7BwXlWe6c7Y+d9gg=; b=UWGL0uVi65EVNDRJHb/QamPKm4pIUtTHkVJ4RWmbDtFltIohPXmOjYeSQ/x6Krlt2p bDKu/VsmPkjZzhPBJaOwdiXeYnkbRijC+L61QWtoe7b777k2SmCZlNRwO5XGHvz2MWwk uWpc9+MQ2WBVM2L4wNyeCh073et7LP/0tYipGSeMUPjnhVvzxYPP0rc1CP1bIeKfqWFq KPUnMSOB3EBPnWOewVYF6Ct5K+SOpIGLEQ7rRaG43XlCLpKqd7BH12alOsDRXTU02Axn SDxAzja6zEyxK8eFaeBDFTXl13UY4NIXmdhUAGxESNVRtdrFek10pXsfBcCgLG4AaGug GbQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bwU+d/SMbsOImruAZSMh+kQW/wZ7BwXlWe6c7Y+d9gg=; b=hEfS5OdpNJbPuyBz8D6G03QNWy35GuEcvPb6irEzq1P0m3Oatb0KkfUnLKPKwFvpJ+ 0iKtuHq/Jnf8emyLdomSM1E1osbAHtlfDtstALtixjaNsnxPeRBpdQUNhor76M7apGgO ShBbSty8JWIowPoyppLo+p82JmwPaKK1z8jQXQoIigYU196GrK/Ehp/qov7Alfjz0S0B LzeD/r2Ud3T+OzKyfd3dnAx18i81TDKyKer/9MlD7aIcMZuBxD0Igw/OlSFdovQcDxfu yRlprJH/nQSfjxxreTTj3YtrtdUNceHmX2RZxJcJbqnkQ2WM4E0NufuaP/yygbDn4HVm wuTQ== X-Gm-Message-State: AOAM533Or3joIxA6WRgqNaK7uODbqqL9HmqTJRZakrMyMfDMCPV3QcFJ taXyNoYh55H1QAzT+DBl3Vcgfu9gHfItqu/mCYw= X-Google-Smtp-Source: ABdhPJzymPDRie4ZYOafYuD4u388X430uugZit3zwaIzH3R4EAYUCR4ZVIWOK64asx6/iWunuomDTt1E8mS1lA+A7q8= X-Received: by 2002:a50:99c3:: with SMTP id n3mr7575182edb.213.1603740043777; Mon, 26 Oct 2020 12:20:43 -0700 (PDT) MIME-Version: 1.0 References: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 26 Oct 2020 22:20:32 +0300 Message-ID: To: Chloe Martindale Cc: Alexey Melnikov , Leonid Reyzin , crypto-panel@irtf.org, draft-irtf-cfrg-vrf@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f1a3d05b297d34c" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-vrf-07 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 19:20:50 -0000 --0000000000009f1a3d05b297d34c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot, Chloe! =D0=BF=D0=BD, 26 =D0=BE=D0=BA=D1=82. 2020 =D0=B3. =D0=B2 21:23, Chloe Marti= ndale : > Hi all, > > apologies again for the delay, my review is now attached. Thanks for your > patience! > > All the best, > Chloe > > On Mon, 14 Sep 2020 at 13:25, Leonid Reyzin wrote: > >> Thank you, Chloe! I hope you are feeling better! >> >> Best, >> >> Leo >> >> >> On Mon, Sep 14, 2020 at 7:36 AM Chloe Martindale < >> chloemartindale@gmail.com> wrote: >> >>> I'm sorry this is on me. I had promised to review it but I've been off >>> for several weeks (and wasn't able to work much before that) for health >>> reasons. I'm back today and naturally have a bit of a backlog but shoul= d be >>> able to get to this before the end of the month if that's ok. >>> >>> All the best, >>> Chloe >>> >>> On Tue, 8 Sep 2020 at 14:19, Leonid Reyzin wrote: >>> >>>> Hi Everyone, >>>> >>>> Just a ping on this -- the VRF draft has been waiting for the >>>> Crypto Review Panel. I don't know if there's been any progress? Thanks= in >>>> advance! >>>> >>>> Leo >>>> >>>> >>>> On Fri, Jun 19, 2020 at 1:04 PM Chloe Martindale < >>>> chloemartindale@gmail.com> wrote: >>>> >>>>> I can do it, but I won't be able to look at it until 2 weeks from now >>>>> because of deadlines - I hope that's not too late? >>>>> >>>>> All the best, >>>>> Chloe >>>>> >>>>> On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, >>>>> wrote: >>>>> >>>>>> Dear Crypto Panel members, >>>>>> >>>>>> Nick, Stanislav and I would like to ask Crypto Review Panel members >>>>>> for >>>>>> a review of >>>>>> >>>>>> >>>>>> ("Verifiable Random Functions"). >>>>>> >>>>>> Chairs are about to start RGLC on the document, so we would like to >>>>>> solicit some reviews before that. >>>>>> >>>>>> >>>>>> One or two reviews would be appreciated. >>>>>> >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Alexey (on behalf of chairs) >>>>>> >>>>>> _______________________________________________ >>>>>> Crypto-panel mailing list >>>>>> Crypto-panel@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/crypto-panel >>>>>> >>>>> _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000009f1a3d05b297d34c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot, Chloe!

=D0=BF=D0=BD, 26 =D0=BE=D0=BA=D1= =82. 2020 =D0=B3. =D0=B2 21:23, Chloe Martindale <chloemartindale@gmail.com>:
Hi all,

apologies again for the delay, my review is now attached. Thanks for you= r patience!

All the best,
Chloe

On Mon, 14 Sep 2020 at 13:25, Leonid Reyzin <reyzin@cs.bu.edu> wrote:
Thank you, Chl= oe! I hope you are feeling better!

Best,

<= /div>
=C2=A0Leo


On Mon, Sep 14, 2020 at 7:36 AM Chl= oe Martindale <chloemartindale@gmail.com> wrote:
I'm sorry this i= s on me. I had promised to review it but I've been off for several week= s (and wasn't able to work much before that) for health reasons. I'= m back today and naturally have a bit of a backlog but should be able to ge= t to this before the end of the month if that's ok.

All the best,
Chloe

On Tue, 8 Sep 2020 at 14:19, L= eonid Reyzin <reyz= in@cs.bu.edu> wrote:
Hi Everyone,

Just a ping on= this -- the VRF draft has been waiting for the Crypto=C2=A0Review Panel. I= don't know if there's been any progress? Thanks in advance!
<= div>
=C2=A0Leo


On Fri, Jun 19, 2020 at 1:= 04 PM Chloe Martindale <chloemartindale@gmail.com> wrote:
I can do it, but = I won't be able to look at it until 2 weeks from now because of deadlin= es - I hope that's not too late?

All=C2=A0the best,
Chloe

On Fri, 19 Jun = 2020, 16:42 Alexey Melnikov, <alexey.melnikov@isode.com> wrote:
Dear Crypto Panel members,
Nick, Stanislav and I would like to ask Crypto Review Panel members for a review of
<https://datatra= cker.ietf.org/doc/draft-irtf-cfrg-vrf/?include_text=3D1>
("Verifiable Random Functions").

Chairs are about to start RGLC on the document, so we would like to
solicit some reviews before that.


One or two reviews would be appreciated.


Thank you,

Alexey (on behalf of chairs)

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/c= rypto-panel
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000009f1a3d05b297d34c-- From nobody Tue Oct 27 14:46:43 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0A3A10C2 for ; Tue, 27 Oct 2020 14:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 R9MYNdTI7M2K for ; Tue, 27 Oct 2020 14:46:39 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C116B3A108C for ; Tue, 27 Oct 2020 14:46:39 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id b15so3183021iod.13 for ; Tue, 27 Oct 2020 14:46:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tc1VNmK2Xk6SgKuSXzyedHPP1WS19mUdLermzhW7HRU=; b=A37Yee9ms44xJoUHgQaCBYjVzHbUuuVgF9EqJqleQ6nx+3PYYxXN9v4/cDYB6vxd77 NJHDxzv67n12he2RBTMHMjY9c7elfCJabbmkQaYqlP14jQxMC8YC+lojVoO3nTXFT8Lr 2grAne1DQvzLgf/vS17WzTDVzQL1c6xbobzVjNJztEZhyK+6W1j8C7jFVJPDbCnKQxDs Y6HnaQ9c8UrHToB8SNUos9/DsH4ejmNP6InhE6z4xuafqvlbA+LSPZmOQTxLMSXY1bZQ RNAN6wvKFbvIAb1+03UFYiWLeygtTisBHkrQpHhlNT9RYIPE60arMOq+qFOC3P1o8+cR 2KCQ== X-Gm-Message-State: AOAM532eazIiJKuBLH55Q+o9SVmh7KjFn+QEYRZdIjj3Wue0S68Mg80Q C4PzXTPDWte4RlauLeFf7UtAPCGPa8C2+qZW38U= X-Google-Smtp-Source: ABdhPJw/KvkGudvXokWnbm6xAyMt7MzAXiKsrPmUP4B/2T31/uIBT4AUqzt1qi6mNgkENM1vnRguuzVFi2GewsOcCpk= X-Received: by 2002:a5e:9618:: with SMTP id a24mr3888015ioq.27.1603835198853; Tue, 27 Oct 2020 14:46:38 -0700 (PDT) MIME-Version: 1.0 References: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> In-Reply-To: From: Leonid Reyzin Date: Tue, 27 Oct 2020 17:46:12 -0400 Message-ID: To: "Stanislav V. Smyshlyaev" Cc: Chloe Martindale , Alexey Melnikov , crypto-panel@irtf.org, draft-irtf-cfrg-vrf@ietf.org Content-Type: multipart/alternative; boundary="0000000000004e555405b2adfb2c" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-vrf-07 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 21:46:42 -0000 --0000000000004e555405b2adfb2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Chloe, Thank you SO much for this detailed work. I will go through it in the next few days and will ask followup questions if I have any. Best, Leo On Mon, Oct 26, 2020 at 3:20 PM Stanislav V. Smyshlyaev wrote: > Thanks a lot, Chloe! > > =D0=BF=D0=BD, 26 =D0=BE=D0=BA=D1=82. 2020 =D0=B3. =D0=B2 21:23, Chloe Mar= tindale : > >> Hi all, >> >> apologies again for the delay, my review is now attached. Thanks for you= r >> patience! >> >> All the best, >> Chloe >> >> On Mon, 14 Sep 2020 at 13:25, Leonid Reyzin wrote: >> >>> Thank you, Chloe! I hope you are feeling better! >>> >>> Best, >>> >>> Leo >>> >>> >>> On Mon, Sep 14, 2020 at 7:36 AM Chloe Martindale < >>> chloemartindale@gmail.com> wrote: >>> >>>> I'm sorry this is on me. I had promised to review it but I've been off >>>> for several weeks (and wasn't able to work much before that) for healt= h >>>> reasons. I'm back today and naturally have a bit of a backlog but shou= ld be >>>> able to get to this before the end of the month if that's ok. >>>> >>>> All the best, >>>> Chloe >>>> >>>> On Tue, 8 Sep 2020 at 14:19, Leonid Reyzin wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Just a ping on this -- the VRF draft has been waiting for the >>>>> Crypto Review Panel. I don't know if there's been any progress? Thank= s in >>>>> advance! >>>>> >>>>> Leo >>>>> >>>>> >>>>> On Fri, Jun 19, 2020 at 1:04 PM Chloe Martindale < >>>>> chloemartindale@gmail.com> wrote: >>>>> >>>>>> I can do it, but I won't be able to look at it until 2 weeks from no= w >>>>>> because of deadlines - I hope that's not too late? >>>>>> >>>>>> All the best, >>>>>> Chloe >>>>>> >>>>>> On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, < >>>>>> alexey.melnikov@isode.com> wrote: >>>>>> >>>>>>> Dear Crypto Panel members, >>>>>>> >>>>>>> Nick, Stanislav and I would like to ask Crypto Review Panel members >>>>>>> for >>>>>>> a review of >>>>>>> < >>>>>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/?include_text= =3D1> >>>>>>> >>>>>>> ("Verifiable Random Functions"). >>>>>>> >>>>>>> Chairs are about to start RGLC on the document, so we would like to >>>>>>> solicit some reviews before that. >>>>>>> >>>>>>> >>>>>>> One or two reviews would be appreciated. >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Alexey (on behalf of chairs) >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Crypto-panel mailing list >>>>>>> Crypto-panel@irtf.org >>>>>>> https://www.irtf.org/mailman/listinfo/crypto-panel >>>>>>> >>>>>> _______________________________________________ >> Crypto-panel mailing list >> Crypto-panel@irtf.org >> https://www.irtf.org/mailman/listinfo/crypto-panel >> > --0000000000004e555405b2adfb2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Chloe,

Thank you SO much for this = detailed work. I will go through it in the next few days and will ask follo= wup questions if I have any.

Best,

<= /div>
=C2=A0Leo


On Mon, Oct 26, 2020 at 3:20 PM Sta= nislav V. Smyshlyaev <smyshsv@gmail= .com> wrote:
Thanks a lot, Chloe!

=D0=BF=D0=BD, 26 =D0=BE=D0= =BA=D1=82. 2020 =D0=B3. =D0=B2 21:23, Chloe Martindale <chloemartindale@gmail.com>:


On Mon, 14 Sep 2020 at 13:25, = Leonid Reyzin <rey= zin@cs.bu.edu> wrote:
Thank you, Chloe! I hope you are feeling bett= er!

Best,

=C2=A0Leo
<= br>

On Mon, Sep 14, 2020 at 7:36 AM Chloe Martindale <chloemartindale@gmail.com= > wrote:
=
I'm sorry this is on me. I had promised to review= it but I've been off for several weeks (and wasn't able to work mu= ch before that) for health reasons. I'm back today and naturally have a= bit of a backlog but should be able to get to this before the end of the m= onth if that's ok.

All the best,
Chl= oe

On Tue, 8 Sep 2020 at 14:19, Leonid Reyzin <reyzin@cs.bu.edu> wrote:
Hi E= veryone,

Just a ping on this -- the VRF draft has been w= aiting for the Crypto=C2=A0Review Panel. I don't know if there's be= en any progress? Thanks in advance!

=C2=A0Leo


On Fri, Jun 19, 2020 at 1:04 PM Chloe Martindale <chloemartindale@gm= ail.com> wrote:
I can do it, but I won't be able to look at it= until 2 weeks from now because of deadlines - I hope that's not too la= te?

All=C2=A0the best,
Chloe

On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, <= alexey.melni= kov@isode.com> wrote:
Dear Crypto Panel members,

Nick, Stanislav and I would like to ask Crypto Review Panel members for a review of
<https://datatra= cker.ietf.org/doc/draft-irtf-cfrg-vrf/?include_text=3D1>
("Verifiable Random Functions").

Chairs are about to start RGLC on the document, so we would like to
solicit some reviews before that.


One or two reviews would be appreciated.


Thank you,

Alexey (on behalf of chairs)

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/c= rypto-panel
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000004e555405b2adfb2c--