From nobody Fri Jun 2 13:06:31 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF862128BBB for ; Fri, 2 Jun 2017 13:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 LFKnOAjK09_9 for ; Fri, 2 Jun 2017 13:06:27 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF0712954D for ; Fri, 2 Jun 2017 13:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zdLyDHK4AawmkxsiI+tfCj1Dylt3JXyqSRE75FIh9LQ=; b=o43VyS59y5c3nrXmnoz6rJe7NVR7DDfzfAjw1uYM2fAePoh8md290vIfPmnFUlQNZns/VrARMO32wS39zEtPWdXLtqUvMZ9/kHBg+OLiY2ae+TE8AbPREurVR2YT3gNRLXUuJ++ynUd4u9xPZwXgJ++Ol1vmJH3wp8JSUAAwKTA= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0151.namprd21.prod.outlook.com (10.173.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.1; Fri, 2 Jun 2017 20:06:25 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1157.006; Fri, 2 Jun 2017 20:06:25 +0000 From: Mike Jones To: "cfrg@irtf.org" CC: Steve KENT Thread-Topic: Reference for hash substitution attack against RSASSA-PSS and its mitigation Thread-Index: AdLb26Zx24x4lnXmRNe6X+ajH2VGUA== Date: Fri, 2 Jun 2017 20:06:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-02T13:06:19.6021399-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0151; 7:++3f8AQXI8LblUKUwYu0qICcmTRDvO6p0vKifinTI0Ksfcz/+rymG16vb6gES/ymZHvbtP2nKZX7aDqTiSI12Bb6ZKjR650iGEaGgeTv9LvWCn46TqyccfW5YQgNmRYujGo702fKzwMZHKHCKNX7m8Fj4M3Kq6mZzjCY6tXwpiNrKXtWXLPCk0iTPSzGxe4AkmewW6uJW3ylIyV+5ujfjB0AMdKTyroAJ0Vri2i5/vxeHOYt11sFrK4vZV2fPyqzBxpUTecopvY2n1/T2dusHB60v+Xee1+nW5VNb/OHq/T30Ee7hJSrw7l2u/69jiJGqmLRhBNBGahP3PYrCzO88SFlHPOeCE3u/nwE6D/BL34= x-ms-traffictypediagnostic: CY4PR21MB0151: x-ms-office365-filtering-correlation-id: 2bd67771-dc8a-41a4-c020-08d4a9f2d954 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR21MB0151; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0151; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0151; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39400400002)(39850400002)(39410400002)(5630700001)(53936002)(2906002)(5660300001)(3280700002)(3660700001)(86612001)(74316002)(33656002)(7736002)(25786009)(86362001)(54896002)(10090500001)(6306002)(6506006)(77096006)(5640700003)(4326008)(5005710100001)(6916009)(8990500004)(9686003)(99286003)(6436002)(55016002)(2351001)(1730700003)(81156014)(81166006)(54356999)(8936002)(8676002)(122556002)(2900100001)(558084003)(50986999)(10290500003)(14454004)(72206003)(2501003)(110136004)(38730400002)(6116002)(102836003)(189998001)(790700001)(7696004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0151; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050485ED3B9A02F48EC2E81EF5F70CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2017 20:06:25.7280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0151 Archived-At: Subject: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:06:30 -0000 --_000_CY4PR21MB050485ED3B9A02F48EC2E81EF5F70CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a paper that describes the theoretical hash substitution attacks a= gainst RSASSA-PSS and how they are mitigated? Thanks, -- Mike --_000_CY4PR21MB050485ED3B9A02F48EC2E81EF5F70CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a paper that describes the theoretical hash= substitution attacks against RSASSA-PSS and how they are mitigated?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_CY4PR21MB050485ED3B9A02F48EC2E81EF5F70CY4PR21MB0504namp_-- From nobody Sun Jun 4 12:28:49 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37F129C6F for ; Sun, 4 Jun 2017 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 GAK_XWGohJkf for ; Sun, 4 Jun 2017 12:28:45 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0076.outbound.protection.outlook.com [104.47.2.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1261129C6C for ; Sun, 4 Jun 2017 12:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pdzyZD3wKeElmMMQI4CIm2xrgP299nTLBWXqHSmEuls=; b=3S0Qb6tKMunGJKIyFit/CiO/OR97WUnVulDGc+3iVUD9PcxzNe+9CqJtdZkz4+HLYVASs8XR72FwekCM13pDU+cnYlk5j3ic9Q71DTtns+hnkRIOdYAYZKKZW7ZNGBkRgPWMxF+XwDq6vueaNWJqZoHdqsUCbPexu+ff+a3qVcw= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sun, 4 Jun 2017 19:28:42 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59%14]) with mapi id 15.01.1143.016; Sun, 4 Jun 2017 19:28:42 +0000 From: "Paterson, Kenny" To: Mike Jones , "cfrg@irtf.org" CC: Steve KENT Thread-Topic: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation Thread-Index: AQHS3WjG4Nl2YzYgAEC1Bs76jiQZZA== Date: Sun, 4 Jun 2017 19:28:41 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.52.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:docoeYCpAI/5jXydQunHIFZ7awH0V4U6XnprV3ik101TMJWYymPtSBGSHbkJ+O8vBIDABlfA1dfBezldut86TGL9tIYU/wDowVx/s3AzapyvcrQB8Rc7Dcyo7sM0czvQQrbGBigx24uYd6KUv95inWkZSeKgZCeQ94+6UHyCo8u6MggvSMDA0LA8rM1AVBh6yiEOHsfXkvwLUyvptjbYsiQcZtPcHqgojRFGAJGQvqWrLQDj61egQU99U01xPtEMaAZcngHzqn4ucS+vIblUbAPbGtFHX8Qc0ejiBYTlsLfzqpSbm7DIyknXmTVP4rR8z2bUK54TqR6d2EDS0SgXMg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(24454002)(25786009)(478600001)(6506006)(5660300001)(72206003)(6486002)(1511001)(229853002)(53936002)(2900100001)(66066001)(189998001)(6512007)(4001350100001)(99286003)(86362001)(8666007)(36756003)(305945005)(50986999)(54356999)(6246003)(38730400002)(74482002)(5250100002)(8936002)(6436002)(7736002)(53546009)(3280700002)(8676002)(3660700001)(2906002)(3846002)(81166006)(83506001)(6116002)(42882006)(2501003)(4326008)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-ms-office365-filtering-correlation-id: ce48df5a-7a17-476b-b819-08d4ab7fe8c5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0301MB1906; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 03283976A6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <591DEDECFD86BD46A2711557311E3A49@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 19:28:41.9925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 19:28:47 -0000 SGkgTWlrZSwNCg0KSSdtIG5vdCBzdXJlIHdoYXQgYXR0YWNrcyB5b3UncmUgcmVmZXJyaW5nIHRv IGhlcmUsIHNvIGNvdWxkIHlvdSBicmllZmx5DQpzdW1tYXJpc2UgdGhlbSBmb3IgbWU/IFRoYXQg bWlnaHQgaGVscCBtZSBhbmQgb3RoZXJzIGZpZ3VyZSBvdXQgaWYgdGhlcmUncw0KYSBzdWl0YWJs ZSByZXNlYXJjaCBwYXBlciB0byBwb2ludCB5b3UgdG93YXJkcy4NCg0KVGhhbmtzLA0KDQpLZW5u eSANCg0KT24gMDIvMDYvMjAxNyAyMTowNiwgIkNmcmcgb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMi IDxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcNCm9uIGJlaGFsZiBvZiBNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+IHdyb3RlOg0KDQo+SXMgdGhlcmUgYSBwYXBlciB0aGF0IGRlc2NyaWJlcyB0aGUg dGhlb3JldGljYWwgaGFzaCBzdWJzdGl0dXRpb24gYXR0YWNrcw0KPmFnYWluc3QgUlNBU1NBLVBT UyBhbmQgaG93IHRoZXkgYXJlIG1pdGlnYXRlZD8NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KPiANCj4NCg0K From nobody Sun Jun 4 23:05:43 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACBD126D85 for ; Sun, 4 Jun 2017 23:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 g2sjsPm2J2Ag for ; Sun, 4 Jun 2017 23:05:40 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0058D12751F for ; Sun, 4 Jun 2017 23:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=13ItYYFYd+L/JkvFCEO0VQVntSXaFExoXwq9Lqgmxlc=; b=WVREffygJtmfjlYPSMLbbBc5dY6tkK2rrwIUNNK1DZsyrNYWdEwuzaRJ0OE1MSt5js6xbbrENdOTJ0fAJFPGggADhvkKakLHMJtO1odNfhSgObP8rRqdZvKP68HeG7CTraPuUXOHCOsp4z4BEUvmcRqSTSn5iz7CUAZ0HccgZi4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0694.namprd21.prod.outlook.com (10.175.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Mon, 5 Jun 2017 06:05:38 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.000; Mon, 5 Jun 2017 06:05:38 +0000 From: Mike Jones To: "Paterson, Kenny" , "cfrg@irtf.org" CC: Steve KENT Thread-Topic: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation Thread-Index: AQHS3WjG4Nl2YzYgAEC1Bs76jiQZZKIVx61Q Date: Mon, 5 Jun 2017 06:05:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-04T23:05:36.4802505-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: rhul.ac.uk; dkim=none (message not signed) header.d=none;rhul.ac.uk; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0694; 7:qDt+S7uKfnEI+tIW13CzXgzk7m7TNXgl2Vg3MSWuYvnH7MN0bOIytmdhb5DVQBH0LUzF+QcgAEGrMH4kv0mD2ICmKE8umZzI5aUE48zR5hkpYf17yK0kpSwytAlec0e3WQS3GUVsHgyefp0Hox40e3s4/EChi3V13Q5FPTbvCYPlE3vAeQe5gV5DluzTSUc+M044U1XNcKyphkE4XNFoezzLmUu0+f1Gu9w8NkYLIc5JRhPuKj4fYn3Tx+L9lL3KulYv1tfnOpNF1uFoWgg7bKOn6TCRBS4dCvbsyXznBrxSb7uK3isIjpmo4hvjBeCV9APM8RL+Fz6Bnj8++zo/6krx8NL9gze845P9qGzfvWQ= x-ms-office365-filtering-correlation-id: fef09226-9c1b-4526-2f4c-08d4abd8e381 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0694; x-ms-traffictypediagnostic: CY4PR21MB0694: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0694; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0694; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39400400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(13464003)(229853002)(33656002)(2900100001)(76176999)(54356999)(50986999)(6506006)(8676002)(77096006)(6436002)(236005)(9686003)(189998001)(54896002)(6306002)(99286003)(55016002)(8656002)(86362001)(81166006)(5660300001)(66066001)(5005710100001)(10090500001)(122556002)(8936002)(10290500003)(478600001)(74316002)(7736002)(3660700001)(72206003)(14454004)(2906002)(3280700002)(2950100002)(38730400002)(53546009)(25786009)(4326008)(3846002)(6116002)(790700001)(102836003)(7696004)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0694; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504B5B60E6DDBC77C5443B6F5CA0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2017 06:05:38.1620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0694 Archived-At: Subject: Re: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 06:05:42 -0000 --_000_CY4PR21MB0504B5B60E6DDBC77C5443B6F5CA0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB0ZXh0IHdhcyB3cml0dGVuIGZvciBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhYm91dCB1 c2luZyBSU0FTU0EtUFNTOg0KDQoNCg0KVGhlcmUgaXMgYSB0aGVvcmV0aWNhbCBoYXNoIHN1YnN0 aXR1dGlvbiBhdHRhY2sgdGhhdCBjYW4gYmUgbW91bnRlZCBhZ2FpbnN0IFJTQVNTQS1QU1MuIEhv d2V2ZXIsIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBzYW1lIGhhc2ggZnVuY3Rpb24gYmUgdXNl ZCBjb25zaXN0ZW50bHkgZm9yIGFsbCBvcGVyYXRpb25zIGlzIGFuIGVmZmVjdGl2ZSBtaXRpZ2F0 aW9uIGFnYWluc3QgaXQuIFVubGlrZSBFQ0RTQSwgaGFzaCBmdW5jdGlvbiBvdXRwdXRzIGFyZSBu b3QgdHJ1bmNhdGVkIHNvIHRoYXQgdGhlIGZ1bGwgaGFzaCB2YWx1ZSBpcyBhbHdheXMgc2lnbmVk LiBUaGUgaW50ZXJuYWwgcGFkZGluZyBzdHJ1Y3R1cmUgb2YgUlNBU1NBLVBTUyBtZWFucyB0aGF0 IG9uZSBuZWVkcyB0byBoYXZlIG11bHRpcGxlIGNvbGxpc2lvbnMgYmV0d2VlbiB0aGUgdHdvIGhh c2ggZnVuY3Rpb25zIHRvIGJlIHN1Y2Nlc3NmdWwgaW4gcHJvZHVjaW5nIGEgZm9yZ2VyeSBiYXNl ZCBvbiBjaGFuZ2luZyB0aGUgaGFzaCBmdW5jdGlvbi4gVGhpcyBpcyBoaWdobHkgdW5saWtlbHku DQoNCg0KDQpJZiB0aGVyZeKAmXMgYSBzdWl0YWJsZSByZWZlcmVuY2UgdG8gdGhlc2UgYXR0YWNr cywgdGhhdCB3b3VsZCBiZSBncmVhdC4gIE9yIGlmIGV2ZW4gc2F5aW5nIHRoaXMgaXMgbWlzZ3Vp ZGVkIG9yIG91dCBvZiBwbGFjZSwgdGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8ga25vdyB0b28uDQoN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVGhhbmtzLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFBhdGVyc29uLCBLZW5ueSBbbWFpbHRvOktlbm55LlBhdGVyc29uQHJodWwuYWMudWtdDQpT ZW50OiBTdW5kYXksIEp1bmUgNCwgMjAxNyAxMjoyOSBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IGNmcmdAaXJ0Zi5vcmcNCkNjOiBTdGV2ZSBLRU5UIDxz dGV2ZS5rZW50QHJheXRoZW9uLmNvbT4NClN1YmplY3Q6IFJlOiBbQ2ZyZ10gUmVmZXJlbmNlIGZv ciBoYXNoIHN1YnN0aXR1dGlvbiBhdHRhY2sgYWdhaW5zdCBSU0FTU0EtUFNTIGFuZCBpdHMgbWl0 aWdhdGlvbg0KDQoNCg0KSGkgTWlrZSwNCg0KDQoNCkknbSBub3Qgc3VyZSB3aGF0IGF0dGFja3Mg eW91J3JlIHJlZmVycmluZyB0byBoZXJlLCBzbyBjb3VsZCB5b3UgYnJpZWZseSBzdW1tYXJpc2Ug dGhlbSBmb3IgbWU/IFRoYXQgbWlnaHQgaGVscCBtZSBhbmQgb3RoZXJzIGZpZ3VyZSBvdXQgaWYg dGhlcmUncyBhIHN1aXRhYmxlIHJlc2VhcmNoIHBhcGVyIHRvIHBvaW50IHlvdSB0b3dhcmRzLg0K DQoNCg0KVGhhbmtzLA0KDQoNCg0KS2VubnkNCg0KDQoNCk9uIDAyLzA2LzIwMTcgMjE6MDYsICJD ZnJnIG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzIiA8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJl aGFsZiBvZiBNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOmNmcmctYm91bmNlc0Bp cnRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNCg0KDQoNCj5JcyB0aGVyZSBhIHBhcGVyIHRoYXQgZGVzY3JpYmVzIHRoZSB0aGVv cmV0aWNhbCBoYXNoIHN1YnN0aXR1dGlvbg0KDQo+YXR0YWNrcyBhZ2FpbnN0IFJTQVNTQS1QU1Mg YW5kIGhvdyB0aGV5IGFyZSBtaXRpZ2F0ZWQ/DQoNCj4NCg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQoNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQo+DQoNCj4NCg0KDQo= --_000_CY4PR21MB0504B5B60E6DDBC77C5443B6F5CA0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIHRleHQgd2FzIHdyaXR0ZW4gZm9y IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFib3V0IHVzaW5nIFJTQVNTQS1QU1M6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGVyZSBpcyBh IHRoZW9yZXRpY2FsIGhhc2ggc3Vic3RpdHV0aW9uIGF0dGFjayB0aGF0IGNhbiBiZSBtb3VudGVk IGFnYWluc3QgUlNBU1NBLVBTUy4gSG93ZXZlciwgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlIHNh bWUgaGFzaCBmdW5jdGlvbiBiZSB1c2VkIGNvbnNpc3RlbnRseSBmb3IgYWxsIG9wZXJhdGlvbnMg aXMgYW4gZWZmZWN0aXZlIG1pdGlnYXRpb24NCiBhZ2FpbnN0IGl0LiBVbmxpa2UgRUNEU0EsIGhh c2ggZnVuY3Rpb24gb3V0cHV0cyBhcmUgbm90IHRydW5jYXRlZCBzbyB0aGF0IHRoZSBmdWxsIGhh c2ggdmFsdWUgaXMgYWx3YXlzIHNpZ25lZC4gVGhlIGludGVybmFsIHBhZGRpbmcgc3RydWN0dXJl IG9mIFJTQVNTQS1QU1MgbWVhbnMgdGhhdCBvbmUgbmVlZHMgdG8gaGF2ZSBtdWx0aXBsZSBjb2xs aXNpb25zIGJldHdlZW4gdGhlIHR3byBoYXNoIGZ1bmN0aW9ucyB0byBiZSBzdWNjZXNzZnVsIGlu DQogcHJvZHVjaW5nIGEgZm9yZ2VyeSBiYXNlZCBvbiBjaGFuZ2luZyB0aGUgaGFzaCBmdW5jdGlv bi4gVGhpcyBpcyBoaWdobHkgdW5saWtlbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj5JZiB0aGVyZeKAmXMgYSBzdWl0YWJsZSByZWZlcmVuY2UgdG8gdGhl c2UgYXR0YWNrcywgdGhhdCB3b3VsZCBiZSBncmVhdC4mbmJzcDsgT3IgaWYgZXZlbiBzYXlpbmcg dGhpcyBpcyBtaXNndWlkZWQgb3Igb3V0IG9mIHBsYWNlLCB0aGF0IHdvdWxkIGJlIHVzZWZ1bCB0 byBrbm93IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFBhdGVyc29u LCBLZW5ueSBbbWFpbHRvOktlbm55LlBhdGVyc29uQHJodWwuYWMudWtdIDxicj4NClNlbnQ6IFN1 bmRheSwgSnVuZSA0LCAyMDE3IDEyOjI5IFBNPGJyPg0KVG86IE1pa2UgSm9uZXMgJmx0O01pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7IGNmcmdAaXJ0Zi5vcmc8YnI+DQpDYzogU3RldmUg S0VOVCAmbHQ7c3RldmUua2VudEByYXl0aGVvbi5jb20mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtD ZnJnXSBSZWZlcmVuY2UgZm9yIGhhc2ggc3Vic3RpdHV0aW9uIGF0dGFjayBhZ2FpbnN0IFJTQVNT QS1QU1MgYW5kIGl0cyBtaXRpZ2F0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBNaWtlLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ20gbm90IHN1cmUgd2hhdCBhdHRhY2tzIHlvdSdy ZSByZWZlcnJpbmcgdG8gaGVyZSwgc28gY291bGQgeW91IGJyaWVmbHkgc3VtbWFyaXNlIHRoZW0g Zm9yIG1lPyBUaGF0IG1pZ2h0IGhlbHAgbWUgYW5kIG90aGVycyBmaWd1cmUgb3V0IGlmIHRoZXJl J3MgYSBzdWl0YWJsZSByZXNlYXJjaCBwYXBlciB0byBwb2ludCB5b3UgdG93YXJkcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5LZW5ueSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gMDIvMDYvMjAxNyAy MTowNiwgJnF1b3Q7Q2ZyZyBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNmcmctYm91bmNlc0BpcnRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5jZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7SXMgdGhlcmUgYSBwYXBlciB0aGF0IGRlc2NyaWJl cyB0aGUgdGhlb3JldGljYWwgaGFzaCBzdWJzdGl0dXRpb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O2F0dGFja3MgYWdhaW5zdCBSU0FTU0EtUFNTIGFuZCBo b3cgdGhleSBhcmUgbWl0aWdhdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0504B5B60E6DDBC77C5443B6F5CA0CY4PR21MB0504namp_-- From nobody Mon Jun 5 07:03:51 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8EF129553 for ; Mon, 5 Jun 2017 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_l3faPPm1Z0 for ; Mon, 5 Jun 2017 07:03:47 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B78129649 for ; Mon, 5 Jun 2017 07:03:47 -0700 (PDT) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2017 10:03:46 -0400 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 5 Jun 2017 10:03:45 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 5 Jun 2017 10:03:44 -0400 From: Dan Brown To: Mike Jones , "cfrg@irtf.org" CC: Steve KENT Thread-Topic: Reference for hash substitution attack against RSASSA-PSS and its mitigation Thread-Index: AdLb26Zx24x4lnXmRNe6X+ajH2VGUACJ9uGQ Date: Mon, 5 Jun 2017 14:03:43 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B1CFB4@XMB116CNC.rim.net> References: In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF501B1CFB4XMB116CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Reference for hash substitution attack against RSASSA-PSS and its mitigation X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:03:50 -0000 --_000_810C31990B57ED40B2062BA10D43FBF501B1CFB4XMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a guess: perhaps this old presentation by Kaliski: http://grouper.ieee.org/groups/1363/Research/contributions/HashFunctionFire= walls.pdf is relevant? Probably even more off-topic: as I recall, the standardized version of PSS = pre-hashes the message, whereas the original academic Bellare-Rogaway versi= on does not. The difference between the standard and the academic version = is a little like the difference between Schnorr and DSA-style signatures. = So, for standard PSS, the hash must resist collisions, pre-images, etc., wh= ereas for the original PSS, perhaps much less is needed from hash (the proo= f assumes a super-strong hash, of course). I suppose that this in turn may= be a concern for hash substitutions ... From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Mike Jones Sent: Friday, June 2, 2017 4:06 PM To: cfrg@irtf.org Cc: Steve KENT Subject: [Cfrg] Reference for hash substitution attack against RSASSA-PSS a= nd its mitigation Is there a paper that describes the theoretical hash substitution attacks a= gainst RSASSA-PSS and how they are mitigated? Thanks, -- Mike --_000_810C31990B57ED40B2062BA10D43FBF501B1CFB4XMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a guess: perhaps this old presentation by Kalis= ki:

 

http://grouper.ieee.org/groups= /1363/Research/contributions/HashFunctionFirewalls.pdf

 

is relevant?

 

Probably even more off-topic: as I recall, the stand= ardized version of PSS pre-hashes the message, whereas the original academi= c Bellare-Rogaway version does not.  The difference between the standa= rd and the academic version is a little like the difference between Schnorr and DSA-style signatures.  So, fo= r standard PSS, the hash must resist collisions, pre-images, etc., whereas = for the original PSS, perhaps much less is needed from hash (the proof assu= mes a super-strong hash, of course).  I suppose that this in turn may be a concern for hash substitutions …= ;

 

From: Cfrg [mailto:cfrg-bounces@irtf.org] = On Behalf Of Mike Jones
Sent: Friday, June 2, 2017 4:06 PM
To: cfrg@irtf.org
Cc: Steve KENT <steve.kent@raytheon.com>
Subject: [Cfrg] Reference for hash substitution attack against RSASS= A-PSS and its mitigation

 

Is there a paper that describes the theoretical hash= substitution attacks against RSASSA-PSS and how they are mitigated?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_810C31990B57ED40B2062BA10D43FBF501B1CFB4XMB116CNCrimnet_-- From nobody Mon Jun 5 07:36:42 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7098A1294B5; Mon, 5 Jun 2017 07:36:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149667340139.3152.10556340180920549215@ietfa.amsl.com> Date: Mon, 05 Jun 2017 07:36:41 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:36:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-02.txt Pages : 46 Date : 2017-06-05 Abstract: If encryption is performed under a single key, there is a certain maximum threshold amount of data that can be safely encrypted. This amount is called key lifetime. This specification contains a description of a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms based on hash functions and on block ciphers that can be used with such modes of operations as CTR, GCM, CCM, CBC, CFB, OFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-02 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 8 14:39:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4399C129508 for ; Thu, 8 Jun 2017 14:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZM4Zi8PThZ1 for ; Thu, 8 Jun 2017 14:39:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7215E1294FA for ; Thu, 8 Jun 2017 14:39:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD6173004B7 for ; Thu, 8 Jun 2017 17:39:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b0twL5_4wczw for ; Thu, 8 Jun 2017 17:39:31 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E27693003FE for ; Thu, 8 Jun 2017 17:39:31 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Jun 2017 17:39:31 -0400 References: <149667340139.3152.10556340180920549215@ietfa.amsl.com> To: cfrg@ietf.org In-Reply-To: <149667340139.3152.10556340180920549215@ietfa.amsl.com> Message-Id: <89AFF43D-EFE7-4D7F-8ECE-877A4BEBD546@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 21:39:35 -0000 I have a few comments on the most recent version of this document. Section 1: Please describe parallel and serial re-keying mechanisms in = the introduction. Section 1: I think we need to say more about internal re-key when it is = first introduced. I suggest: This specification presents two approaches that extend the key lifetime for a single symmetric key while avoiding renegotiation:=20 external and internal re-keying. External re-keying is performed by = a protocol, and it is independent of block cipher, key size, and mode. Internal re-keying is built into the mode, and it depends heavily on the properties of the block cipher and key size. Section 1, Last paragraph: Please separate the ideas here. First, TLS = 1.3 is an example of a protocol with external re-key. Second, there is = a discussion of the benefits of re-key. The first belongs elsewhere. Section 4 says: . . . External re- keying approach is recommended for usage in protocols that process quite small messages. . . .=20 It is obvious that the message size can exceed L. That said, external = re-keying is also very useful when there are lots of messages or the = protocol has a way to break a very large message into manageable chunks. = Obviously, TCP breaks a very large stream into many manageable chunks. Section 4, first item number 3 says: . . . provides forward and backward security of session keys . . . This is only true if the previous traffic keys are securely deleted by = all parties that have the keys. Section 5, bottom of page 8: Wouldn=E2=80=99t it be cleaner to say: L =3D min(L1, L2) q =3D min(q1, q2) q*m <=3D L Nits: Please use figure numbers and captions on the illustrations. Section 1: s/С/C/ Section 4: s/Homever/However/ Section 4: s/it almost does not affect performance/minimal impact on = performance/ Section 4: s/sessin keys/session keys/ Section 4: s/always have an access/always has access/ From nobody Wed Jun 14 09:21:34 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABD012EC80 for ; Wed, 14 Jun 2017 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH5n5nbw0H3t for ; Wed, 14 Jun 2017 09:21:24 -0700 (PDT) Received: from smtp1.science.ru.nl (smtp1.science.ru.nl [131.174.16.143]) (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 2A2F212EC7C for ; Wed, 14 Jun 2017 09:21:22 -0700 (PDT) Received: from [145.116.133.188] (ip-145-116-133-188.wlan-int.ru.nl [145.116.133.188]) (authen=benoit) by smtp1.science.ru.nl (8.14.4/5.32) with ESMTP id v5EGLJ1b019001 for ; Wed, 14 Jun 2017 18:21:20 +0200 To: cfrg@irtf.org From: =?UTF-8?Q?Beno=c3=aet_Viguier?= Message-ID: Date: Wed, 14 Jun 2017 18:21:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gxHsQ59DETEFbQkWNx9D2ieMVVPlRetG0" Archived-At: Subject: [Cfrg] RFC Draft for KangarooTwelve XOF draft-viguier-kangarootwelve-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:21:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gxHsQ59DETEFbQkWNx9D2ieMVVPlRetG0 Content-Type: multipart/mixed; boundary="IGWnWTDWKQc4jrji8DkDRgtGgGOF2EUmW"; protected-headers="v1" From: =?UTF-8?Q?Beno=c3=aet_Viguier?= To: cfrg@irtf.org Message-ID: Subject: RFC Draft for KangarooTwelve XOF draft-viguier-kangarootwelve-00 --IGWnWTDWKQc4jrji8DkDRgtGgGOF2EUmW Content-Type: multipart/alternative; boundary="------------0F7391A1CE76045ABB06EA47" This is a multi-part message in MIME format. --------------0F7391A1CE76045ABB06EA47 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello everyone, I wrote this RFC draft for KangarooTwelve (https://eprint.iacr.org/2016/770). It provides an efficient and secure hashing primitive, which is able to exploit the parallelism of the implementation in a scalable way. It uses tree hashing over a round-reduced version of SHAKE128 as underlying primitive. The reference code is also at available at: https://github.com/KeccakTeam/KeccakCodePackage (Standalone/KangarooTwelve-reference/K12.py) Draft is available here: https://tools.ietf.org/html/draft-viguier-kangarootwelve-00 I would like to submit this RFC under the Internet Research Task Force stream, and as far as I understood I need a Research Group (RFC 5743). Anyone would be interested to be the Editor? Of course, any other feedback is welcome. --=20 Kind regards, Beno=C3=AEt Viguier Software Engineer - PhD Student | Cryptography & Formal Methods Radboud University | Mercator 1, room 03.17, Toernooiveld 212 6525 EC Nijmegen, the Netherlands | www.viguier.nl -------------------------------------------------------------------------= - This message (and any attachments) is intended solely for the addressee(s= ) and may contain confidential information. If you are not the addressee, d= o not copy this message (and any attachments), forward or share this messag= e with third parties. You are requested to notify the sender immediately an= d delete this message. --------------0F7391A1CE76045ABB06EA47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello everyone,

I wrote this RFC draft for KangarooTwelve (https://eprint.iacr.org= /2016/770).
It provides an efficient and secure hashing primitive, which is able to exploit
the parallelism of the implementation in a scalable way. It uses tree hashing
over a round-reduced version of SHAKE128 as underlying primitive.

The reference code is also at available at:
https:/= /github.com/KeccakTeam/KeccakCodePackage
(Standalone/KangarooTwelve-reference/K12.py)

Draft is available here:
https://tools.ietf.org/html/draft-viguier-kangarootwelve-00
=

I would like to submit this RFC under the Internet Research Task Force stream,
and as far as I understood I need a Research Group (RFC 5743).
Anyone would be interested to be the Editor?

Of course, any other feedback is welcome.

--=20
Kind regards,

Beno=C3=AEt Viguier
Software Engineer - PhD Student | Cryptography & Formal Methods
Radboud University | Mercator 1, room 03.17, Toernooiveld 212
6525 EC Nijmegen, the Netherlands | www.viguier.nl

-------------------------------------------------------------------------=
-
This message (and any attachments) is intended solely for the addressee(s=
)
and may contain confidential information. If you are not the addressee, d=
o
not copy this message (and any attachments), forward or share this messag=
e
with third parties. You are requested to notify the sender immediately an=
d
delete this message.
--------------0F7391A1CE76045ABB06EA47-- --IGWnWTDWKQc4jrji8DkDRgtGgGOF2EUmW-- --gxHsQ59DETEFbQkWNx9D2ieMVVPlRetG0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEpbgh3lxW0oiYI4+f/A7ruKvQqOYFAllBYn8ACgkQ/A7ruKvQ qOZf4Q//eF1jxI/99lbK9k0yPT5nMgvuaDK/Wzm9j+slw0jopEhhh008glthAR4C 9oGKE12l6uoTzLCutNlclrcoN5iVjiTP1ZuK/ikwZVCgezRGT9pVPmHAcJc2bB/8 tcIXu7rw63YdjHhPzGf4pt/W1ucrdbqXOM+mSCuE5BxIDiVMUWQCqPp2WM6R8ZQv xNaOeGjeSi1gMPvbwbFndtB1WPzjtdBnhUHrmzyFEqTc4GBaw5yZPRlBFVMU/Pya Y1gOWXGUwvCYVpMeyMxJQEmEpfRvSt5kPWifVZSBAw53Mh7JCGK0672WUivdvhGN xmQTtLRskJOZqcyYoOZ8tZ8141HVQBsS3L9hMlx/dXDq0D3tLrqYvfnjy8HYni7z Jqn1eF5ceOvlfX70VDTAb62m134h92haDP2F5G5+tpQStBfdXwceBi3ZbIRAz8PT ADZykst/Q9CcI10U9VAWZP3i2P/SkULQRNDJqnVz2WOVhTLgIwhPyIDFIoDcSZef DYxNemKmrVo4ZWbuEoZMwRCH1KfQc8iVFM54zlSum4OpmE1/wqQIPItWd6ZjG87T BIZyIcoAg51wLEeB/ppeENDIzcY/mMXicZC2ks+zVUsBmJY6gmHzWisd2YwMmr+c rp+zzk/aLvr6r0qye8dNUyUI6YLYxSS+9CemQquG/HT2FesNZX4= =W14U -----END PGP SIGNATURE----- --gxHsQ59DETEFbQkWNx9D2ieMVVPlRetG0-- From nobody Thu Jun 15 07:16:56 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213112E040 for ; Thu, 15 Jun 2017 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 rxOTTbyEklUV for ; Thu, 15 Jun 2017 07:16:50 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20049.outbound.protection.outlook.com [40.107.2.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C50126B6D for ; Thu, 15 Jun 2017 07:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DyaAmSR49Fz3gWHHjSpswu8jYbLC5PWYNGUT6ciQ7Ls=; b=mzxP01YG2Xy3YSF+mlkMsqhkJVh2HTwhw5/aZ9Srb74AxniUT7a6NBo2jf9/NLH3rPe2j8UBFY59YUh+1MRtY/IwgVEApc/mR+vDN52Y8HzDE3jTvIyqk6wAnZPsX4NPvxpyGLs6dPdD4SVrFxxus2q94VS/bDjEOEHSZygKY+0= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1905.eurprd03.prod.outlook.com (10.168.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 15 Jun 2017 14:16:47 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59%14]) with mapi id 15.01.1157.017; Thu, 15 Jun 2017 14:16:46 +0000 From: "Paterson, Kenny" To: "cfrg@ietf.org" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt Thread-Index: AQHSpud0G7Nvk2NWAEWKLkFqd0wSnqGoglCAgH4EpoA= Date: Thu, 15 Jun 2017 14:16:46 +0000 Message-ID: References: <149061159741.30566.11599293166376872082@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 7:5/GN8F0iZtByc/uLw62uY9K+jMXFYVBq+J0LhHFk1aoP5JYooU9N0twE63dA19VxAPJTpRIuk9RH8GcNf5i4ek1nSQrP2pcywr5tWN6yN5rzfcgvnSApH8KuB/2BKI4CYEZObs+LkipuRo66jfzqv23+tArqJDOOU5siYNqUwZiqg9DjylzN92rQWYg2AgfdEVIV3RLKvddmpUE8EMzRU921KyJe4+nIHpeU7nB4JJZhqcu5SdxexXTfxTqsD50q8DHDxY4qcNAwTjkqHY36WU0Y+jqksgLAz4lQnYxngXehYiZpZoSyqtKToJYP5CAH5Fm7quFu4DCCic1bXtD52g== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39850400002)(39410400002)(24454002)(377454003)(377424004)(6436002)(413944005)(2351001)(39060400002)(478600001)(5640700003)(66066001)(14454004)(6486002)(50986999)(53546009)(54356999)(25786009)(4326008)(2900100001)(74482002)(72206003)(966005)(6506006)(2906002)(6512007)(38730400002)(110136004)(3660700001)(53936002)(3280700002)(76176999)(2950100002)(6246003)(5660300001)(5250100002)(229853002)(551544002)(230783001)(305945005)(42882006)(6916009)(8936002)(1730700003)(81166006)(99286003)(8676002)(2501003)(4001350100001)(102836003)(3846002)(36756003)(6116002)(189998001)(86362001)(6306002)(83506001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-traffictypediagnostic: AM4PR0301MB1905: x-ms-office365-filtering-correlation-id: 90e7ecba-8821-464b-db68-08d4b3f92835 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1905; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1905; x-forefront-prvs: 0339F89554 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <343D67CB0282B2428A4FE96450D2AB75@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2017 14:16:46.8148 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905 Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:16:54 -0000 RGVhciBDRlJHLA0KDQpEbWl0cnkgS2hvdnJhdG92aWNoIGtpbmRseSBwcmVzZW50ZWQgdGhlIGxh dGVzdCBkcmFmdCBmb3IgQXJnb24yIGF0IHRoZQ0KaW50ZXJpbSBDRlJHIG1lZXRpbmcgaW4gUGFy aXMuIEZvciB0aG9zZSBvZiB5b3Ugd2hvIGNvdWxkIG5vdCBhdHRlbmQsIGhpcw0Kc2xpZGVzIGNh biBiZSBmb3VuZCBoZXJlOg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLTIwMTctY2ZyZy0wMS9zbGlkZXMvc2xpZGVzLWludGVyaW0NCi0yMDE3LWNmcmctMDEtc2Vz c2EtYXJnb24yLTAwLnBkZg0KDQoNCk15IHNlbnNlIGZyb20gdGhlIGNvbnN0cnVjdGl2ZSBkaXNj dXNzaW9uIHRoYXQgdG9vayBwbGFjZSBhZnRlciBEbWl0cnkncw0KdGFsayBpbiBQYXJpcyB3YXMg dGhhdCB0aGVyZSBhcmUgbm93IG5vIHJlbWFpbmluZyBzZXJpb3VzIG9iamVjdGlvbnMgdG8NCnRo ZSByZWNvbW1lbmRlZCBwYXJhbWV0ZXJzIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJh ZnQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlydGYtY2ZyZy1h cmdvbjIvDQoNCg0KSWYgdGhlcmUgYXJlIGZ1cnRoZXIgc3Vic3RhbnRpdmUgdGVjaG5pY2FsIGNv bW1lbnRzIGZyb20gdGhlIENGUkcNCm1lbWJlcnNoaXAsIHRoZSBjaGFpcnMgd291bGQgYmUgZ3Jh dGVmdWwgaWYgdGhleSBjb3VsZCBiZSBicm91Z2h0IHRvIHRoZQ0KbGlzdCBpbiB0aGUgbmV4dCBm ZXcgZGF5cy4NCg0KQXNzdW1pbmcgd2UgaGF2ZSBpbmRlZWQgcmVhY2hlZCBjb25zZW5zdXMsIHRo ZW4gd2Ugd2lsbCBiZSBpbiBhIHBvc2l0aW9uDQp0byBtb3ZlIHRvIGxhc3QgY2FsbCBmb3IgdGhp cyBJRC4NCg0KVGhhbmtzLA0KDQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQoNCg0KT24gMjcvMDMv MjAxNyAxMTo1MSwgIkNmcmcgb24gYmVoYWxmIG9mIERtaXRyeSBLaG92cmF0b3ZpY2giDQo8Y2Zy Zy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBraG92cmF0b3ZpY2hAZ21haWwuY29tPiB3 cm90ZToNCg0KPlNvbWUgY29tbWVudHMgb24gYSBuZXcgZHJhZnQ6VmFyaWFudHNBcmdvbjIgZmls bHMgTSBieXRlcyBvZiBtZW1vcnkgaW4gVA0KPml0ZXJhdGlvbnMgb3Zlcg0KPiBpdCwgd2l0aCBN IGFuZCBUIGJlaW5nIHRoZSBwYXJhbWV0ZXJzIHN1cHBsaWVkIHRvIEFyZ29uMiBhbmQgZGV0ZXJt aW5pbmcNCj5pdHMgcGVyZm9ybWFuY2UuIFNwZWVkIG9uIGEgdHlwaWNhbCBzZXJ2ZXIgaXMgbGlu ZWFyIGluIHRoZSBNVCBwcm9kdWN0Lg0KPg0KPlRoZSBBcmdvbjIgZmFtaWx5IGhhcyB0aHJlZSB2 YXJpYW50czogSSwgRCwgYW5kDQo+IElELCB3aGljaCBkaWZmZXIgaW4gdGhlIHdheSBvZiByZXVz aW5nIG1lbW9yeSB0aGF0IGhhcyBiZWVuIGZpbGxlZC4gVGhlDQo+SSB2YXJpYW50IG1ha2VzIHF1 ZXJpZXMgd2l0aCBwcmVkaWN0YWJsZSBhZGRyZXNzZXMsIHdoZXJlYXMgRCBkZXRlcm1pbmVzDQo+ dGhlIGFkZHJlc3NlcyBvbiB0aGUgZmx5IGRlcGVuZGluZyBvbiB0aGUgY3VycmVudCBzdGF0ZSAo YW5kIHRodXMgdGhlDQo+cGFzc3dvcmQpLiBUaGUgSUQgdmFyaWFudCBmb2xsb3dzIEkgZm9yIHRo ZQ0KPiBmaXJzdCBoYWxmIG9mIHRoZSBtZW1vcnkgdXNlZCBhbmQgRCBmb3IgdGhlIHJlc3QgYW5k IHdoaWxlIG92ZXJ3cml0aW5nLg0KPlNpZGUtY2hhbm5lbHNUaGUgc2lkZS1jaGFubmVsIGF0dGFj a3MsIHdoaWNoIGFyZSBvZiBzdGlsbCByaXNpbmcNCj4gY29uY2VybiBpbiB0aGUgc2VjdXJpdHkg Y29tbXVuaXR5LCBhcmUgYXBwbGljYWJsZSB0byB0aGUgRCB2YXJpYW50IGFzDQo+dGhlIG1lbW9y eSBhZGRyZXNzZXMgYW5kIHRodXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBhc3N3b3JkIG9yIG90 aGVyDQo+c2VjcmV0IGlucHV0cyBjYW4gYmUgZGV0ZXJtaW5lZCBmcm9tIHRoZSB0aW1pbmcgbGVh a3MuIFRoZSBJIHZhcmlhbnQgaXMNCj5jb21wbGV0ZWx5IGludnVsbmVyYWJsZSB0byB0aGlzIGF0 dGFjaywgYW5kDQo+IHRoZSBJRCB2YXJpYW50IHByb3ZpZGVzIG9ubHkgYSBjb25zdGFudCBmYWN0 b3IgaW1wcm92ZW1lbnQgZm9yIHRoZQ0KPmF0dGFja2VyLg0KPkhhcmR3YXJlIGFuZCB0cmFkZW9m ZnNUaGUgTSBhbmQgVCBwYXJhbWV0ZXJzIGRldGVybWluZSB0aGUgY29zdCBvZg0KPmJydXRlZm9y Y2luZw0KPiBwYXNzd29yZHMgb24gY3VzdG9tIGhhcmR3YXJlLCB3aGljaCBpcyBwcm9wb3J0aW9u YWwgdG8gTTJUDQo+IGlmIHdlIGZvbGxvdyB0aGUgdHJhZGl0aW9uYWwgdGltZS1hcmVhIHByb2R1 Y3QgbWV0cmljLiBUaGUgdGltZS1tZW1vcnkNCj50cmFkZW9mZiBhbmFseXNpcyBbMl0gc2hvd3Mg dGhhdCB0aGUgYnJ1dGVmb3JjZSBjb3N0IGZvciB0aGUgSSB2YXJpYW50DQo+Y2FuIGJlIGNoYW5n ZWQgdG8gTTJUL1EoTSxUKQ0KPiBmb3Igc29tZSBxdWFsaXR5IGZ1bmN0aW9uIFEuIEZvciBpbnN0 YW5jZSwgUSgyMzAsMSk9NSwNCj4gUSgyMzAsNCk9Mi41Lg0KPg0KPlRoZSBEIHZhcmlhbnQgaXMg aW52dWxuZXJhYmxlIHRvIHRoZSBhcHByb2FjaCBbMl0sDQo+IGFuZCB0aGUgc2F2aW5ncyBmYWN0 b3IgaW4gdGhlIElEIHZhcmlhbnQgaXMgdXBwZXIgYm91bmRlZCBieSBmYWN0b3IgMg0KPmZvciBh bGwgcGFyYW1ldGVycy4NCj5EZWZlbmRlciB0cmFkZW9mZiBhbmQgdWx0aW1hdGUNCj4gcmVjb21t ZW5kYXRpb25zSW4gcHVibGljIGFuZCBwcml2YXRlIGNvbnZlcnNhdGlvbnMgd2l0aCBzZWN1cml0 eQ0KPiBhcmNoaXRlY3RzIGluIHRoZSBpbmR1c3RyeSB3ZSBsZWFybmVkIHRoYXQgdGhlIGJvdHRs ZW5lY2sgaW4gYSBzeXN0ZW0NCj5lbXBsb3lpbmcgdGhlIHBhc3N3b3JkLWhhc2hpbmcgZnVuY3Rp b24gaXMgdGhlIGZ1bmN0aW9uIGxhdGVuY3kgcmF0aGVyDQo+dGhhbiBtZW1vcnkgY29zdHMuIFdl IHRoZW4gYXNzdW1lIHRoYXQgYSByYXRpb25hbCBkZWZlbmRlciB3b3VsZCBsaWtlIHRvDQo+bWF4 aW1pemUgdGhlIGJydXRlZm9yY2UgY29zdHMgZm9yIHRoZSBhdHRhY2tlcg0KPiBlcXVpcHBlZCB3 aXRoIGEgbGlzdCBvZiBoYXNoZXMsIHNhbHRzLCBhbmQgdGltaW5nIGluZm9ybWF0aW9uLCBmb3Ig Zml4ZWQNCj5jb21wdXRpbmcgdGltZSBvbiB0aGUNCj4gZGVmZW5kZXLigJlzIG1hY2hpbmUuICBJ biB0aGlzIGFzc3VtcHRpb24gdGhlIGRlZmVuZGVyIGtlZXBzIHRoZSBNVA0KPnByb2R1Y3QgY29u c3RhbnQgYW5kIG1heGltaXplcyB0aGUgbG9zc2VzIE0vUShNLFQpLg0KPiBUaGUgYXV0aG9ycyBv ZiBbMl0gcHJvdmlkZXMgdXMgd2l0aCBhdHRhY2sgY29zdCBlc3RpbWF0ZXMgZm9yIGNvbnN0YW50 DQo+TVQgPSAyMjgsMjMwLDIzMg0KPiAobWVhc3VyZWQgaW4gaXRlcmF0aW9uLWJ5dGVzKQ0KPg0K PldlIHVsdGltYXRlbHkgcmVjb21tZW5kIHRoZSBJRCB2YXJpYW50IHdpdGggVD0xIGFuZCBtYXhp bXVtIE0gYXMgYQ0KPmRlZmF1bHQgc2V0dGluZyBmb3IgYWxsIGVudmlyb25tZW50cywgd2hpY2gg aXMgc2VjdXJlDQo+IGFnYWluc3Qgc2lkZS1jaGFubmVsIGF0dGFja3MgYW5kIHByb2hpYml0IGFk dmVyc2FyaWFsIGFkdmFudGFnZSBvbg0KPmRlZGljYXRlZCBicnV0ZWZvcmNlIGhhcmR3YXJlLg0K Pg0KPg0KPlJlZmVyZW5jZXNbMV0NCj7igJxFZmZpY2llbnRseSBDb21wdXRpbmcgRGF0YS1JbmRl cGVuZGVudA0KPiBNZW1vcnktSGFyZCBGdW5jdGlvbnPigJ0gPGh0dHA6Ly9lcHJpbnQuaWFjci5v cmcvMjAxNi8xMTUucGRmPg0KPlsyXQ0KPuKAnFRvd2FyZHMgUHJhY3RpY2FsIEF0dGFja3Mgb24N Cj4gQXJnb24yaSBhbmQgQmFsbG9vbiBIYXNoaW5n4oCdICA8aHR0cDovL2VwcmludC5pYWNyLm9y Zy8yMDE2Lzc1OS5wZGY+DQo+DQo+DQo+DQo+DQo+DQo+T24gTW9uLCBNYXIgMjcsIDIwMTcgYXQg MTI6NDYgUE0sIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPg0KPg0KPkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cw0KPmRpcmVjdG9yaWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENy eXB0byBGb3J1bSBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFRo ZSBtZW1vcnktaGFyZCBBcmdvbjIgcGFzc3dvcmQgaGFzaCBhbmQNCj5wcm9vZi1vZi13b3JrIGZ1 bmN0aW9uDQo+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBBbGV4IEJpcnl1a292DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICBEYW5pZWwgRGludQ0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgRG1pdHJ5IEtob3ZyYXRvdmljaA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgU2ltb24g Sm9zZWZzc29uDQo+ICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pcnRmLWNmcmctYXJn b24yLTAyLnR4dA0KPiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjYNCj4gICAgICAgIERhdGUg ICAgICAgICAgICA6IDIwMTctMDMtMjcNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB0aGUgQXJnb24yIG1lbW9yeS1oYXJkIGZ1bmN0aW9uIGZvciBwYXNzd29yZA0K PiAgIGhhc2hpbmcgYW5kIHByb29mLW9mLXdvcmsgYXBwbGljYXRpb25zLiAgV2UgcHJvdmlkZSBh biBpbXBsZW1lbnRlcg0KPiAgIG9yaWVudGVkIGRlc2NyaXB0aW9uIHRvZ2V0aGVyIHdpdGggc2Ft cGxlIGNvZGUgYW5kIHRlc3QgdmVjdG9ycy4gIFRoZQ0KPiAgIHB1cnBvc2UgaXMgdG8gc2ltcGxp ZnkgYWRvcHRpb24gb2YgQXJnb24yIGZvciBJbnRlcm5ldCBwcm90b2NvbHMuDQo+DQo+DQo+VGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi8NCj4NCj5U aGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDINCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDINCj4N Cj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDIN Cj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+dG9vbHMuaWV0Zi5vcmcgPGh0dHA6Ly90b29s cy5pZXRmLm9yZz4uDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DZnJn IG1haWxpbmcgbGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NmcmcNCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4tLSANCj5CZXN0IHJlZ2Fy ZHMsDQo+RG1pdHJ5IEtob3ZyYXRvdmljaA0KPg0KPg0KDQo= From nobody Thu Jun 15 07:25:00 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBD3126B6D for ; Thu, 15 Jun 2017 07:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 Y_SChSdIpDDM for ; Thu, 15 Jun 2017 07:24:57 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0074.outbound.protection.outlook.com [104.47.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8307D129A99 for ; Thu, 15 Jun 2017 07:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NkGH08Q8lgLv1wKUz/o8MKhaq/NZAi4p7gJYLc1gT8A=; b=Tcgw0qV/XEplsjy6QfocxlRKqiUykDMmHvWeM/j25vsViFoQmkJKeslXUqdagMgHiqRVdGIU1kXYxf4WVbiCLSpvtiIlIjXNHFVaBgjRa+Cf3yupDzb9rPAge80UiDt5SwdJTVlJyXy12r2cPZZm8Nnnxv8arXIzH4aomg8h2M4= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 15 Jun 2017 14:24:54 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59%14]) with mapi id 15.01.1157.017; Thu, 15 Jun 2017 14:24:53 +0000 From: "Paterson, Kenny" To: "cfrg@ietf.org" CC: "agl@google.com" , Alexey Melnikov , Shay Gueron , "Yehuda Lindell" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt Thread-Index: AQHSjfILPJEKyD2c8U+2aZYUqmbh9aF2yOAAgAB/nACAr3KmgA== Date: Thu, 15 Jun 2017 14:24:53 +0000 Message-ID: References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:exLL/rjeKuJFBreeYhc6q0qOF0CkAhQ8gdLF8N0bp2Wz36ezcNcrzDgrpJdgojqR3zu6/S6Idx0zV1gCzVkGa0QErxr1BptVkQbulf7/BOq1POcLoYEbADQJafCh5GbRF/4lI/vGiWGELYQqUtRnQ2m8WE36kMdE0224H5OBf/RW0/Z+eZHk0v/eVIzDXs2NXDGNik1iQ7K+cgSofhA+FFdw6CLBbI5uxOEPhuoYC6om3dYXMN9nLU4/BEdfCJIDm+V6hStNs2f7dW2g0EtrTZGUH3g8IVyTz45+SllQ+fa/VQiX8MfN4t8LKjrw8IWKYmZQODPxaVTUA33pM7xvOQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39840400002)(39400400002)(39850400002)(24454002)(377424004)(377454003)(478600001)(36756003)(2501003)(413944005)(72206003)(25786009)(83506001)(5250100002)(4326008)(14454004)(39060400002)(86362001)(189998001)(230783001)(2351001)(4001350100001)(66066001)(2900100001)(54356999)(50986999)(6246003)(5640700003)(6436002)(76176999)(53936002)(3660700001)(6506006)(6306002)(38730400002)(3280700002)(305945005)(7736002)(74482002)(110136004)(54906002)(2906002)(6116002)(99286003)(102836003)(6486002)(3846002)(1730700003)(6512007)(2950100002)(6916009)(8936002)(8676002)(81166006)(229853002)(42882006)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-ms-office365-filtering-correlation-id: df706123-fd53-45a6-7519-08d4b3fa4a27 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1906; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0339F89554 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2017 14:24:53.2597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:25:00 -0000 RGVhciBDRlJHLA0KDQpBc2lkZSBmcm9tIHNvbWUgaGVscGZ1bCBjb21tZW50cyBmcm9tIERhdmlk IE1jR3JldywgdGhlcmUgaGFzIGJlZW4gbm8NCnN1YnN0YW50aXZlIGRpc2N1c3Npb24gb2YgdGhp cyBkcmFmdCBmb3Igc29tZSBtb250aHMuDQoNCklmIHBlb3BsZSBoYXZlIHJlbWFpbmluZyB0ZWNo bmljYWwgY29tbWVudHMsIHBsZWFzZSB3b3VsZCB0aGV5IGJyaW5nIHRoZW0NCnRvIHRoaXMgbGlz dCBpbiB0aGUgbmV4dCBmZXcgZGF5cz8NCg0KQXNzdW1pbmcgdGhlcmUgYXJlIG5vIG1ham9yIG9i amVjdGlvbnMsIHdlIHNob3VsZCB0aGVuIGJlIGluIGEgcG9zaXRpb24gdG8NCnN0YXJ0IGxhc3Qg Y2FsbCBmb3IgdGhpcyBJRCAobW9kdWxvIGFuIHVwZGF0ZSB0byBhZGRyZXNzIHRoZSBtaW5vciBp c3N1ZXMNCmlkZW50aWZpZWQgYnkgRGF2aWQpLg0KDQpDaGVlcnMsDQoNCktlbm55IChmb3IgdGhl IGNoYWlycykNCg0KDQo+T24gMjMvMDIvMjAxNyAxNjozMiwgIkNmcmcgb24gYmVoYWxmIG9mIEFk YW0gTGFuZ2xleSINCj48Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBhZ2xAaW1w ZXJpYWx2aW9sZXQub3JnPiB3cm90ZToNCj4NCj4+T24gVGh1LCBGZWIgMjMsIDIwMTcgYXQgODoy OCBBTSwgIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPj4+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0K Pj4+ZGlyZWN0b3JpZXMuDQo+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ3J5 cHRvIEZvcnVtIG9mIHRoZSBJRVRGLg0KPj4+DQo+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAg OiBBRVMtR0NNLVNJVjogTm9uY2UgTWlzdXNlLVJlc2lzdGFudA0KPj4+QXV0aGVudGljYXRlZCBF bmNyeXB0aW9uDQo+Pj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBTaGF5IEd1ZXJvbg0KPj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgQWRhbSBMYW5nbGV5DQo+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICBZZWh1ZGEgTGluZGVsbA0KPj4+ICAgICAgICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNC50eHQNCj4+PiAgICAgICAgIFBhZ2VzICAgICAg ICAgICA6IDQ2DQo+Pj4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTAyLTIzDQo+Pg0K Pj5EZWFyIGFsbCwNCj4+DQo+PlJldmlzaW9uIDA0IG9mIHRoZSBBRVMtR0NNLVNJViBkcmFmdA0K Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1nY21zaXYtMDQp IGhhcyBqdXN0IGJlZW4NCj4+cHVibGlzaGVkLiBUaGlzIGNvbnRhaW5zIG9ubHkgdGlkeS11cHMg ZnJvbSByZXZpc2lvbiAwM+KAlG5vIHN1YnN0YW50aXZlDQo+PmNoYW5nZXMgaGF2ZSBiZWVuIG1h ZGUuDQo+Pg0KPj5Nb3N0IGltcG9ydGFudGx5LCBpdCBub3cgcmVmZXJlbmNlcyBhIHBhcGVyDQo+ PihodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE3LzE2OCkgYnkgU2hheSBhbmQgWWVodWRhIGlu IHdoaWNoIHRoZXkNCj4+Z2l2ZSBwcmVjaXNlIHNlY3VyaXR5IGJvdW5kcyBmb3IgQUVTLUdDTS1T SVYuIFNwZWNpZmljYWxseSBJJ2QgbGlrZSB0bw0KPj5oaWdobGlnaHQgdG8gdGhlIGdyb3VwIHRo ZW9yZW0gc2l4ICh3aGljaCBnaXZlcyB0aG9zZSBib3VuZHMpIGFuZA0KPj5zZWN0aW9uIDUuMyAo d2hpY2ggZ2l2ZXMgY29uY3JldGUgdmFsdWVzIG9mIHRob3NlIGJvdW5kcyBhdCBhIG51bWJlcg0K Pj5vZiBsb2NhdGlvbnMgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3BhY2UpLg0KPj4NCj4+SW4gbGln aHQgb2YgcHJldmlvdXMgZGlzY3Vzc2lvbnMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAsIHNlY3Rpb24g c2V2ZW4NCj4+aW5jbHVkZXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSBtZWFuaW5nIG9mIG5vbmNl LW1pc3VzZSByZXNpc3RhbmNlLg0KPj4NCj4+KENvbW1lbnRzIGFib3V0IHRoZSBwYXBlciwgaW5j bHVkaW5nIHNpZ2h0aW5ncyBvZiB0eXBvcywgYXJlIHdlbGNvbWUNCj4+dG8gYmUgc2VudCB0byB1 cyBkaXJlY3RseTsgbm8gbmVlZCB0byBjbHV0dGVyIHRoaXMgbGlzdCB3aXRoIHRoZW0uKQ0KPj4N Cj4+DQo+PkNoZWVycw0KPj4NCj4+QUdMDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj5DZnJnIG1haWxpbmcgbGlzdA0KPj5DZnJnQGlydGYu b3JnDQo+Pmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPg0KDQo= From nobody Thu Jun 15 07:41:56 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08821294E8 for ; Thu, 15 Jun 2017 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 6022G0IAxllW for ; Thu, 15 Jun 2017 07:41:50 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73CA128B93 for ; Thu, 15 Jun 2017 07:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XtQ61S+WJaLIqq4IPlMzuFHI/qi9CRmD02+2T+znI6U=; b=qRuKYo30/aMXldcVhUz3r+GL2pD7mhXi5rFneen1dsqZsqC1iTcUIdsTMhvWh/SDX2wtEktKDMIHsHiF5yDu4WpKityVcHP4d9ubLvK9KprYt6ZmVjfBjKxot8Yr0CMMRnxlShwnIaF4eeB7Bnnsi8WIORDD48EU+zShchntNUQ= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Thu, 15 Jun 2017 14:41:47 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59%14]) with mapi id 15.01.1157.017; Thu, 15 Jun 2017 14:41:46 +0000 From: "Paterson, Kenny" To: "Paterson, Kenny" , "cfrg@ietf.org" CC: "agl@google.com" , Alexey Melnikov , Shay Gueron , "Yehuda Lindell" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt Thread-Index: AQHSjfILPJEKyD2c8U+2aZYUqmbh9aF2yOAAgAB/nACAr3KmgIAABJ0A Date: Thu, 15 Jun 2017 14:41:46 +0000 Message-ID: References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: rhul.ac.uk; dkim=none (message not signed) header.d=none;rhul.ac.uk; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:cdRsd0Uqg7A1v5hUnfTcc/iVVIUTlqbH7Bejls6WrXcbEcrq/07QqlZCVmfMLKeNcecwjrcmG22RhcxWhTyxMMMejBcB/WOFLFixB4XxCFxP7/lytXRLJa3fi6hCzk60e2eJAZBe/WZaiq0CB+5QfyQvrF+Hni4iSq6MCxJYryt+UVgdjeN4anKcp5VWR3nAYiNIYMZ3+za+55odupOmjhELulfsUjSa0nElyAQ1PHHp7eZsWQeF5XX0MkYDPnuPg2u+dGMcSE/WO36PXbqLCKlHfZayi1d41j9WyJ26ZP7mdrkJ3mh4VJ//aDZdqdCMRvYCgwYz2pW5+/MxBW2f6Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(24454002)(377424004)(377454003)(93886004)(478600001)(36756003)(2501003)(413944005)(72206003)(83506001)(25786009)(5250100002)(4326008)(14454004)(39060400002)(53546009)(230783001)(86362001)(189998001)(4001350100001)(66066001)(2900100001)(54356999)(50986999)(6246003)(6436002)(76176999)(53936002)(3660700001)(6506006)(6306002)(74482002)(38730400002)(3280700002)(305945005)(7736002)(54906002)(2906002)(6116002)(99286003)(102836003)(6486002)(3846002)(6512007)(2950100002)(8936002)(8676002)(81166006)(229853002)(42882006)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-ms-office365-filtering-correlation-id: 32a2cd4f-c617-47ad-eeb2-08d4b3fca62a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0301MB1906; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0339F89554 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2017 14:41:46.5481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:41:53 -0000 RGVhciBDRlJHLA0KDQpBcG9sb2dpZXMsIG15IG1lc3NhZ2UgYmVsb3cgc2hvdWxkIGhhdmUgcmVm ZXJlbmNlZA0KDQogIGRyYWZ0LWlydGYtY2ZyZy1nY21zaXYtMDUudHh0DQoNCmluc3RlYWQgb2Yg DQoNCiAgZHJhZnQtaXJ0Zi1jZnJnLWdjbXNpdi0wNC50eHQNCg0KLSBub3QgZW5vdWdoIChTTEVF UCB8fCBDT0ZGRUUpLg0KDQpDaGVlcnMsDQoNCktlbm55IA0KDQpPbiAxNS8wNi8yMDE3IDE1OjI0 LCAiUGF0ZXJzb24sIEtlbm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQoN Cj5EZWFyIENGUkcsDQo+DQo+QXNpZGUgZnJvbSBzb21lIGhlbHBmdWwgY29tbWVudHMgZnJvbSBE YXZpZCBNY0dyZXcsIHRoZXJlIGhhcyBiZWVuIG5vDQo+c3Vic3RhbnRpdmUgZGlzY3Vzc2lvbiBv ZiB0aGlzIGRyYWZ0IGZvciBzb21lIG1vbnRocy4NCj4NCj5JZiBwZW9wbGUgaGF2ZSByZW1haW5p bmcgdGVjaG5pY2FsIGNvbW1lbnRzLCBwbGVhc2Ugd291bGQgdGhleSBicmluZyB0aGVtDQo+dG8g dGhpcyBsaXN0IGluIHRoZSBuZXh0IGZldyBkYXlzPw0KPg0KPkFzc3VtaW5nIHRoZXJlIGFyZSBu byBtYWpvciBvYmplY3Rpb25zLCB3ZSBzaG91bGQgdGhlbiBiZSBpbiBhIHBvc2l0aW9uIHRvDQo+ c3RhcnQgbGFzdCBjYWxsIGZvciB0aGlzIElEIChtb2R1bG8gYW4gdXBkYXRlIHRvIGFkZHJlc3Mg dGhlIG1pbm9yIGlzc3Vlcw0KPmlkZW50aWZpZWQgYnkgRGF2aWQpLg0KPg0KPkNoZWVycywNCj4N Cj5LZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQo+DQo+DQo+Pk9uIDIzLzAyLzIwMTcgMTY6MzIsICJD ZnJnIG9uIGJlaGFsZiBvZiBBZGFtIExhbmdsZXkiDQo+PjxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcg b24gYmVoYWxmIG9mIGFnbEBpbXBlcmlhbHZpb2xldC5vcmc+IHdyb3RlOg0KPj4NCj4+Pk9uIFRo dSwgRmViIDIzLCAyMDE3IGF0IDg6MjggQU0sICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3 cm90ZToNCj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj4+ZGlyZWN0b3JpZXMuDQo+Pj4+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENyeXB0byBGb3J1bSBvZiB0aGUgSUVURi4NCj4+Pj4NCj4+ Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBRVMtR0NNLVNJVjogTm9uY2UgTWlzdXNlLVJl c2lzdGFudA0KPj4+PkF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KPj4+PiAgICAgICAgIEF1dGhv cnMgICAgICAgICA6IFNoYXkgR3Vlcm9uDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg QWRhbSBMYW5nbGV5DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWWVodWRhIExpbmRl bGwNCj4+Pj4gICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pcnRmLWNmcmctZ2Ntc2l2 LTA0LnR4dA0KPj4+PiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDQ2DQo+Pj4+ICAgICAgICAg RGF0ZSAgICAgICAgICAgIDogMjAxNy0wMi0yMw0KPj4+DQo+Pj5EZWFyIGFsbCwNCj4+Pg0KPj4+ UmV2aXNpb24gMDQgb2YgdGhlIEFFUy1HQ00tU0lWIGRyYWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1nY21zaXYtMDQpIGhhcyBqdXN0IGJlZW4NCj4+ PnB1Ymxpc2hlZC4gVGhpcyBjb250YWlucyBvbmx5IHRpZHktdXBzIGZyb20gcmV2aXNpb24gMDPi gJRubyBzdWJzdGFudGl2ZQ0KPj4+Y2hhbmdlcyBoYXZlIGJlZW4gbWFkZS4NCj4+Pg0KPj4+TW9z dCBpbXBvcnRhbnRseSwgaXQgbm93IHJlZmVyZW5jZXMgYSBwYXBlcg0KPj4+KGh0dHBzOi8vZXBy aW50LmlhY3Iub3JnLzIwMTcvMTY4KSBieSBTaGF5IGFuZCBZZWh1ZGEgaW4gd2hpY2ggdGhleQ0K Pj4+Z2l2ZSBwcmVjaXNlIHNlY3VyaXR5IGJvdW5kcyBmb3IgQUVTLUdDTS1TSVYuIFNwZWNpZmlj YWxseSBJJ2QgbGlrZSB0bw0KPj4+aGlnaGxpZ2h0IHRvIHRoZSBncm91cCB0aGVvcmVtIHNpeCAo d2hpY2ggZ2l2ZXMgdGhvc2UgYm91bmRzKSBhbmQNCj4+PnNlY3Rpb24gNS4zICh3aGljaCBnaXZl cyBjb25jcmV0ZSB2YWx1ZXMgb2YgdGhvc2UgYm91bmRzIGF0IGEgbnVtYmVyDQo+Pj5vZiBsb2Nh dGlvbnMgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3BhY2UpLg0KPj4+DQo+Pj5JbiBsaWdodCBvZiBw cmV2aW91cyBkaXNjdXNzaW9ucyBpbiB0aGUgd29ya2luZyBncm91cCwgc2VjdGlvbiBzZXZlbg0K Pj4+aW5jbHVkZXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSBtZWFuaW5nIG9mIG5vbmNlLW1pc3Vz ZSByZXNpc3RhbmNlLg0KPj4+DQo+Pj4oQ29tbWVudHMgYWJvdXQgdGhlIHBhcGVyLCBpbmNsdWRp bmcgc2lnaHRpbmdzIG9mIHR5cG9zLCBhcmUgd2VsY29tZQ0KPj4+dG8gYmUgc2VudCB0byB1cyBk aXJlY3RseTsgbm8gbmVlZCB0byBjbHV0dGVyIHRoaXMgbGlzdCB3aXRoIHRoZW0uKQ0KPj4+DQo+ Pj4NCj4+PkNoZWVycw0KPj4+DQo+Pj5BR0wNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PkNmcmcgbWFpbGluZyBsaXN0DQo+Pj5DZnJn QGlydGYub3JnDQo+Pj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcN Cj4+DQo+DQoNCg== From nobody Thu Jun 15 08:36:41 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875781294F8 for ; Thu, 15 Jun 2017 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82AX9Rf1YH0q for ; Thu, 15 Jun 2017 08:36:37 -0700 (PDT) Received: from mailhub131.itcs.purdue.edu (mailhub131.itcs.purdue.edu [128.210.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B77126B6E for ; Thu, 15 Jun 2017 08:36:37 -0700 (PDT) Received: from exchange.purdue.edu (exchange.purdue.edu [128.210.1.29]) by mailhub131.itcs.purdue.edu (8.14.4/8.14.4/mta-nopmx.smtp.purdue.edu) with ESMTP id v5FFaZ7Q011033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2017 11:36:36 -0400 Received: from wppexc07.purdue.lcl (172.30.136.180) by wppexc12.purdue.lcl (172.30.136.185) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 15 Jun 2017 11:36:35 -0400 Received: from wppexc07.purdue.lcl ([fe80::49db:3fa0:d668:8da4]) by wppexc07.purdue.lcl ([fe80::49db:3fa0:d668:8da4%14]) with mapi id 15.00.1178.000; Thu, 15 Jun 2017 11:36:35 -0400 From: "Blocki, Jeremiah M" To: "Paterson, Kenny" , "cfrg@ietf.org" Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt Thread-Index: AQHSpudr72kny3qHWUqPlyLx0FrlmqGoxV6AgH3z6wD//8H0gA== Date: Thu, 15 Jun 2017 15:36:34 +0000 Message-ID: References: <149061159741.30566.11599293166376872082@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.10.9.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.2.2308539 X-PerlMx-URL-Scanned: Yes X-PerlMx-Virus-Scanned: Yes Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-argon2-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:36:40 -0000 SGkgQWxsLA0KDQoxKSBJIGFncmVlIHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIHRvIHVzZSBBcmdv bjJpZCBmb3IgcGFzc3dvcmQgaGFzaGluZyBhcyBpdCBhcHBlYXJzIHRvIHN0cmlrZSBhIHJlYXNv bmFibGUgYmFsYW5jZSBiZXR3ZWVuIHNpZGUtY2hhbm5lbCByZXNpc3RhbmNlIGFuZCBwYXJhbGxl bCBhdHRhY2tzLiBJZiB0aGVyZSBhcmUgbm8gc2lkZSBjaGFubmVsIGF0dGFja3MgdGhlbiBBcmdv bjJpZCByZXNpc3RzIHJlY2VudCBwYXJhbGxlbGl6YXRpb24gYXR0YWNrcyBbQUIxNl0sIGFuZCBp ZiB0aGVyZSBhcmUgc2lkZSBjaGFubmVsIGF0dGFja3MgdGhlbiBzZWN1cml0eSBzaG91bGQgaG9w ZWZ1bGx5IGp1c3QgcmVkdWNlIHRvIHRoYXQgb2YgQXJnb24yaS4NCg0KMikgUmVnYXJkaW5nIHRo ZSBkYXRhLWluZGVwZW5kZW50IG1vZGUgKEFyZ29uMmkpIEkgd2FudGVkIHRvIGhpZ2hsaWdodCB0 d28gcmVjZW50IHJlc3VsdHMgZnJvbSBteSBvd24gd29yayB3aGljaCBJIGJlbGlldmUgYXJlIHJl bGV2YW50IHRvIHRoZSBkaXNjdXNzaW9uOg0KDQphKSBTYW1zb24gWmhvdSBhbmQgSSByZWNlbnRs eSBwcm92ZWQgbmV3ICpsb3dlciBib3VuZHMqIGZvciBBcmdvbjJpICh0aGUgcHJvb2YgZW5jb21w YXNzZXMgdmVyc2lvbnMgMS4yKykuIFRoZSBwYXBlciBpcyBhdmFpbGFibGUgb24gZVByaW50IGh0 dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy80NDIucGRmLiAgSW4gc3VtbWFyeSwgdGhlIGN1bXVs YXRpdmUgbWVtb3J5IGNvc3QgKGNtYykgb2YgY29tcHV0aW5nIEFyZ29uMmlCICh2ZXJzaW9ucyAx LjIrKSBpcyBhdCBsZWFzdCBPbWVnYShuXnsxLjc1fSkgKGlnbm9yaW5nIGxvZ2FyaXRobWljIGZh Y3RvcnMpLCB3aGljaCBtZWFucyB0aGF0IGluIGFuIGFzeW1wdG90aWMgc2Vuc2UgdGhlIGV4aXN0 aW5nIGF0dGFja3MgYXJlIG5lYXJseSBvcHRpbWFsLiAgVGhlIG5ldyBsb3dlciBib3VuZCBkZW1v bnN0cmF0ZXMgdGhhdCBBcmdvbjJpQiAodmVyc2lvbnMgMS4yKykgaW1wcm92ZXMgb24gQXJnb24y aUEgKHYuMS4xKSBhbmQgb3RoZXIgY29tcGV0aW5nIGRhdGEtaW5kZXBlbmRlbnQgbWVtb3J5IGhh cmQgZnVuY3Rpb25zIChpTUhGcykgc3VjaCBhcyBCYWxsb29uIEhhc2hpbmcgKGNtYyA8PSBPKG5e MS43MDgpKSBvciBDYXRlbmEgKGNtYyA8PSBPKG5eezEuNjI1fSkpLiANCg0KYikgRm9yIGFuIGlN SEYgdGhlIGJlc3Qgb25lIGNhbiBob3BlIGZvciBpcyBjbWMgPj0gbl4yL2xvZyhuKSBbQUIxNl0u IFRoZXJlIGFyZSBtYXRjaGluZyBjb25zdHJ1Y3Rpb25zIFtBQlAxN10sIGJ1dCB1bnRpbCByZWNl bnRseSB0aGVzZSBjb25zdHJ1Y3Rpb25zIGhhdmUgYmVlbiBwdXJlbHkgdGhlb3JldGljYWwgZS5n LiwgcmVseWluZyBvbiBhbiBleHBlbnNpdmUgY29tYmluYXRvcmlhbCBjb25zdHJ1Y3Rpb24gb2Yg RXJkb3MsIEdyYWhhbSBhbmQgU3plbWVyZWRpIG9mIGRlcHRoLXJvYnVzdCBncmFwaHMuIEpvZWwg QWx3ZW4sIEJlbiBIYXJzaGEgYW5kIEkgcmVjZW50bHkgZ2F2ZSBhIHZlcnkgc2ltcGxlIGNvbnN0 cnVjdGlvbiBvZiBhIGRlcHRoLXJvYnVzdCBncmFwaCwgd2hpY2ggaXMgZWFzeSB0byBpbXBsZW1l bnQgYXMgcGFydCBvZiBhbiBpTUhGLiBPdXIgZW1waXJpY2FsIGFuYWx5c2lzIGluZGljYXRlcyB0 aGF0IHRoZSBuZXcgaU1IRiBjb25zdHJ1Y3Rpb24gcHJvdmlkZXMgc3Ryb25nIHJlc2lzdGFuY2Ug dG8gcGFyYWxsZWwgYXR0YWNrcy4gV2UgYWxzbyBtb2RpZmllZCB0aGUgQXJnb24yaSBpbXBsZW1l bnRhdGlvbiB0byB1c2UgdGhpcyBuZXcgZWRnZSBkaXN0cmlidXRlZC4gVGhlIG1vZGlmaWNhdGlv bnMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgcGVyZm9ybWFuY2UuIEZvciB0aGUgY3VyaW91cyB3 ZSBoYXZlIGNvZGUgYXZhaWxhYmxlIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9QcmFjdGljYWwtR3Jh cGhzL0FyZ29uMi1QcmFjdGljYWwtR3JhcGguIFRoZSBwYXBlciBpcyBhdmFpbGFibGUgb24gZVBy aW50IGF0IGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy80NDMucGRmLiAgICAgIA0KICAgICAg ICAgIA0KVGhhbmtzLA0KDQpKZXJlbWlhaA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQ2ZyZyBbbWFpbHRvOmNmcmctYm91bmNlc0BpcnRmLm9yZ10gT24gQmVoYWxmIE9mIFBh dGVyc29uLCBLZW5ueQ0KU2VudDogVGh1cnNkYXksIEp1bmUgMTUsIDIwMTcgMTA6MTcgQU0NClRv OiBjZnJnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NmcmddIEktRCBBY3Rpb246IGRyYWZ0LWly dGYtY2ZyZy1hcmdvbjItMDIudHh0DQoNCkRlYXIgQ0ZSRywNCg0KRG1pdHJ5IEtob3ZyYXRvdmlj aCBraW5kbHkgcHJlc2VudGVkIHRoZSBsYXRlc3QgZHJhZnQgZm9yIEFyZ29uMiBhdCB0aGUgaW50 ZXJpbSBDRlJHIG1lZXRpbmcgaW4gUGFyaXMuIEZvciB0aG9zZSBvZiB5b3Ugd2hvIGNvdWxkIG5v dCBhdHRlbmQsIGhpcyBzbGlkZXMgY2FuIGJlIGZvdW5kIGhlcmU6DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0tMjAxNy1jZnJnLTAxL3NsaWRlcy9zbGlkZXMtaW50 ZXJpbQ0KLTIwMTctY2ZyZy0wMS1zZXNzYS1hcmdvbjItMDAucGRmDQoNCg0KTXkgc2Vuc2UgZnJv bSB0aGUgY29uc3RydWN0aXZlIGRpc2N1c3Npb24gdGhhdCB0b29rIHBsYWNlIGFmdGVyIERtaXRy eSdzIHRhbGsgaW4gUGFyaXMgd2FzIHRoYXQgdGhlcmUgYXJlIG5vdyBubyByZW1haW5pbmcgc2Vy aW91cyBvYmplY3Rpb25zIHRvIHRoZSByZWNvbW1lbmRlZCBwYXJhbWV0ZXJzIGluIHRoZSBsYXRl c3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlydGYtY2ZyZy1hcmdvbjIvDQoNCg0KSWYgdGhlcmUgYXJlIGZ1cnRoZXIgc3Vi c3RhbnRpdmUgdGVjaG5pY2FsIGNvbW1lbnRzIGZyb20gdGhlIENGUkcgbWVtYmVyc2hpcCwgdGhl IGNoYWlycyB3b3VsZCBiZSBncmF0ZWZ1bCBpZiB0aGV5IGNvdWxkIGJlIGJyb3VnaHQgdG8gdGhl IGxpc3QgaW4gdGhlIG5leHQgZmV3IGRheXMuDQoNCkFzc3VtaW5nIHdlIGhhdmUgaW5kZWVkIHJl YWNoZWQgY29uc2Vuc3VzLCB0aGVuIHdlIHdpbGwgYmUgaW4gYSBwb3NpdGlvbiB0byBtb3ZlIHRv IGxhc3QgY2FsbCBmb3IgdGhpcyBJRC4NCg0KVGhhbmtzLA0KDQpLZW5ueSAoZm9yIHRoZSBjaGFp cnMpDQoNCg0KT24gMjcvMDMvMjAxNyAxMTo1MSwgIkNmcmcgb24gYmVoYWxmIG9mIERtaXRyeSBL aG92cmF0b3ZpY2giDQo8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBraG92cmF0 b3ZpY2hAZ21haWwuY29tPiB3cm90ZToNCg0KPlNvbWUgY29tbWVudHMgb24gYSBuZXcgZHJhZnQ6 VmFyaWFudHNBcmdvbjIgZmlsbHMgTSBieXRlcyBvZiBtZW1vcnkgaW4gDQo+VCBpdGVyYXRpb25z IG92ZXIgIGl0LCB3aXRoIE0gYW5kIFQgYmVpbmcgdGhlIHBhcmFtZXRlcnMgc3VwcGxpZWQgdG8g DQo+QXJnb24yIGFuZCBkZXRlcm1pbmluZyBpdHMgcGVyZm9ybWFuY2UuIFNwZWVkIG9uIGEgdHlw aWNhbCBzZXJ2ZXIgaXMgDQo+bGluZWFyIGluIHRoZSBNVCBwcm9kdWN0Lg0KPg0KPlRoZSBBcmdv bjIgZmFtaWx5IGhhcyB0aHJlZSB2YXJpYW50czogSSwgRCwgYW5kICBJRCwgd2hpY2ggZGlmZmVy IGluIA0KPnRoZSB3YXkgb2YgcmV1c2luZyBtZW1vcnkgdGhhdCBoYXMgYmVlbiBmaWxsZWQuIFRo ZSBJIHZhcmlhbnQgbWFrZXMgDQo+cXVlcmllcyB3aXRoIHByZWRpY3RhYmxlIGFkZHJlc3Nlcywg d2hlcmVhcyBEIGRldGVybWluZXMgdGhlIGFkZHJlc3NlcyANCj5vbiB0aGUgZmx5IGRlcGVuZGlu ZyBvbiB0aGUgY3VycmVudCBzdGF0ZSAoYW5kIHRodXMgdGhlIHBhc3N3b3JkKS4gVGhlIA0KPklE IHZhcmlhbnQgZm9sbG93cyBJIGZvciB0aGUgIGZpcnN0IGhhbGYgb2YgdGhlIG1lbW9yeSB1c2Vk IGFuZCBEIGZvciANCj50aGUgcmVzdCBhbmQgd2hpbGUgb3ZlcndyaXRpbmcuDQo+U2lkZS1jaGFu bmVsc1RoZSBzaWRlLWNoYW5uZWwgYXR0YWNrcywgd2hpY2ggYXJlIG9mIHN0aWxsIHJpc2luZyAg DQo+Y29uY2VybiBpbiB0aGUgc2VjdXJpdHkgY29tbXVuaXR5LCBhcmUgYXBwbGljYWJsZSB0byB0 aGUgRCB2YXJpYW50IGFzIA0KPnRoZSBtZW1vcnkgYWRkcmVzc2VzIGFuZCB0aHVzIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBwYXNzd29yZCBvciBvdGhlciANCj5zZWNyZXQgaW5wdXRzIGNhbiBiZSBk ZXRlcm1pbmVkIGZyb20gdGhlIHRpbWluZyBsZWFrcy4gVGhlIEkgdmFyaWFudCBpcyANCj5jb21w bGV0ZWx5IGludnVsbmVyYWJsZSB0byB0aGlzIGF0dGFjaywgYW5kICB0aGUgSUQgdmFyaWFudCBw cm92aWRlcyANCj5vbmx5IGEgY29uc3RhbnQgZmFjdG9yIGltcHJvdmVtZW50IGZvciB0aGUgYXR0 YWNrZXIuDQo+SGFyZHdhcmUgYW5kIHRyYWRlb2Zmc1RoZSBNIGFuZCBUIHBhcmFtZXRlcnMgZGV0 ZXJtaW5lIHRoZSBjb3N0IG9mIA0KPmJydXRlZm9yY2luZyAgcGFzc3dvcmRzIG9uIGN1c3RvbSBo YXJkd2FyZSwgd2hpY2ggaXMgcHJvcG9ydGlvbmFsIHRvIA0KPk0yVCAgaWYgd2UgZm9sbG93IHRo ZSB0cmFkaXRpb25hbCB0aW1lLWFyZWEgcHJvZHVjdCBtZXRyaWMuIFRoZSANCj50aW1lLW1lbW9y eSB0cmFkZW9mZiBhbmFseXNpcyBbMl0gc2hvd3MgdGhhdCB0aGUgYnJ1dGVmb3JjZSBjb3N0IGZv ciANCj50aGUgSSB2YXJpYW50IGNhbiBiZSBjaGFuZ2VkIHRvIE0yVC9RKE0sVCkgIGZvciBzb21l IHF1YWxpdHkgZnVuY3Rpb24gDQo+US4gRm9yIGluc3RhbmNlLCBRKDIzMCwxKT01LCAgUSgyMzAs NCk9Mi41Lg0KPg0KPlRoZSBEIHZhcmlhbnQgaXMgaW52dWxuZXJhYmxlIHRvIHRoZSBhcHByb2Fj aCBbMl0sICBhbmQgdGhlIHNhdmluZ3MgDQo+ZmFjdG9yIGluIHRoZSBJRCB2YXJpYW50IGlzIHVw cGVyIGJvdW5kZWQgYnkgZmFjdG9yIDIgZm9yIGFsbCANCj5wYXJhbWV0ZXJzLg0KPkRlZmVuZGVy IHRyYWRlb2ZmIGFuZCB1bHRpbWF0ZQ0KPiByZWNvbW1lbmRhdGlvbnNJbiBwdWJsaWMgYW5kIHBy aXZhdGUgY29udmVyc2F0aW9ucyB3aXRoIHNlY3VyaXR5ICANCj5hcmNoaXRlY3RzIGluIHRoZSBp bmR1c3RyeSB3ZSBsZWFybmVkIHRoYXQgdGhlIGJvdHRsZW5lY2sgaW4gYSBzeXN0ZW0gDQo+ZW1w bG95aW5nIHRoZSBwYXNzd29yZC1oYXNoaW5nIGZ1bmN0aW9uIGlzIHRoZSBmdW5jdGlvbiBsYXRl bmN5IHJhdGhlciANCj50aGFuIG1lbW9yeSBjb3N0cy4gV2UgdGhlbiBhc3N1bWUgdGhhdCBhIHJh dGlvbmFsIGRlZmVuZGVyIHdvdWxkIGxpa2UgDQo+dG8gbWF4aW1pemUgdGhlIGJydXRlZm9yY2Ug Y29zdHMgZm9yIHRoZSBhdHRhY2tlciAgZXF1aXBwZWQgd2l0aCBhIGxpc3QgDQo+b2YgaGFzaGVz LCBzYWx0cywgYW5kIHRpbWluZyBpbmZvcm1hdGlvbiwgZm9yIGZpeGVkIGNvbXB1dGluZyB0aW1l IG9uIA0KPnRoZSAgZGVmZW5kZXLigJlzIG1hY2hpbmUuICBJbiB0aGlzIGFzc3VtcHRpb24gdGhl IGRlZmVuZGVyIGtlZXBzIHRoZSBNVCANCj5wcm9kdWN0IGNvbnN0YW50IGFuZCBtYXhpbWl6ZXMg dGhlIGxvc3NlcyBNL1EoTSxUKS4NCj4gVGhlIGF1dGhvcnMgb2YgWzJdIHByb3ZpZGVzIHVzIHdp dGggYXR0YWNrIGNvc3QgZXN0aW1hdGVzIGZvciBjb25zdGFudCANCj5NVCA9IDIyOCwyMzAsMjMy ICAobWVhc3VyZWQgaW4gaXRlcmF0aW9uLWJ5dGVzKQ0KPg0KPldlIHVsdGltYXRlbHkgcmVjb21t ZW5kIHRoZSBJRCB2YXJpYW50IHdpdGggVD0xIGFuZCBtYXhpbXVtIE0gYXMgYSANCj5kZWZhdWx0 IHNldHRpbmcgZm9yIGFsbCBlbnZpcm9ubWVudHMsIHdoaWNoIGlzIHNlY3VyZSAgYWdhaW5zdCAN Cj5zaWRlLWNoYW5uZWwgYXR0YWNrcyBhbmQgcHJvaGliaXQgYWR2ZXJzYXJpYWwgYWR2YW50YWdl IG9uIGRlZGljYXRlZCANCj5icnV0ZWZvcmNlIGhhcmR3YXJlLg0KPg0KPg0KPlJlZmVyZW5jZXNb MV0NCj7igJxFZmZpY2llbnRseSBDb21wdXRpbmcgRGF0YS1JbmRlcGVuZGVudCAgTWVtb3J5LUhh cmQgRnVuY3Rpb25z4oCdIA0KPjxodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMTYvMTE1LnBkZj4N Cj5bMl0NCj7igJxUb3dhcmRzIFByYWN0aWNhbCBBdHRhY2tzIG9uDQo+IEFyZ29uMmkgYW5kIEJh bGxvb24gSGFzaGluZ+KAnSAgPGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNi83NTkucGRmPg0K Pg0KPg0KPg0KPg0KPg0KPk9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDEyOjQ2IFBNLCA8aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCj4NCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQo+ZGlyZWN0b3Jp ZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ3J5cHRvIEZvcnVtIG9mIHRo ZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIG1lbW9yeS1oYXJkIEFy Z29uMiBwYXNzd29yZCBoYXNoIGFuZA0KPnByb29mLW9mLXdvcmsgZnVuY3Rpb24NCj4gICAgICAg IEF1dGhvcnMgICAgICAgICA6IEFsZXggQmlyeXVrb3YNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIERhbmllbCBEaW51DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBEbWl0cnkgS2hvdnJh dG92aWNoDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1vbiBKb3NlZnNzb24NCj4gICAg ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlydGYtY2ZyZy1hcmdvbjItMDIudHh0DQo+ICAg ICAgICBQYWdlcyAgICAgICAgICAgOiAyNg0KPiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAx Ny0wMy0yNw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBB cmdvbjIgbWVtb3J5LWhhcmQgZnVuY3Rpb24gZm9yIHBhc3N3b3JkDQo+ICAgaGFzaGluZyBhbmQg cHJvb2Ytb2Ytd29yayBhcHBsaWNhdGlvbnMuICBXZSBwcm92aWRlIGFuIGltcGxlbWVudGVyDQo+ ICAgb3JpZW50ZWQgZGVzY3JpcHRpb24gdG9nZXRoZXIgd2l0aCBzYW1wbGUgY29kZSBhbmQgdGVz dCB2ZWN0b3JzLiAgVGhlDQo+ICAgcHVycG9zZSBpcyB0byBzaW1wbGlmeSBhZG9wdGlvbiBvZiBB cmdvbjIgZm9yIEludGVybmV0IHByb3RvY29scy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pcnRmLWNmcmctYXJnb24yLw0KPg0KPlRoZXJlIGFyZSBhbHNvIGh0 bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi0wMg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi0wMg0KPg0KPkEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaXJ0Zi1jZnJnLWFyZ29uMi0wMg0KPg0KPg0KPlBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IA0KPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCANCj50b29scy5pZXRmLm9yZyA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4N Cj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNmcmcgbWFpbGluZyBsaXN0DQo+ Q2ZyZ0BpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Zy Zw0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPi0tDQo+QmVzdCByZWdhcmRzLA0KPkRtaXRyeSBLaG92 cmF0b3ZpY2gNCj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNmcmcgbWFpbGluZyBsaXN0DQpDZnJnQGlydGYub3JnDQpodHRwczovL3d3dy5p cnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg== From nobody Thu Jun 15 10:27:22 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7671293D8 for ; Thu, 15 Jun 2017 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 95a0c7T_KwzL for ; Thu, 15 Jun 2017 10:27:19 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 DE72D129329 for ; Thu, 15 Jun 2017 10:27:18 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id w1so29155282qtg.2 for ; Thu, 15 Jun 2017 10:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qcUfsi1HqcKaJbRoZSqkAiv72twLkga6Ld1d1/lLGXc=; b=mdkeU56CAeiuJRwQtGIrV9PT24bv95kb5i3Ohs51bcsKxXbSTri7dxeuHJG+w8KHh7 IgkNNZ3ebL+gwoVYEAi8KeQaNIkaz0AhCUq4itM39d232dH94Lnoxr6rvBtI+KqKGJ1J 5r+bXn3rI8Qata6LmdvVTjPDdSpWCkMfOEOinbeRQM1qxTSOecwhAEzATQ7CNX883Uvq UYLnUbvVLDDflbpV/R1vyFbzF9VxVIaaTRN8W6wE0x/f7mGcvOZTuzZgaqjS5JygCoo/ Vg5EwbqcZ4lwV75dMA4/7+d+Ed3KXoMFossrBTzNCraU7mkCg2fX8MheAfl47ZcmEI2A ux5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qcUfsi1HqcKaJbRoZSqkAiv72twLkga6Ld1d1/lLGXc=; b=huw6piEne1RmnFjnnSTmHMtPotwHfb7VZOz4UyWYu3Zn1SVKJ0tdvO5FhMY1lacXzc zjqwiR6NNZh7VvXkEzjZRMtjlZ7dqEtz2dCtRIL0IkCdIx249jIMJddZbRuFf8K443/J zcQwJTz2WufI7eUYEtcpJyUw7UQJqampvy+zP2AElc/4zw++qWdvGe1niWIxTGPnOONG zoiSiSuP31/qGJuxz4B0ACpv8jHND21VcHOwObjr+EFKua/DrEfqNTv3auMHJ9WOzRsl wy7E6t7o7MliZV4OXKuyacA6+a4jZno/nae8yxSPqzVaKi4CkFFRJAiR1gm6pT/6JOEP Ip7A== X-Gm-Message-State: AKS2vOxi/ukHMr+JkAWvzfehRu7yfLPk+3EH7NI4obE8i8JRpYXhmWXp pKk+v1MAYjY8M+fm3nqTPKoVlPCqIw== X-Received: by 10.55.76.140 with SMTP id z134mr7783288qka.35.1497547637685; Thu, 15 Jun 2017 10:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.82.243 with HTTP; Thu, 15 Jun 2017 10:27:17 -0700 (PDT) In-Reply-To: References: From: David Wong Date: Thu, 15 Jun 2017 18:27:17 +0100 Message-ID: To: =?UTF-8?Q?Beno=C3=AEt_Viguier?= Cc: cfrg@irtf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] RFC Draft for KangarooTwelve XOF draft-viguier-kangarootwelve-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:27:22 -0000 Hey Benoit, I'm happy to see that the first draft is done! The whole thing looks pretty good to me. I have some minor feedback as well as a major one right below: I think the specification mixes implementation tricks and the real specification keccak. If you're planning on giving (reversed) values in hexadecimal for the dsByte and the padding, I think it is worth specifying the sponge function differently with inversed operations in the permutation and a transformation from input to lanes, relevant to the tricks that implementations use. This would also mean getting rid of any LSB 0 bit-numbering mention in the convention section. I think this RFC would be a really good opportunity to clear things up and simplify the implementers' job. I would start by defining F as F(input, domain_separation, output_length). Then the following algorithm for the function F: // Padding 1. append the domain_separation byte to the input 2. append zeros to the input until it becomes a multiple of the rate (168 b= ytes) 3. XOR the last byte of the padded input with 0x80 // XOR'ing 4. split the input in n blocks of 168 bytes (rate size): block_1, ..., bloc= k_n 5. For each block, apply the Absorb algorithm Absorb(block_1, state); ...; Absorb(block_n, state) (note that each Absorb call is taking an updated state from the previous Absorb call) // Output'ing 6. concatenate the outputs of Squeeze algorithm until the amount of bytes collected is greater or equal to output_length output =3D Squeeze(state) || ... || Squeeze(state) (note that each Squeeze call is taking an updated state from the previous Squeeze call) 7. truncate the output to the size of output_length and return the result // Absorb algorithm Absorb(input, state) takes an input of 168 bytes, the state of the sponge and updates the state. 1. Split the input in 21 8-byte blocks: input_1, ..., input_21; such that input_i =3D {b_i_0, b_i_1, b_i_2, b_i_3, b_i_4, b_i_5, b_i_6, b_i_7} 2. For each input_i, reverse the order of the bytes, such that reversed_input_i =3D {b_i_7, b_i_6, b_i_5, b_i_4, b_i_3, b_i_2, b_i_1, b= _i_0} 3. For the first 21 "public" lanes of the sponge seen as Lane_i =3D {L_i_0, L_i_1, L_i_2, L_i_3, L_i_4, L_i_5, L_i_6, L_i_7}, XOR each reversed_input_i against each Lane_i, such that Lane_i =3D {L_i_0 + b_i_7, L_i_1 + b_i_6, L_i_2 + b_i_5, L_i_3 + b_i_4, L_i_4 + b_i_3, L_i_5 + b_i_2, L_i_6 + b_i_1, L_i_7 + b_i_0} 4. Update the sponge state by calling the permutation with only the last 12 rounds (see Appendix A) // Squeeze algorithm output =3D Squeeze(state) takes the state of the sponge and updates the state, while returning a 168 bytes output 1. Copy out the 21 "public" lanes of the sponge state Lane_1, ..., Lane_21 seen as Lane_i =3D {L_i_0, L_i_1, L_i_2, L_i_3, L_i_4, L_i_5, L_i_6, L_i_7} 2. Reverse the bytes of each copied lane: Reversed_Lane_i =3D {L_i_7, L_i_6, L_i_5, L_i_4, L_i_3, L_i_2, L_i_1, L_= i_0} 3. Update the sponge state by calling the permutation with only the last 12 rounds (see Appendix A) 4. Return Reversed_Lane_1 || ... || Reversed_Lane_21 Now, in the appendix A.1. of the permutation, I would be careful to define every operation in the reverse direction. For example ROL64() is done by a left shift << instead of a right shift >>. It should also be mentionned that operations have been reversed since the lanes have been reversed. I think this is important because the point of such an RFC is to dumb down the technical details and facilitate the implementation. A lot of shortcuts can be taken here because we do not care about other rate+capacity variants, or non-multiple of bytes. I have some more feedback about details here and there. Feel free to ignore or acknowledge as you deem relevant. =E2=86=92 The abstract It could contain more information on the use-case rather than on what type of primitive it is. I'm saying that because I often run into obscure RFC and have a hard time understanding from the abstract what they are for. Here is how I would think is important: * K12 =E2=86=92 KangarooTwelve is an eXtendable Output Function = (XOF) * trust =E2=86=92 The design is based on SHA-3 and done by the sam= e inventors * XOF =E2=86=92 It provides an arbitrary output length that can = be truncated to any desired size * fast =E2=86=92 Its performs better than SHA-3, SHA-2 and SHA-1 * big inputs =E2=86=92 It takes advantage of tree hashing to efficientl= y parallelize hashing of big files * small inputs =E2=86=92 Due to Sakura Coding and the padding, no penalty exists for small inputs This could be written as: This document defines the KangarooTwelve eXtendable Output Function (XOF)= , a hash function based on SHA-3 and designed by the same inventors that provides outputs of arbitrary lengths. It performs better than SHA-3, SHA= -2 and SHA-1; taking advantage of parallelism to speed up hashing of big fil= es while still being efficient by avoiding penalties for small inputs. =E2=86=92 The introduction - It could use the same spiel about the no-penalty for small inputs. - You mention Keccak without defining what it is (you mention Keccak-p before though). =E2=86=92 Section 1.1. Conventions - Do you really need the MUST, SHOULD, etc... keywords? I'm not sure any of these makes too much sense in K12's context. - "LSB 0 bit convention" is also called "LSB 0 bit-numbering", which might more formal and fit to the context? > |s| denotes the length of a byte string "s". For example, |"FF FF"| =3D= 2. I think this should emphasize the unit: "denotes the length of a value in 'bytes'" =E2=86=92 Section 2.1. Inner function: F > Keccak-p[1600,n_r=3D12] I think it should be noted that these are the "last" 12 rounds of the permutation with 24 rounds. Also I'd prefer a function F defined as F(input, domain_separation, output_length) to simplify the other parts of the RFC. > The input string S SHOULD be represented as a pair (Sbytes, dS), Not sure why the "SHOULD" or why the mention of a "pair". What's a pair in C :) ? > multi-rate padding rule pad10*1 - You mention the multi-rate padding without defining it. - Do we really need these explanations on the computation of `dS`? Just giving the values should be enough imo =E2=86=92 Section 2.2. Tree hashing over F - Could this section simply be renamed "Hashing"? - I would also enumerate the steps and simplify a few things. For example= : KangarooTwelve( input, custom_string, output_length ) takes any input to be hashed, a (optionally empty) customization string and a desired output length. It then execute the following steps: 1. Concatenate input, custom_string and right_encode(|custom_string|). S =3D input || custom_string || right_encode(|custom_string|) 2. If the byte length of S is less than 8192 bytes, then run the sponge function on S with dsByte =3D 0x07 and ignore the rest of these steps. Otherwise skip this step and go directly to step 3. F(S, dsByte=3D0x07, output_length) 3. Split the concatenated value into n chunks of 8192 bytes, where the last one can be shorter or equal to 8192 bytes). For example with 5 chunks: S =3D S_0 || .. || S_4 with |S_0| =3D |S_1| =3D |S_2| =3D |S_3| =3D 8192 bytes and |S_4| <=3D 8192 bytes 4. Compute CV_1 to CV_4, optionally using the parallelism supported by your architecture. (For example this is achievable on Intel architecture by using SIMD instructions.) Node_i =3D S_i || `110` CV_i =3D F(Node_i, dsByte=3D0x0B, output_length=3D32) 5. To compute the final input, start by contatenating the first chunk with the hexadecimal string "03 00 00 00 00 00 00 00" final_input =3D S_0 || "03 00 00 00 00 00 00 00" 6. Append the concatenation of all the the CV_i to the final input. final_input =3D final_input || CV_1 || CV_2 || CV_3 || CV_4 7. Append the encoding of the number of chunks minus one (4 in our example) to the final input. final_input =3D final_input || right_encoding(n-1) 8. Append the hexadecimal string "FF FF" to the final input. final_input =3D final_input || "FF FF" 9. Run the sponge function on the final input with dsByte =3D 0x06 F(final_input, dsByte=3D0x06, output_length) > For |S| > 8192 bytes I think diagrams should be in the appendix (or at least in a different section). Also a diagram for `|S| <=3D 8192 bytes` would be nice as well :) +--------------+ | message | +--------------+ || +--------------+ | custom_string| +--------------+ || +-----------------------------------+ F(dsByte=3D0x07= ) | right_encode(|custom_string|) |-----------------> output +-----------------------------------+ =E2=86=92 2.3. right_encode( x ) > x =3D x / 256 I don't think you define the division here. I would define it in this section as well as in the convention section (1.1): a / b outputs the quotient of the operation: a divided by b. For example 10 =3D 3 * 9 + 1, so 3 would be outputed by the operation 10 / 9. Furthermore, since 240 =3D 0 * 256 + 240, 0 would be the output of 240 / 256. =E2=86=92 Section 3. Test Vectors These should probably be in an Appendix. =E2=86=92 Appendix A.3. You could also think of including (or replacing yours with) the python function there: https://github.com/gvanas/KeccakCodePackage/blob/master/Standalone/Kangar= ooTwelve-reference/K12.py#L98:L113 But I think it should be noted that this is not taking advantage of parallelism. I probably have more, but this is starting to get huge so... I'll wait until you tell me if I'm being unreasonable. Thanks again for your work Benoit! Regards, David From nobody Thu Jun 15 17:56:17 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839471270FC; Thu, 15 Jun 2017 17:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 OZWIHLwQ6WpR; Thu, 15 Jun 2017 17:56:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C501A126E3A; Thu, 15 Jun 2017 17:56:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E8F6BEB3; Fri, 16 Jun 2017 01:56:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe9PZpy9uNMT; Fri, 16 Jun 2017 01:56:05 +0100 (IST) Received: from [172.28.172.2] (unknown [185.51.73.39]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F3EC1BEAA; Fri, 16 Jun 2017 01:56:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497574565; bh=FxsusIsoFCI4VPSp2suiYw3WMyLzS/6eH+hnBI5pPvk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eXyfdw46UoVyGuS1/qE2kZkidUvTmZZHZu0R2+TCnRcxz6FSPZfM7zNsXXv9X/IOc Mnk/RvSpvrwxwNAmegzWeEfU45szvfaiUgRNcEiKvdLtwLQpS3KeYi1Bx11HUFr0CW HmKahsqluQALFjEOv4VdpnOXo5idNVhy+Bqj8HPQ= To: "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> Date: Fri, 16 Jun 2017 01:56:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2HF9T7PvPKFdPS2lNjO5SiD5C3vG6wpXt" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 00:56:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2HF9T7PvPKFdPS2lNjO5SiD5C3vG6wpXt Content-Type: multipart/mixed; boundary="dfoeq9KthArdbBWD7PbUv5EPlaQLaF44d"; protected-headers="v1" From: Stephen Farrell To: "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Message-ID: <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> Subject: Re: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> In-Reply-To: --dfoeq9KthArdbBWD7PbUv5EPlaQLaF44d Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi all, Apologies for being slow in reviewing this. My comments are below. I have two things that I think really ought be checked before this is ready for publication. When that's done, then I think this will be ready to publish. I also have two further comments/suggestions that I think would be significant and relatively easy improvements to the document. Those don't affect the IRSG review process though, considering the RG were presumably happy enough as-is. (I'd still argue for those changes though:-) And I've a bunch of mostly editorial comments that the authors can choose to take on board or not as they see fit. Cheers, S. possible errors: ---------------- - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be missing parenthesis around the "(w-1)" to me. Without those brackets I could interpret that test to always result in false. - 4.1.9: should the call to setIdx in alg 12 be after treeSig? as-is you seem to have incremented the index too soon so that when alg 11 does getIdx it'd presumably get the incremented index and cause verification failure. I think the same is true of alg 16 as well, in section 4.2.4. significant comments, but likely fixable: ----------------------------------------- - section 5: there are waaaay too many options defined here. As-is, this will damage potential deployment of xmss. I would strongly suggest deleting all of the options except the minimum, that being one (and only one) set of parameters for XMSS and one for XMSS^MT. If others are needed later, those can be defined later. (Note that the damage done here includes the hours of developer time that would be wasted debating which of these choices to implement/use. Consider the case of pre-hash variants of eddsa for an ongoing example.) - section 5 (or an appendix) should contain some test vectors (including intermediate values). Without those, implementers have a much harder time of getting their code right. nits, near-nits and other ignorable things: ------------------------------------------- - abstract: I'd suggest s/can withstand attacks/ can withstand so-far known attacks/ - 1.1: You say if used >1 time "no cryptographic security guarantees remain." It might be clearer to give some examples of consequences, e.g. that the attacker can forge new signatures or whatever. - 1.1: I think you might mention that XMSS and other OTS ideas require some new crypto APIs. I'm not aware if anyone has developed proposals for such, but would be interested if someone has. - 2.3, 2nd last para: you might want to say what happens with e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but someone might think it's 0x3c0 or even 0xc3. - 2.5: having the "type word" as octet 15 of a 32 byte address seems odd. Is there a reason why? (Just wondering.) - 2.6: It seems odd to given an example where the input and output of base_w() are the same. A different example may be more useful. (More examples generally would be great.) - 3.1.3: maybe note that "/" means nothing? Which I assume it does? Better might be to just say that. - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing units - 3.1.5: "the variable" - which one? - 3.1.5: "For the parameter sets given in Section 5 a 32-bit unsigned integer is sufficient." Sufficient for what? - 3.1.5: The ascii art at the end of p16 doesn't help much. - 3.1.7: The "MUST match" statement doesn't seem enforceable nor testable so I'm not sure it's a good idea to include. OTOH, I do get the idea of using 2119 terms for emphasis. - 3.1.7: I think it might be useful to point out any specific problems associated with using a low entropy human memorable secret (password) for the value S. No matter what you say, people will do that, so better if you can say you told them specifically about downsides of doing that. - 4.1.12: I'm not sure if the MAY there is correct or not. If it means "you MAY use a different algorithm to get the same output as alg 12" then that'd be fine. If something else is meant I'm not sure what you're saying, and it'd probably be better to not even mention it. - section 5 should also spell out the signature and public key sizes in bytes and ideally, if you keep multiple options, (but please don't:-) describe relative or measured timings. --dfoeq9KthArdbBWD7PbUv5EPlaQLaF44d-- --2HF9T7PvPKFdPS2lNjO5SiD5C3vG6wpXt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZQyyhAAoJEC88hzaAX42iOGIIAJgMKWIRN7RGNlC0kNfvl7zh U5v/ewQyA1avNWjXe4U0GNESZS/zV2GNLx7DhjVPZiXa7SBKQLdT2uy68gMXsXI9 AKtWN1Jb/nKhMiEnzVWh2o80vwrDV2ReZGumeP2+rf4qObLh/Qf8Y3FRacNCy45g +Peq3icykWY2pC2If09Pdx4gFr6lQzB/hgTTxYXqPGj9Eu8Kml8CNuOiv9eoP9+1 uO1ak8A2Ek17MD+ucE2nPzpzkUBJLhYV4euH8mtep6/SFpKhCos63m48SRlIvdel NSXqfT4RX+ti0DPEIP9VKLjpg/Oy3JstwYSe0IV3XUpSl9hN07oP4O4IALixadk= =cOho -----END PGP SIGNATURE----- --2HF9T7PvPKFdPS2lNjO5SiD5C3vG6wpXt-- From nobody Thu Jun 15 21:59:34 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1F01277BB for ; Thu, 15 Jun 2017 21:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDn7f7c4E-6p for ; Thu, 15 Jun 2017 21:59:29 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id D78981200F3 for ; Thu, 15 Jun 2017 21:59:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-27-55-143-82.revip3.asianet.co.th; To: Francisco Rodriguez- Henriquez , "cfrg@irtf.org" References: Cc: =?UTF-8?Q?Julio_C=c3=a9sar_Lopez?= , Thomaz Oliveira , huseyin.hisil@yasar.edu.tr From: Peter Dettman Message-ID: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> Date: Fri, 16 Jun 2017 11:58:54 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:59:33 -0000 Hi Francisco, I've updated my (java) implementations of X25519 and X448 in line with your revised paper. My rough benchmark results for a complete ECDH are -17.7% and -19.5% time required for X25519 and X448 respectively. These are perhaps slightly more modest than the paper's estimates. Your paper already anticipates that (uncounted) field add/sub are significant in practice. Part of the difference however is that my implementation of Algorithm 3 handles the final 'q' bits using simple doublings, and removes redundant cswaps - just as Algorithm 5 does. Of course Alg. 3 is just as presented in RFC 7748, but it might be a fairer comparison to first apply to Alg. 3 those of your optimizations that are applicable. Also, my (32-bit) X448 implementation (Alg. 5) required a carry propagation for 'A' (line 10), due to tight bounds on limbs when squaring D, E. I did the same for (32-bit) X25519 although I haven't yet proved it necessary. An idea: for fixed-base X25519, why not precompute one doubling? i.e. just calculate (k/2) * 2P, needing only 2 final doublings (you even already have S of order 4). I am not sure whether this extends to precomputing (q-1) doublings. Another thought that occurred to me is that someone might get the idea to use your fixed-base ladder with some other point. Couldn't this go awry if that point were already "P + S" or similar? If so, a caution somewhere in the paper on preconditions for the fixed point might be advised. Regards, Pete Dettman On 12/05/2017 7:14 AM, Francisco Rodriguez- Henriquez wrote: > Dear CFRG community, > > We would like to draw your attention to an improved version of our IACR > pre-print 2017/264 now entitled: > > "How to (pre-)compute a ladder" > > In this revised version, we present an improved differential addition > formula that uses pre-computation to match the computational cost of the > classical Montgomery differential addition. > > Accordingly, our estimates suggest that a full implementation of our > pre-computable ladder proposal should outperform state-of-the-art > software implementations of the X25519 and X448 functions by a 40% > speedup when working in the fixed-point scenario. > > We would be delighted to receive feedback (including sightings of typos) > from the CFRG community. > > With best regards, > > Thomaz Oliveira, Julio López, Hüseyin Hisil and Francisco > Rodríguez-Henríquez > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Sat Jun 17 11:25:18 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771F8129B59 for ; Sat, 17 Jun 2017 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 PCt10bldGsbJ for ; Sat, 17 Jun 2017 11:25:14 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50071.outbound.protection.outlook.com [40.107.5.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B23129B55 for ; Sat, 17 Jun 2017 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MDlIdSoJjV7HAwbsFOxcIkgLYH1t9EVSH80PZsHNO/c=; b=AurHXybaHr8akBOim50vinKrnTvqo+/ePFp/UyIzCxKo1rN0PTdEW60NkKB9Kn0sLLAT4FKYRDkJJ3jy0Jn2nNIXcnX32YX0A/L57Ge7CvzBLLdvHW7tpMpDl5twhQ60Ci7lcD20f7N/cU3aS+qS4ApmYgVrvR2d/ejDA8hCmrE= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Sat, 17 Jun 2017 18:25:11 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::9dfc:6390:892b:6c59%14]) with mapi id 15.01.1157.022; Sat, 17 Jun 2017 18:25:10 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: [irsg] IETF 99 Preliminary Agenda Thread-Index: AQHS5vVPXa0xkvcxbUiULGn2QZRjbKIpcN4A Date: Sat, 17 Jun 2017 18:25:10 +0000 Message-ID: References: <149765443414.24066.16271031992661424263.idtracker@ietfa.amsl.com> In-Reply-To: <149765443414.24066.16271031992661424263.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.62.179] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:Q0bu9JWlIUCVRhfCCYctJrIRH/DKIT49hEEAYu4MNMAhuv4R6BsXOFmCNw40FyrjfZKYy4srRwmVs9v91g4lNy+q6G/DMIzhXefBTp4GV1OIhDr5P5UwPVk7gtEr6GcH/DjCHsAuzY8Iy4i6H8L+1A0Q5T4IDibJWEQIRHkJh8tlkHPQYvXH0LN+gdQ7OWcnPyzWthwWkNHcJ8opxJSOsO6C6CCK/RH2QVCgqJ7iNV9/UU610kWUOUOfyOl5K33/ZM1+IFso9clNE610/huYc9MQY5d5B8h6qyO3xwYrbGMbAV5bsA+rxLLHELsyolarhZSyqc7C7XIgLRLcwMaxkTGw7H5mdt//aXmspRCLm9ZRlQ7m6R7GyprQh+l87agaWc6nEbiE6lC5M2Wvy1PwkCuR5pwnYYDA/3LhiCC1tx75KBKmjcM1EDA/DRmFTJ0v+7BZmZbxHWj9rRLWQMVK9kKd2kcVhrT95D8z+7CqVJlwBR0Rvk2WoVefavn+7WHIM2QztgAzRmx2gEq2iNhQ3qxyzLGjLPqb+AquZuh+yc/tBpujHhEqAY+gsC/wnVdNiNoOI3QIFQ3iExBfWQBeSgRS5tZtqpoW+kNBoZ1/w5MFvKaLEuS3MKyNYtNx/OrBQnxqQG6VaIjznPlZ5Ipb3Lv4pfYk+Me2owS4BpdfHSj+8uAYxjR7cEV2+ioAiV+WFK0e4ZjlnPZLLbPW7UMMZpr6XvXkMTmFw50ISJKFn4JVs2rOR+KV7MjWgqfzV/++3xZC/3MKKIEl90uBBQ4Xbtj0p72PKFya+0LdIkPnI8k= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(3660700001)(99286003)(2473003)(189998001)(3280700002)(38730400002)(2906002)(6436002)(2501003)(110136004)(6506006)(5640700003)(5250100002)(2900100001)(53546009)(6306002)(25786009)(6486002)(86362001)(83506001)(6512007)(53936002)(14454004)(76176999)(72206003)(50986999)(54356999)(36756003)(478600001)(66066001)(305945005)(81166006)(6116002)(102836003)(74482002)(3846002)(8676002)(7736002)(4001350100001)(5660300001)(2351001)(229853002)(8936002)(1730700003)(6916009)(2950100002)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-ms-office365-filtering-correlation-id: 84b82ea5-a1d4-46bd-119c-08d4b5ae305c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 034119E4F6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2017 18:25:10.5422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: [Cfrg] FW: [irsg] IETF 99 Preliminary Agenda X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 18:25:17 -0000 SGkNCg0KVGhlIHByZWxpbWluYXJ5IGFnZW5kYSBmb3IgdGhlIElFVEYgbWVldGluZyBpbiBQcmFn dWUgaGFzIGJlZW4gYW5ub3VuY2VkLg0KDQpDRlJHIGlzIHNjaGVkdWxlZCB0byB0YWtlIHBsYWNl IDE1NTAtMTc1MCAoQWZ0ZXJub29uIFNlc3Npb24gSUkpIG9uDQpUdWVzZGF5IDE4dGggSnVseS4N Cg0KRnVsbCBzY2hlZHVsZSBhdCBsaW5rcyBiZWxvdy4NCg0KQ2hlZXJzDQoNCktlbm55IA0KDQpP biAxNy8wNi8yMDE3IDAwOjA3LCAiaXJzZyBvbiBiZWhhbGYgb2YgSUVURiBBZ2VuZGEiDQo8aXJz Zy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBhZ2VuZGFAaWV0Zi5vcmc+IHdyb3RlOg0K DQo+VGhlIElFVEYgOTkgcHJlbGltaW5hcnkgYWdlbmRhIGhhcyBiZWVuIHBvc3RlZC4gVGhlIGZp bmFsIGFnZW5kYSB3aWxsIGJlDQo+cHVibGlzaGVkIG9uIEZyaWRheSwgSnVuZSAyMywgMjAxNy4N Cj4NCj5JZiB5b3Ugd291bGQgbGlrZSB0byByZXF1ZXN0IGEgY2hhbmdlIHRvIHRoZSBwcmVsaW1p bmFyeSBhZ2VuZGEsIHBsZWFzZQ0KPnNlbmQgYSBtZXNzYWdlIHRvIGFnZW5kYUBpZXRmLm9yZyBh bmQgY29weSBhbGwgcmVsZXZhbnQgQXJlYSBEaXJlY3RvcnMuDQo+DQo+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzk5L2FnZW5kYS5odG1sDQo+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9tZWV0aW5nLzk5L2FnZW5kYS50eHQNCj4NCj5UaGFuayB5b3UhDQo+DQo+SUVU RiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Mon Jun 19 09:39:32 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9CC131603; Mon, 19 Jun 2017 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 bCXUz39XI43T; Mon, 19 Jun 2017 09:39:27 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10083.outbound.protection.outlook.com [40.107.1.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BF71315E7; Mon, 19 Jun 2017 09:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fy3uDn4bRURrMRxrIJ/da459CLfQjdbFW4u5TghmWgg=; b=vputIbhkcTCFf0PGHLHzcjGdKxC9kgG15TBuYr9atLtS03ru/aOVfPPaylW9XdzpVUxlmmcUWXYFrRFinBS8LcJWHUxP3Hx5eLW2gJgpBw3GxInTPVHQF81BOd+yQaI8FOaiFBtuPq7s8NyIcjQmqtV00b9UCy4/pJJderaro/s= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Mon, 19 Jun 2017 16:37:28 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a0cf:ee9d:63a3:d1ab]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a0cf:ee9d:63a3:d1ab%14]) with mapi id 15.01.1178.018; Mon, 19 Jun 2017 16:37:28 +0000 From: "Paterson, Kenny" To: Stephen Farrell , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" CC: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Thread-Topic: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 Thread-Index: AQHSplCaq+TMeSvbmEmNdyOfQ3yIYKHhJb6AgAABdICAQ2hIgIACmomAgAXOyYA= Date: Mon, 19 Jun 2017 16:37:28 +0000 Message-ID: References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> In-Reply-To: <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:aP6I/yhSIpIilYjXQTsJ0hU0H+7NikBgoY4WoKMVKIE0m/dudWJ5e67Tyf8WZXM2gcNwbQPB2fezjXgWu2M6ltbrybAx65bELuwHAJ5ol5BgNR+yTFF+0oChfTk9UzuWo2QzYUyEap4se9Lnk7Ut7ddrTSsXbegIKTwHmwUedxHgmff+2d+3DRpXnF8AftEKDna79JEQcvgxhEpNNtg0o8qz/8Ed2zZMEi1xryZ/fXm4xMmmZEtHPMrUoBY+J30c+znurHmcKxB1ThI1AZCa7MF4ZBxA6DGF7VCqFkulnLa/Y5jrr2rL5bHPlUXnwVwldCraJwQy98AGxsrsnAnt56Abkc50PgVnazGMuO5yMKTS79p/FvpeGfrPwEcjxzk2ZWJOT7HYjnXEKSBd4Ckkfh+J+2gjLhMcjdMLPNOryneQ5cQIB0KeHBs280OPpk7gHFQg0d+2raNDD0C0IpW6Juwy9xwdcY0yWWcfmnyisR8uZcRimax8Cwgj33E9f/Cxd0yRdoepdiD4DQNS2BoN6RguScrsIW6HzXtmC1s4DxbMVtqO6N9MOvsqT3n+iIsfzDSSz9r5TjlIfg6USVGNnB0CymgOXXfBBkjjb6Dly7ddLeXwNl1tEcEDXohld4jTA14q364sJVRXRsMMxvGJk0xbm/tBFhMADA/+lAXLnJ55temL3loAZmQgE5RgJwGHFaJukJ/a1KXD+fmj4o6LmjSdhbbUKGse22WkzHMXuj4MdNI8Ix4vRXsJNuL2FNdi+hCCJIQrPBNzJZ0rKMkt4hPS87kXk81U41Pfjwve6BU= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39850400002)(39400400002)(39840400002)(53754006)(24454002)(53936002)(5250100002)(6512007)(99286003)(2201001)(305945005)(93886004)(14454004)(72206003)(2906002)(25786009)(3660700001)(53546009)(478600001)(8676002)(6246003)(54356999)(38730400002)(76176999)(81166006)(50986999)(551544002)(66066001)(4001350100001)(6486002)(83506001)(8936002)(229853002)(74482002)(189998001)(2950100002)(2900100001)(42882006)(36756003)(86362001)(102836003)(3846002)(6116002)(6436002)(7736002)(5660300001)(230783001)(6506006)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: ee8283f4-30e8-4494-4609-08d4b731793d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0343AC1D30 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 16:37:28.0484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:39:30 -0000 QFN0ZXBoZW46IHRoYW5rcyBmb3IgbWFraW5nIHRoaXMgdGhvcm91Z2ggc3R1ZHkgb2YgdGhlIGRy YWZ0Lg0KDQpAZHJhZnQgYXV0aG9yczogY2FuIHlvdSBwbGVhc2UgZ28gdGhyb3VnaCB0aGlzIGZl ZWRiYWNrIGNhcmVmdWxseSBhbmQNCmltcGxlbWVudCB0aGUgbmVjZXNzYXJ5IGNoYW5nZXM/DQoN ClRoZSB0b3VnaGVzdCBwYXJ0IHdpbGwgbGlrZWx5IGJlIHNlbGVjdGluZyBvbmUgc2V0IG9mIHBh cmFtZXRlcnMuIElmDQpTdGVwaGVuIGlzIGFtZW5hYmxlIChidXQgbWF5YmUgaGUgaXMgbm90KSwg SSdkIHN1Z2dlc3QgaGlnaGxpZ2h0aW5nIG9uZQ0Kc2V0IGFtb25nc3QgdGhlIHNldmVyYWwgbGlz dGVkIGFzIGJlaW5nIHlvdXIgInByZWZlcnJlZCIgc2V0IChyYXRoZXIgdGhhbg0KaW5jbHVkaW5n IGp1c3Qgb25lIHNldCBhcyBTdGVwaGVuIHN1Z2dlc3RzKSAtIHRoYXQnZCBiZSBhIGhhbGZ3YXkg aG91c2UNCmJldHdlZW4gd2hhdCB5b3UgY3VycmVudGx5IGhhdmUgYW5kIHdoYXQgU3RlcGhlbiBz dWdnZXN0cy4NCg0KQ2hlZXJzLA0KDQpLZW5ueSANCg0KDQpPbiAxNi8wNi8yMDE3IDAxOjU2LCAi U3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQoNCj4N Cj5IaSBhbGwsDQo+DQo+QXBvbG9naWVzIGZvciBiZWluZyBzbG93IGluIHJldmlld2luZyB0aGlz LiBNeSBjb21tZW50cyBhcmUgYmVsb3cuDQo+SSBoYXZlIHR3byB0aGluZ3MgdGhhdCBJIHRoaW5r IHJlYWxseSBvdWdodCBiZSBjaGVja2VkIGJlZm9yZSB0aGlzDQo+aXMgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLiBXaGVuIHRoYXQncyBkb25lLCB0aGVuIEkgdGhpbmsgdGhpcyB3aWxsDQo+YmUgcmVh ZHkgdG8gcHVibGlzaC4NCj4NCj5JIGFsc28gaGF2ZSB0d28gZnVydGhlciBjb21tZW50cy9zdWdn ZXN0aW9ucyB0aGF0IEkgdGhpbmsgd291bGQNCj5iZSBzaWduaWZpY2FudCBhbmQgcmVsYXRpdmVs eSBlYXN5IGltcHJvdmVtZW50cyB0byB0aGUgZG9jdW1lbnQuDQo+VGhvc2UgZG9uJ3QgYWZmZWN0 IHRoZSBJUlNHIHJldmlldyBwcm9jZXNzIHRob3VnaCwgY29uc2lkZXJpbmcgdGhlDQo+Ukcgd2Vy ZSBwcmVzdW1hYmx5IGhhcHB5IGVub3VnaCBhcy1pcy4gKEknZCBzdGlsbCBhcmd1ZSBmb3IgdGhv c2UNCj5jaGFuZ2VzIHRob3VnaDotKQ0KPg0KPkFuZCBJJ3ZlIGEgYnVuY2ggb2YgbW9zdGx5IGVk aXRvcmlhbCBjb21tZW50cyB0aGF0IHRoZSBhdXRob3JzIGNhbg0KPmNob29zZSB0byB0YWtlIG9u IGJvYXJkIG9yIG5vdCBhcyB0aGV5IHNlZSBmaXQuDQo+DQo+Q2hlZXJzLA0KPlMuDQo+DQo+DQo+ cG9zc2libGUgZXJyb3JzOg0KPi0tLS0tLS0tLS0tLS0tLS0NCj4NCj4tIDMuMS4yOiBBbGdvcml0 aG0gMjogImlmICggKGkgKyBzKSA+IHcgLSAxICkuLi4iIHNlZW1zIHRvIGJlDQo+bWlzc2luZyBw YXJlbnRoZXNpcyBhcm91bmQgdGhlICIody0xKSIgdG8gbWUuICBXaXRob3V0IHRob3NlDQo+YnJh Y2tldHMgSSBjb3VsZCBpbnRlcnByZXQgdGhhdCB0ZXN0IHRvIGFsd2F5cyByZXN1bHQgaW4gZmFs c2UuDQo+DQo+LSA0LjEuOTogc2hvdWxkIHRoZSBjYWxsIHRvIHNldElkeCBpbiBhbGcgMTIgYmUg YWZ0ZXIgdHJlZVNpZz8NCj4gIGFzLWlzIHlvdSBzZWVtIHRvIGhhdmUgaW5jcmVtZW50ZWQgdGhl IGluZGV4IHRvbyBzb29uIHNvDQo+dGhhdCB3aGVuIGFsZyAxMSBkb2VzIGdldElkeCBpdCdkIHBy ZXN1bWFibHkgZ2V0IHRoZQ0KPmluY3JlbWVudGVkIGluZGV4IGFuZCBjYXVzZSB2ZXJpZmljYXRp b24gZmFpbHVyZS4gSSB0aGluaw0KPnRoZSBzYW1lIGlzIHRydWUgb2YgYWxnIDE2IGFzIHdlbGws IGluIHNlY3Rpb24gNC4yLjQuDQo+DQo+c2lnbmlmaWNhbnQgY29tbWVudHMsIGJ1dCBsaWtlbHkg Zml4YWJsZToNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0K Pi0gc2VjdGlvbiA1OiB0aGVyZSBhcmUgd2FhYWF5IHRvbyBtYW55IG9wdGlvbnMgZGVmaW5lZCBo ZXJlLg0KPiAgQXMtaXMsIHRoaXMgd2lsbCBkYW1hZ2UgcG90ZW50aWFsIGRlcGxveW1lbnQgb2Yg eG1zcy4gSQ0KPndvdWxkIHN0cm9uZ2x5IHN1Z2dlc3QgZGVsZXRpbmcgYWxsIG9mIHRoZSBvcHRp b25zIGV4Y2VwdCB0aGUNCj5taW5pbXVtLCB0aGF0IGJlaW5nIG9uZSAoYW5kIG9ubHkgb25lKSBz ZXQgb2YgcGFyYW1ldGVycyBmb3INCj5YTVNTIGFuZCBvbmUgZm9yIFhNU1NeTVQuIElmIG90aGVy cyBhcmUgbmVlZGVkIGxhdGVyLCB0aG9zZQ0KPmNhbiBiZSBkZWZpbmVkIGxhdGVyLiAoTm90ZSB0 aGF0IHRoZSBkYW1hZ2UgZG9uZSBoZXJlIGluY2x1ZGVzDQo+dGhlIGhvdXJzIG9mIGRldmVsb3Bl ciB0aW1lIHRoYXQgd291bGQgYmUgd2FzdGVkIGRlYmF0aW5nDQo+d2hpY2ggb2YgdGhlc2UgY2hv aWNlcyB0byBpbXBsZW1lbnQvdXNlLiBDb25zaWRlciB0aGUgY2FzZSBvZg0KPnByZS1oYXNoIHZh cmlhbnRzIG9mIGVkZHNhIGZvciBhbiBvbmdvaW5nIGV4YW1wbGUuKQ0KPg0KPi0gc2VjdGlvbiA1 IChvciBhbiBhcHBlbmRpeCkgc2hvdWxkIGNvbnRhaW4gc29tZSB0ZXN0IHZlY3RvcnMNCj4gIChp bmNsdWRpbmcgaW50ZXJtZWRpYXRlIHZhbHVlcykuIFdpdGhvdXQgdGhvc2UsIGltcGxlbWVudGVy cw0KPmhhdmUgYSBtdWNoIGhhcmRlciB0aW1lIG9mIGdldHRpbmcgdGhlaXIgY29kZSByaWdodC4N Cj4NCj5uaXRzLCBuZWFyLW5pdHMgYW5kIG90aGVyIGlnbm9yYWJsZSB0aGluZ3M6DQo+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPi0gYWJzdHJhY3Q6IEkn ZCBzdWdnZXN0IHMvY2FuIHdpdGhzdGFuZCBhdHRhY2tzLyBjYW4gd2l0aHN0YW5kDQo+ICBzby1m YXIga25vd24gYXR0YWNrcy8NCj4NCj4tIDEuMTogWW91IHNheSBpZiB1c2VkID4xIHRpbWUgIm5v IGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkNCj4gIGd1YXJhbnRlZXMgcmVtYWluLiIgSXQgbWlnaHQg YmUgY2xlYXJlciB0byBnaXZlIHNvbWUNCj5leGFtcGxlcyBvZiBjb25zZXF1ZW5jZXMsIGUuZy4g dGhhdCB0aGUgYXR0YWNrZXIgY2FuIGZvcmdlIG5ldw0KPnNpZ25hdHVyZXMgb3Igd2hhdGV2ZXIu DQo+DQo+LSAxLjE6IEkgdGhpbmsgeW91IG1pZ2h0IG1lbnRpb24gdGhhdCBYTVNTIGFuZCBvdGhl ciBPVFMgaWRlYXMNCj4gIHJlcXVpcmUgc29tZSBuZXcgY3J5cHRvIEFQSXMuIEknbSBub3QgYXdh cmUgaWYgYW55b25lIGhhcw0KPmRldmVsb3BlZCBwcm9wb3NhbHMgZm9yIHN1Y2gsIGJ1dCB3b3Vs ZCBiZSBpbnRlcmVzdGVkIGlmDQo+c29tZW9uZSBoYXMuDQo+DQo+LSAyLjMsIDJuZCBsYXN0IHBh cmE6IHlvdSBtaWdodCB3YW50IHRvIHNheSB3aGF0IGhhcHBlbnMgd2l0aA0KPiAgZS5nLiAgQjw8 MiB3aGVyZSBCPTB4ZjAuIEkgYXNzdW1lIHRoZSByZXN1bHQgaXMgMHhjMCBidXQNCj5zb21lb25l IG1pZ2h0IHRoaW5rIGl0J3MgMHgzYzAgb3IgZXZlbiAweGMzLg0KPg0KPi0gMi41OiBoYXZpbmcg dGhlICJ0eXBlIHdvcmQiIGFzIG9jdGV0IDE1IG9mIGEgMzIgYnl0ZSBhZGRyZXNzDQo+ICBzZWVt cyBvZGQuIElzIHRoZXJlIGEgcmVhc29uIHdoeT8gKEp1c3Qgd29uZGVyaW5nLikNCj4NCj4tIDIu NjogSXQgc2VlbXMgb2RkIHRvIGdpdmVuIGFuIGV4YW1wbGUgd2hlcmUgdGhlIGlucHV0IGFuZA0K PiAgb3V0cHV0IG9mIGJhc2VfdygpIGFyZSB0aGUgc2FtZS4gQSBkaWZmZXJlbnQgZXhhbXBsZSBt YXkgYmUNCj5tb3JlIHVzZWZ1bC4gKE1vcmUgZXhhbXBsZXMgZ2VuZXJhbGx5IHdvdWxkIGJlIGdy ZWF0LikNCj4NCj4tIDMuMS4zOiBtYXliZSBub3RlIHRoYXQgIi8iIG1lYW5zIG5vdGhpbmc/IFdo aWNoIEkgYXNzdW1lIGl0DQo+ICBkb2VzPyBCZXR0ZXIgbWlnaHQgYmUgdG8ganVzdCBzYXkgdGhh dC4NCj4NCj4tIDMuMS41OiAiYSBtYXhpbXVtIHZhbHVlIG9mIGxlbl8xICogKHcgLSAxKSAqIDJe OCIgaXMgbWlzc2luZw0KPiAgdW5pdHMNCj4NCj4tIDMuMS41OiAidGhlIHZhcmlhYmxlIiAtIHdo aWNoIG9uZT8NCj4NCj4tIDMuMS41OiAiRm9yIHRoZSBwYXJhbWV0ZXIgc2V0cyBnaXZlbiBpbiBT ZWN0aW9uIDUgYSAzMi1iaXQNCj4gIHVuc2lnbmVkIGludGVnZXIgaXMgc3VmZmljaWVudC4iIFN1 ZmZpY2llbnQgZm9yIHdoYXQ/DQo+DQo+LSAzLjEuNTogVGhlIGFzY2lpIGFydCBhdCB0aGUgZW5k IG9mIHAxNiBkb2Vzbid0IGhlbHAgbXVjaC4NCj4NCj4tIDMuMS43OiBUaGUgIk1VU1QgbWF0Y2gi IHN0YXRlbWVudCBkb2Vzbid0IHNlZW0gZW5mb3JjZWFibGUNCj4gIG5vciB0ZXN0YWJsZSBzbyBJ J20gbm90IHN1cmUgaXQncyBhIGdvb2QgaWRlYSB0byBpbmNsdWRlLg0KPk9UT0gsIEkgZG8gZ2V0 IHRoZSBpZGVhIG9mIHVzaW5nIDIxMTkgdGVybXMgZm9yIGVtcGhhc2lzLg0KPg0KPi0gMy4xLjc6 IEkgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHBvaW50IG91dCBhbnkgc3BlY2lmaWMNCj4g IHByb2JsZW1zIGFzc29jaWF0ZWQgd2l0aCB1c2luZyBhIGxvdyBlbnRyb3B5IGh1bWFuIG1lbW9y YWJsZQ0KPnNlY3JldCAocGFzc3dvcmQpIGZvciB0aGUgdmFsdWUgUy4gTm8gbWF0dGVyIHdoYXQg eW91IHNheSwNCj5wZW9wbGUgd2lsbCBkbyB0aGF0LCBzbyBiZXR0ZXIgaWYgeW91IGNhbiBzYXkg eW91IHRvbGQgdGhlbQ0KPnNwZWNpZmljYWxseSBhYm91dCBkb3duc2lkZXMgb2YgZG9pbmcgdGhh dC4NCj4NCj4tIDQuMS4xMjogSSdtIG5vdCBzdXJlIGlmIHRoZSBNQVkgdGhlcmUgaXMgY29ycmVj dCBvciBub3QuICBJZg0KPiAgaXQgbWVhbnMgInlvdSBNQVkgdXNlIGEgZGlmZmVyZW50IGFsZ29y aXRobSB0byBnZXQgdGhlIHNhbWUNCj5vdXRwdXQgYXMgYWxnIDEyIiB0aGVuIHRoYXQnZCBiZSBm aW5lLiBJZiBzb21ldGhpbmcgZWxzZSBpcw0KPm1lYW50IEknbSBub3Qgc3VyZSB3aGF0IHlvdSdy ZSBzYXlpbmcsIGFuZCBpdCdkIHByb2JhYmx5IGJlDQo+YmV0dGVyIHRvIG5vdCBldmVuIG1lbnRp b24gaXQuDQo+DQo+LSBzZWN0aW9uIDUgc2hvdWxkIGFsc28gc3BlbGwgb3V0IHRoZSBzaWduYXR1 cmUgYW5kDQo+cHVibGljIGtleSBzaXplcyBpbiBieXRlcyBhbmQgaWRlYWxseSwgaWYgeW91IGtl ZXAgbXVsdGlwbGUNCj5vcHRpb25zLCAoYnV0IHBsZWFzZSBkb24ndDotKSBkZXNjcmliZSByZWxh dGl2ZSBvciBtZWFzdXJlZA0KPnRpbWluZ3MuDQo+DQo+DQo+DQoNCg== From nobody Mon Jun 19 09:52:21 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4419131652; Mon, 19 Jun 2017 09:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 yPHO8RiA-LL0; Mon, 19 Jun 2017 09:52:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A153F13169E; Mon, 19 Jun 2017 09:48:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D85FBBEAA; Mon, 19 Jun 2017 17:48:23 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZJzcn2YeFda; Mon, 19 Jun 2017 17:48:23 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C7CD4BE64; Mon, 19 Jun 2017 17:48:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497890899; bh=ltsKbZCJuYKdgnlIYBJ7rmUJgzToULvmEFF290ytHVY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=l7YqKWIuDAa4BA/NligjcBDv8NrYxjieIHghAR9DsFYXSKIwmdTBFkZ62krl9a9Wx srwq3tRT0G4oMRVgGlP1RbZ6o2RhSJJfL7jdQfSXQRk6wCm32+ILDgP4yAmGCEpkkt DP+jo2Y3SCdWAcHqlNRTmO0EJuT8+S1A3qev/OUI= To: "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> Date: Mon, 19 Jun 2017 17:48:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Anq5QderXe4qn09l5PPHOtjulNhDcDLPl" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:52:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Anq5QderXe4qn09l5PPHOtjulNhDcDLPl Content-Type: multipart/mixed; boundary="p6jwAVPv5KOcj8kMmAH27jxCm8i5crH9N"; protected-headers="v1" From: Stephen Farrell To: "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Message-ID: <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> Subject: Re: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> In-Reply-To: --p6jwAVPv5KOcj8kMmAH27jxCm8i5crH9N Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 19/06/17 17:37, Paterson, Kenny wrote: > @Stephen: thanks for making this thorough study of the draft. >=20 > @draft authors: can you please go through this feedback carefully and > implement the necessary changes? >=20 > The toughest part will likely be selecting one set of parameters. If > Stephen is amenable (but maybe he is not), I'd suggest highlighting one= > set amongst the several listed as being your "preferred" set (rather th= an > including just one set as Stephen suggests) - that'd be a halfway house= > between what you currently have and what Stephen suggests. I'm always amenable:-) For me, the key thing is to avoid folks using the RFC feeling the need to debate which set(s) of parameters to choose to use. Such debates are really wasteful, so reducing the set to the minimum is very helpful. If there's really a need for loads of parameters to be defined, (and I don't think there is for this), then that creates a need to explain when to use which, in sufficient detail for developers. So I do think it's easier to just delete options, and since there's an IANA registry, if it turns out more variants are needed later then those can be added as needed. So, absent someone saying that they need loads of options for their code, I'd say just one XMSS and one XMSS^MT option would be best. Cheers, S. >=20 > Cheers, >=20 > Kenny=20 >=20 >=20 > On 16/06/2017 01:56, "Stephen Farrell" wrot= e: >=20 >> >> Hi all, >> >> Apologies for being slow in reviewing this. My comments are below. >> I have two things that I think really ought be checked before this >> is ready for publication. When that's done, then I think this will >> be ready to publish. >> >> I also have two further comments/suggestions that I think would >> be significant and relatively easy improvements to the document. >> Those don't affect the IRSG review process though, considering the >> RG were presumably happy enough as-is. (I'd still argue for those >> changes though:-) >> >> And I've a bunch of mostly editorial comments that the authors can >> choose to take on board or not as they see fit. >> >> Cheers, >> S. >> >> >> possible errors: >> ---------------- >> >> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >> missing parenthesis around the "(w-1)" to me. Without those >> brackets I could interpret that test to always result in false. >> >> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >> as-is you seem to have incremented the index too soon so >> that when alg 11 does getIdx it'd presumably get the >> incremented index and cause verification failure. I think >> the same is true of alg 16 as well, in section 4.2.4. >> >> significant comments, but likely fixable: >> ----------------------------------------- >> >> - section 5: there are waaaay too many options defined here. >> As-is, this will damage potential deployment of xmss. I >> would strongly suggest deleting all of the options except the >> minimum, that being one (and only one) set of parameters for >> XMSS and one for XMSS^MT. If others are needed later, those >> can be defined later. (Note that the damage done here includes >> the hours of developer time that would be wasted debating >> which of these choices to implement/use. Consider the case of >> pre-hash variants of eddsa for an ongoing example.) >> >> - section 5 (or an appendix) should contain some test vectors >> (including intermediate values). Without those, implementers >> have a much harder time of getting their code right. >> >> nits, near-nits and other ignorable things: >> ------------------------------------------- >> >> - abstract: I'd suggest s/can withstand attacks/ can withstand >> so-far known attacks/ >> >> - 1.1: You say if used >1 time "no cryptographic security >> guarantees remain." It might be clearer to give some >> examples of consequences, e.g. that the attacker can forge new >> signatures or whatever. >> >> - 1.1: I think you might mention that XMSS and other OTS ideas >> require some new crypto APIs. I'm not aware if anyone has >> developed proposals for such, but would be interested if >> someone has. >> >> - 2.3, 2nd last para: you might want to say what happens with >> e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but >> someone might think it's 0x3c0 or even 0xc3. >> >> - 2.5: having the "type word" as octet 15 of a 32 byte address >> seems odd. Is there a reason why? (Just wondering.) >> >> - 2.6: It seems odd to given an example where the input and >> output of base_w() are the same. A different example may be >> more useful. (More examples generally would be great.) >> >> - 3.1.3: maybe note that "/" means nothing? Which I assume it >> does? Better might be to just say that. >> >> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >> units >> >> - 3.1.5: "the variable" - which one? >> >> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >> unsigned integer is sufficient." Sufficient for what? >> >> - 3.1.5: The ascii art at the end of p16 doesn't help much. >> >> - 3.1.7: The "MUST match" statement doesn't seem enforceable >> nor testable so I'm not sure it's a good idea to include. >> OTOH, I do get the idea of using 2119 terms for emphasis. >> >> - 3.1.7: I think it might be useful to point out any specific >> problems associated with using a low entropy human memorable >> secret (password) for the value S. No matter what you say, >> people will do that, so better if you can say you told them >> specifically about downsides of doing that. >> >> - 4.1.12: I'm not sure if the MAY there is correct or not. If >> it means "you MAY use a different algorithm to get the same >> output as alg 12" then that'd be fine. If something else is >> meant I'm not sure what you're saying, and it'd probably be >> better to not even mention it. >> >> - section 5 should also spell out the signature and >> public key sizes in bytes and ideally, if you keep multiple >> options, (but please don't:-) describe relative or measured >> timings. >> >> >> >=20 --p6jwAVPv5KOcj8kMmAH27jxCm8i5crH9N-- --Anq5QderXe4qn09l5PPHOtjulNhDcDLPl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSABSAAoJEC88hzaAX42iP98IAIiN6jXg18iFhSBBh8vZSRpM F9XuxNkUkL8K8kX4E7CtPQ91WkHDc1jaTlUFziTb35A8qDjjR8mK3curu+uY9cLR yjw/A8rcVsAiygbyHsJHJ8jIhbPpznbDmwccd19agekZL8thbxt9GsIH/2gEvYvB 415TJTUGQTdyLg0w30CUaFnBrKO9I87Aszaoji4gmFnXV4vcZddMM/9OU26Ielw1 XScmpbeTy91tBDu8/O4gzm7IluuaR/OZ90jaYIOVIP2c8kO41uclsICl3QthCjQ6 nMH30Jn1TFNLMT57ysCJMGPgXRjrcsWZgpjjGZ9PmptHSduDcFn+AEv3Er7YyXw= =LUqO -----END PGP SIGNATURE----- --Anq5QderXe4qn09l5PPHOtjulNhDcDLPl-- From nobody Tue Jun 20 00:59:10 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3A1292C5; Tue, 20 Jun 2017 00:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiHyk92Ydjeo; Tue, 20 Jun 2017 00:59:00 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (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 E68E8129400; Tue, 20 Jun 2017 00:58:59 -0700 (PDT) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dNE3r-0003q8-6y; Tue, 20 Jun 2017 09:58:55 +0200 Received: from [145.116.44.239] by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1dNE3r-0008Gt-0A; Tue, 20 Jun 2017 09:58:55 +0200 To: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> From: "A. Huelsing" Message-ID: <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> Date: Tue, 20 Jun 2017 09:58:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23490/Tue Jun 20 06:14:12 2017) Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 07:59:03 -0000 Hi, thanks a lot for your review Stephen. Let me comment on the parameter criticism. There is a crucial difference between XMSS and "traditional" signature schemes which influenced our decision. Unlike "traditional" signature schemes, XMSS (and all other Merkle-tree based, stateful schemes) the number of signatures one can generate using a key pair is controlled by the parameter h, the total tree hight, which also influences performance significantly (increasing h increases number of signatures but makes the scheme slower and signatures larger). What we tried to do was to reduce all parameters that really influence implementations (used hash function, hash function output length, Winternitz parameter) to a single mandatory parameter set (SHA2-256, 256, 16). This also fixes a single security level of 256 bit classical / 128 bit quantum. We only gave different mandatory options for the total tree height and - for XMSS^MT - different options for the number of layers d which controls the height of trees in a hypertree. I am not aware of an implementation that really relies on these two parameters being fixed. Low-level optimized implementations are rather vectorizing the hash-function implementation as there is not too much exploitable parallelism in the signature and verification algorithm as most operations are sequential (different story for stateless schemes). Now the selection really depends on what are your requirements, i.e., how many signatures should be possible with one key pair. I agree that we should support this highlighting the number of signatures as well as the signature size for each of these parameter sets. Finally, regarding the test vectors: I think it makes more sense to think of hash-based signatures as a protocol rather than a basic primitive. We have cross-verified reference implementations available. Is there an option to provide an implementation instead of test vectors? Then developers can test their implementation by verifying their signatures with the reference code and check their verification algorithm with signatures from the reference implementation. I am happy to add test cases (we already got those from the cross testing). What do you think? Andreas Am 19-06-17 um 18:48 schrieb Stephen Farrell: > Hiya, > > On 19/06/17 17:37, Paterson, Kenny wrote: >> @Stephen: thanks for making this thorough study of the draft. >> >> @draft authors: can you please go through this feedback carefully and >> implement the necessary changes? >> >> The toughest part will likely be selecting one set of parameters. If >> Stephen is amenable (but maybe he is not), I'd suggest highlighting one >> set amongst the several listed as being your "preferred" set (rather than >> including just one set as Stephen suggests) - that'd be a halfway house >> between what you currently have and what Stephen suggests. > I'm always amenable:-) > > For me, the key thing is to avoid folks using the RFC feeling > the need to debate which set(s) of parameters to choose to use. > Such debates are really wasteful, so reducing the set to the > minimum is very helpful. If there's really a need for loads > of parameters to be defined, (and I don't think there is for > this), then that creates a need to explain when to use which, > in sufficient detail for developers. > > So I do think it's easier to just delete options, and since > there's an IANA registry, if it turns out more variants are > needed later then those can be added as needed. So, absent > someone saying that they need loads of options for their code, > I'd say just one XMSS and one XMSS^MT option would be best. > > Cheers, > S. > >> Cheers, >> >> Kenny >> >> >> On 16/06/2017 01:56, "Stephen Farrell" wrote: >> >>> Hi all, >>> >>> Apologies for being slow in reviewing this. My comments are below. >>> I have two things that I think really ought be checked before this >>> is ready for publication. When that's done, then I think this will >>> be ready to publish. >>> >>> I also have two further comments/suggestions that I think would >>> be significant and relatively easy improvements to the document. >>> Those don't affect the IRSG review process though, considering the >>> RG were presumably happy enough as-is. (I'd still argue for those >>> changes though:-) >>> >>> And I've a bunch of mostly editorial comments that the authors can >>> choose to take on board or not as they see fit. >>> >>> Cheers, >>> S. >>> >>> >>> possible errors: >>> ---------------- >>> >>> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >>> missing parenthesis around the "(w-1)" to me. Without those >>> brackets I could interpret that test to always result in false. >>> >>> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >>> as-is you seem to have incremented the index too soon so >>> that when alg 11 does getIdx it'd presumably get the >>> incremented index and cause verification failure. I think >>> the same is true of alg 16 as well, in section 4.2.4. >>> >>> significant comments, but likely fixable: >>> ----------------------------------------- >>> >>> - section 5: there are waaaay too many options defined here. >>> As-is, this will damage potential deployment of xmss. I >>> would strongly suggest deleting all of the options except the >>> minimum, that being one (and only one) set of parameters for >>> XMSS and one for XMSS^MT. If others are needed later, those >>> can be defined later. (Note that the damage done here includes >>> the hours of developer time that would be wasted debating >>> which of these choices to implement/use. Consider the case of >>> pre-hash variants of eddsa for an ongoing example.) >>> >>> - section 5 (or an appendix) should contain some test vectors >>> (including intermediate values). Without those, implementers >>> have a much harder time of getting their code right. >>> >>> nits, near-nits and other ignorable things: >>> ------------------------------------------- >>> >>> - abstract: I'd suggest s/can withstand attacks/ can withstand >>> so-far known attacks/ >>> >>> - 1.1: You say if used >1 time "no cryptographic security >>> guarantees remain." It might be clearer to give some >>> examples of consequences, e.g. that the attacker can forge new >>> signatures or whatever. >>> >>> - 1.1: I think you might mention that XMSS and other OTS ideas >>> require some new crypto APIs. I'm not aware if anyone has >>> developed proposals for such, but would be interested if >>> someone has. >>> >>> - 2.3, 2nd last para: you might want to say what happens with >>> e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but >>> someone might think it's 0x3c0 or even 0xc3. >>> >>> - 2.5: having the "type word" as octet 15 of a 32 byte address >>> seems odd. Is there a reason why? (Just wondering.) >>> >>> - 2.6: It seems odd to given an example where the input and >>> output of base_w() are the same. A different example may be >>> more useful. (More examples generally would be great.) >>> >>> - 3.1.3: maybe note that "/" means nothing? Which I assume it >>> does? Better might be to just say that. >>> >>> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >>> units >>> >>> - 3.1.5: "the variable" - which one? >>> >>> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >>> unsigned integer is sufficient." Sufficient for what? >>> >>> - 3.1.5: The ascii art at the end of p16 doesn't help much. >>> >>> - 3.1.7: The "MUST match" statement doesn't seem enforceable >>> nor testable so I'm not sure it's a good idea to include. >>> OTOH, I do get the idea of using 2119 terms for emphasis. >>> >>> - 3.1.7: I think it might be useful to point out any specific >>> problems associated with using a low entropy human memorable >>> secret (password) for the value S. No matter what you say, >>> people will do that, so better if you can say you told them >>> specifically about downsides of doing that. >>> >>> - 4.1.12: I'm not sure if the MAY there is correct or not. If >>> it means "you MAY use a different algorithm to get the same >>> output as alg 12" then that'd be fine. If something else is >>> meant I'm not sure what you're saying, and it'd probably be >>> better to not even mention it. >>> >>> - section 5 should also spell out the signature and >>> public key sizes in bytes and ideally, if you keep multiple >>> options, (but please don't:-) describe relative or measured >>> timings. >>> >>> >>> From nobody Tue Jun 20 04:30:14 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E09131A37; Tue, 20 Jun 2017 04:30:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149795821266.23654.3156380083355252967@ietfa.amsl.com> Date: Tue, 20 Jun 2017 04:30:12 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-03.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:30:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-03.txt Pages : 46 Date : 2017-06-20 Abstract: If encryption is performed under a single key, there is a certain maximum threshold amount of data that can be safely encrypted. This amount is called key lifetime. This specification contains a description of a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms based on hash functions and on block ciphers that can be used with such modes of operations as CTR, GCM, CCM, CBC, CFB, OFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-03 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 20 04:42:09 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4933129B3C; Tue, 20 Jun 2017 04:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 qLb19vvliQOj; Tue, 20 Jun 2017 04:42:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA7A129AF7; Tue, 20 Jun 2017 04:41:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D0A6BE5D; Tue, 20 Jun 2017 12:41:55 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t8gH7DE6upE; Tue, 20 Jun 2017 12:41:54 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6EB15BE53; Tue, 20 Jun 2017 12:41:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497958914; bh=jjx/kI+ubdf3iOpb1gSD6Uuc1uEmT9+kDzeYkgK/yos=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cU0tNy6Vo5mEH+8U3Mb5xyVi5M8IzHNRY71vxEOB9NtC/wlW7iseVClkZekieNCRS fDaHPtjtP2LogRHvC2jr68AQ9apLt0NvHIA6nSiP/XjpuHmYehQQ7se5SvUaZf7B/x SBkeHot2aM0nNAkVXkbXG/gLIi4DAVuHsj/ZGFN0= To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> Date: Tue, 20 Jun 2017 12:41:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1nOe0VFA8nOn3NBf524iVOkWIGPlWWOua" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:42:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1nOe0VFA8nOn3NBf524iVOkWIGPlWWOua Content-Type: multipart/mixed; boundary="3d4TdoVJ7xf1FffO1Qkw3jc3dJi0mpPDl"; protected-headers="v1" From: Stephen Farrell To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Message-ID: <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> Subject: Re: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> In-Reply-To: <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> --3d4TdoVJ7xf1FffO1Qkw3jc3dJi0mpPDl Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Andreas, On 20/06/17 08:58, A. Huelsing wrote: > Hi, >=20 > thanks a lot for your review Stephen. >=20 > Let me comment on the parameter criticism. There is a crucial differenc= e between > XMSS and "traditional" signature schemes which influenced our decision.= > Unlike "traditional" signature schemes, XMSS (and all other Merkle-tree= based, > stateful schemes) the number of signatures one can generate using a key= pair > is controlled by the parameter h, the total tree hight, which also infl= uences > performance significantly (increasing h increases number of signatures = but makes > the scheme slower and signatures larger). >=20 >=20 > What we tried to do was to reduce all parameters that really influence > implementations (used hash function, hash function output length, Winte= rnitz > parameter) to a single mandatory parameter set (SHA2-256, 256, 16). Thi= s also > fixes a single security level of 256 bit classical / 128 bit quantum. W= e only > gave different mandatory options for the total tree height and - for XM= SS^MT - > different options for the number of layers d which controls the height = of trees > in a hypertree. I am not aware of an implementation that really relies = on these > two parameters being fixed. Low-level optimized implementations are rat= her > vectorizing the hash-function implementation as there is not too much > exploitable parallelism in the signature and verification algorithm as = most > operations are sequential (different story for stateless schemes). >=20 >=20 > Now the selection really depends on what are your requirements, i.e., h= ow many > signatures should be possible with one key pair. I agree that we should= support > this highlighting the number of signatures as well as the signature siz= e for > each of these parameter sets. So 5.2 has 3 required variants with h=3D10,16 and 20. And you have 9 optional variants there too. (In case folks reading this forget h=3D10 allows for 2^10 signatures.) And 5.3 has 8 required variants with h=3D20,40,60 and d varying between 2 and 12. And you have 24 optional variants. That's a total of 36 options, which I still maintain isn't useful. The probability that a verifier doesn't support a variant chosen by a signer seems like it'd be too high to me. And given what I imagine are the range of different implementation strategies, I'd also guess that a verifier could see performance vary in unexpected ways if it tries to support all 36, i.e. I'm guessing a verifier that can handle all 36 won't see best performance for all variants and might experience really bad performance for some. Considering 5.2 - I think I'd argue to only define the h=3D10 one for now (or only make that REQUIRED). My argument would be that any real application has to handle running out of signatures, and experience (mine anyway:-) says that hitting that sooner is better. (Sort of similar to how LE issues 90-day certificates as a way to ensure renewal gets done and gets automated - I think they got that right.) For 5.3 I'd also argue to just go with about the same number of signatures on the same basis, and to only make one variant REQUIRED, so h=3D20,d=3D2 I guess. I agree that adding more about the signature-count and maybe time/memory trade-offs would be good regardless. (Though that could be done in another draft if publishing now is a priority.) All that said, please note that I don't consider that this ought be blocking in terms of publication. (While still not liking that there's 36 options:-) >=20 > Finally, regarding the test vectors: I think it makes more sense to thi= nk of > hash-based signatures as a protocol rather than a basic primitive. We h= ave > cross-verified reference implementations available. Is there an option = to > provide an implementation instead of test vectors? Then developers can = test > their implementation by verifying their signatures with the reference c= ode and > check their verification algorithm with signatures from the reference > implementation. I am happy to add test cases (we already got those from= the > cross testing). It's maybe a bit late in the day but you could add an RFC7942 section to the draft describing implementations. That text is usually deleted from the RFC (an approach of which I'm not fond) but the I-D will still exist, so it'd not get lost. Or you could add a reference to wiki page or similar that has that kind of information. Either would be a fine thing to do. I guess at the stage we're at the latter would make more sense. (I did a quick search and didn't find such a page though, so I guess you'd have to make one with the names of implementations and links to code/docs.) And to be clear, if you don't have an implementation that can spit out test vectors and intermediate values, then I'm not asking that you make one now. Cheers, S. >=20 > What do you think? >=20 > Andreas >=20 >=20 > Am 19-06-17 um 18:48 schrieb Stephen Farrell: >> Hiya, >> >> On 19/06/17 17:37, Paterson, Kenny wrote: >>> @Stephen: thanks for making this thorough study of the draft. >>> >>> @draft authors: can you please go through this feedback carefully and= >>> implement the necessary changes? >>> >>> The toughest part will likely be selecting one set of parameters. If >>> Stephen is amenable (but maybe he is not), I'd suggest highlighting o= ne >>> set amongst the several listed as being your "preferred" set (rather = than >>> including just one set as Stephen suggests) - that'd be a halfway hou= se >>> between what you currently have and what Stephen suggests. >> I'm always amenable:-) >> >> For me, the key thing is to avoid folks using the RFC feeling >> the need to debate which set(s) of parameters to choose to use. >> Such debates are really wasteful, so reducing the set to the >> minimum is very helpful. If there's really a need for loads >> of parameters to be defined, (and I don't think there is for >> this), then that creates a need to explain when to use which, >> in sufficient detail for developers. >> >> So I do think it's easier to just delete options, and since >> there's an IANA registry, if it turns out more variants are >> needed later then those can be added as needed. So, absent >> someone saying that they need loads of options for their code, >> I'd say just one XMSS and one XMSS^MT option would be best. >> >> Cheers, >> S. >> >>> Cheers, >>> >>> Kenny=20 >>> >>> >>> On 16/06/2017 01:56, "Stephen Farrell" wr= ote: >>> >>>> Hi all, >>>> >>>> Apologies for being slow in reviewing this. My comments are below. >>>> I have two things that I think really ought be checked before this >>>> is ready for publication. When that's done, then I think this will >>>> be ready to publish. >>>> >>>> I also have two further comments/suggestions that I think would >>>> be significant and relatively easy improvements to the document. >>>> Those don't affect the IRSG review process though, considering the >>>> RG were presumably happy enough as-is. (I'd still argue for those >>>> changes though:-) >>>> >>>> And I've a bunch of mostly editorial comments that the authors can >>>> choose to take on board or not as they see fit. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>> possible errors: >>>> ---------------- >>>> >>>> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >>>> missing parenthesis around the "(w-1)" to me. Without those >>>> brackets I could interpret that test to always result in false. >>>> >>>> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >>>> as-is you seem to have incremented the index too soon so >>>> that when alg 11 does getIdx it'd presumably get the >>>> incremented index and cause verification failure. I think >>>> the same is true of alg 16 as well, in section 4.2.4. >>>> >>>> significant comments, but likely fixable: >>>> ----------------------------------------- >>>> >>>> - section 5: there are waaaay too many options defined here. >>>> As-is, this will damage potential deployment of xmss. I >>>> would strongly suggest deleting all of the options except the >>>> minimum, that being one (and only one) set of parameters for >>>> XMSS and one for XMSS^MT. If others are needed later, those >>>> can be defined later. (Note that the damage done here includes >>>> the hours of developer time that would be wasted debating >>>> which of these choices to implement/use. Consider the case of >>>> pre-hash variants of eddsa for an ongoing example.) >>>> >>>> - section 5 (or an appendix) should contain some test vectors >>>> (including intermediate values). Without those, implementers >>>> have a much harder time of getting their code right. >>>> >>>> nits, near-nits and other ignorable things: >>>> ------------------------------------------- >>>> >>>> - abstract: I'd suggest s/can withstand attacks/ can withstand >>>> so-far known attacks/ >>>> >>>> - 1.1: You say if used >1 time "no cryptographic security >>>> guarantees remain." It might be clearer to give some >>>> examples of consequences, e.g. that the attacker can forge new >>>> signatures or whatever. >>>> >>>> - 1.1: I think you might mention that XMSS and other OTS ideas >>>> require some new crypto APIs. I'm not aware if anyone has >>>> developed proposals for such, but would be interested if >>>> someone has. >>>> >>>> - 2.3, 2nd last para: you might want to say what happens with >>>> e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but >>>> someone might think it's 0x3c0 or even 0xc3. >>>> >>>> - 2.5: having the "type word" as octet 15 of a 32 byte address >>>> seems odd. Is there a reason why? (Just wondering.) >>>> >>>> - 2.6: It seems odd to given an example where the input and >>>> output of base_w() are the same. A different example may be >>>> more useful. (More examples generally would be great.) >>>> >>>> - 3.1.3: maybe note that "/" means nothing? Which I assume it >>>> does? Better might be to just say that. >>>> >>>> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >>>> units >>>> >>>> - 3.1.5: "the variable" - which one? >>>> >>>> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >>>> unsigned integer is sufficient." Sufficient for what? >>>> >>>> - 3.1.5: The ascii art at the end of p16 doesn't help much. >>>> >>>> - 3.1.7: The "MUST match" statement doesn't seem enforceable >>>> nor testable so I'm not sure it's a good idea to include. >>>> OTOH, I do get the idea of using 2119 terms for emphasis. >>>> >>>> - 3.1.7: I think it might be useful to point out any specific >>>> problems associated with using a low entropy human memorable >>>> secret (password) for the value S. No matter what you say, >>>> people will do that, so better if you can say you told them >>>> specifically about downsides of doing that. >>>> >>>> - 4.1.12: I'm not sure if the MAY there is correct or not. If >>>> it means "you MAY use a different algorithm to get the same >>>> output as alg 12" then that'd be fine. If something else is >>>> meant I'm not sure what you're saying, and it'd probably be >>>> better to not even mention it. >>>> >>>> - section 5 should also spell out the signature and >>>> public key sizes in bytes and ideally, if you keep multiple >>>> options, (but please don't:-) describe relative or measured >>>> timings. >>>> >>>> >>>> >=20 >=20 --3d4TdoVJ7xf1FffO1Qkw3jc3dJi0mpPDl-- --1nOe0VFA8nOn3NBf524iVOkWIGPlWWOua Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSQoCAAoJEC88hzaAX42itCoIAJBYTsecijXohVFXsSjOhaEi esej+DaLLWiMNOskfl1pUVAEdDKqd4ERrQ55cpVxmjVrxdpQwqi8Mjhe/v8jlbtK oWvzGT65DO2Z8nh1RqwLmwcQrCJfu5ncZlqEwWbM5vMZP2EI+qm/LmeUOQRq4zzA JwdSLMVf0oa5wZE6awJ2k2TTSoIaO9TkfPW3sen+xdjzl9JYs+w0KUtV1Tx6YKV8 e34gKSqMgkMTbPebyE6QpbKC04JxLSEX3C3ZPbUt/CFXjWIYdngBqUrPxqLKOCyw 3zEtUEwUQJv1DXXkFIc/CYAprBG7B7eJ5lNSQuUKgrO5HQe/opLBQQ8YNocohSA= =xh2e -----END PGP SIGNATURE----- --1nOe0VFA8nOn3NBf524iVOkWIGPlWWOua-- From nobody Tue Jun 20 04:45:24 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB09128D3E for ; Tue, 20 Jun 2017 04:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lutVRYCmAph8 for ; Tue, 20 Jun 2017 04:45:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B19129B2D for ; Tue, 20 Jun 2017 04:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD7ABBE64; Tue, 20 Jun 2017 12:45:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZmdc82Nyp9Q; Tue, 20 Jun 2017 12:45:12 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F36F8BE53; Tue, 20 Jun 2017 12:45:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497959112; bh=+yiMWJ0CnLwJA3Eh3O+UkFFy0XokVLJZ8pDS8vaAX54=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=vIm6TEMx8jsChEqmV3BSeazSeUnbl20+fh9U7hVyMNJJKpNYikTp82fst3Id5YHjr TrHbW3ktzYTZ/swQmB+mNfL2LGi27I43pK0lHRTs3KOZSAsVxwTzC7f9YpjQjuLP5z 75KqZoV6YN3fOnO5CvCkbFDe/he4+E+Azi05dxuM= To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 20 Jun 2017 12:45:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eNs3IVVKko6GO4o2jdEB1uW6t6bQ613ia" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:45:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eNs3IVVKko6GO4o2jdEB1uW6t6bQ613ia Content-Type: multipart/mixed; boundary="8UqSvgB2JroPgVuaP35pJPtet54PmUtxr"; protected-headers="v1" From: Stephen Farrell To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Message-ID: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> In-Reply-To: <4180756b-b718-05ce-2ea0-b8bf65fa8711@cs.tcd.ie> --8UqSvgB2JroPgVuaP35pJPtet54PmUtxr Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable (Dropping irsg) Oops, my arithmetic was wrong: it's 44 options, not 36:-) I left out the mandatory ones from 5.3. Doesn't affect the argument though. S. On 20/06/17 12:41, Stephen Farrell wrote: >=20 > Hi Andreas, >=20 > On 20/06/17 08:58, A. Huelsing wrote: >> Hi, >> >> thanks a lot for your review Stephen. >> >> Let me comment on the parameter criticism. There is a crucial differen= ce between >> XMSS and "traditional" signature schemes which influenced our decision= =2E >> Unlike "traditional" signature schemes, XMSS (and all other Merkle-tre= e based, >> stateful schemes) the number of signatures one can generate using a ke= y pair >> is controlled by the parameter h, the total tree hight, which also inf= luences >> performance significantly (increasing h increases number of signatures= but makes >> the scheme slower and signatures larger). >> >> >> What we tried to do was to reduce all parameters that really influence= >> implementations (used hash function, hash function output length, Wint= ernitz >> parameter) to a single mandatory parameter set (SHA2-256, 256, 16). Th= is also >> fixes a single security level of 256 bit classical / 128 bit quantum. = We only >> gave different mandatory options for the total tree height and - for X= MSS^MT - >> different options for the number of layers d which controls the height= of trees >> in a hypertree. I am not aware of an implementation that really relies= on these >> two parameters being fixed. Low-level optimized implementations are ra= ther >> vectorizing the hash-function implementation as there is not too much >> exploitable parallelism in the signature and verification algorithm as= most >> operations are sequential (different story for stateless schemes). >> >> >> Now the selection really depends on what are your requirements, i.e., = how many >> signatures should be possible with one key pair. I agree that we shoul= d support >> this highlighting the number of signatures as well as the signature si= ze for >> each of these parameter sets. >=20 > So 5.2 has 3 required variants with h=3D10,16 and 20. And you > have 9 optional variants there too. (In case folks reading > this forget h=3D10 allows for 2^10 signatures.) >=20 > And 5.3 has 8 required variants with h=3D20,40,60 and d varying > between 2 and 12. And you have 24 optional variants. >=20 > That's a total of 36 options, which I still maintain isn't > useful. The probability that a verifier doesn't support a > variant chosen by a signer seems like it'd be too high to > me. And given what I imagine are the range of different > implementation strategies, I'd also guess that a verifier > could see performance vary in unexpected ways if it tries > to support all 36, i.e. I'm guessing a verifier that can > handle all 36 won't see best performance for all variants > and might experience really bad performance for some. >=20 > Considering 5.2 - I think I'd argue to only define the h=3D10 > one for now (or only make that REQUIRED). My argument would > be that any real application has to handle running out of > signatures, and experience (mine anyway:-) says that hitting > that sooner is better. (Sort of similar to how LE issues > 90-day certificates as a way to ensure renewal gets done and > gets automated - I think they got that right.) >=20 > For 5.3 I'd also argue to just go with about the same number > of signatures on the same basis, and to only make one variant > REQUIRED, so h=3D20,d=3D2 I guess. >=20 > I agree that adding more about the signature-count and maybe > time/memory trade-offs would be good regardless. (Though that > could be done in another draft if publishing now is a priority.) >=20 > All that said, please note that I don't consider that this > ought be blocking in terms of publication. (While still not > liking that there's 36 options:-) >=20 >> >> Finally, regarding the test vectors: I think it makes more sense to th= ink of >> hash-based signatures as a protocol rather than a basic primitive. We = have >> cross-verified reference implementations available. Is there an option= to >> provide an implementation instead of test vectors? Then developers can= test >> their implementation by verifying their signatures with the reference = code and >> check their verification algorithm with signatures from the reference >> implementation. I am happy to add test cases (we already got those fro= m the >> cross testing). >=20 > It's maybe a bit late in the day but you could add an RFC7942 > section to the draft describing implementations. That text is > usually deleted from the RFC (an approach of which I'm not fond) > but the I-D will still exist, so it'd not get lost. Or you > could add a reference to wiki page or similar that has that > kind of information. Either would be a fine thing to do. I guess > at the stage we're at the latter would make more sense. (I did > a quick search and didn't find such a page though, so I guess > you'd have to make one with the names of implementations and > links to code/docs.) >=20 > And to be clear, if you don't have an implementation that can > spit out test vectors and intermediate values, then I'm not > asking that you make one now. >=20 > Cheers, > S. >=20 >> >> What do you think? >> >> Andreas >> >> >> Am 19-06-17 um 18:48 schrieb Stephen Farrell: >>> Hiya, >>> >>> On 19/06/17 17:37, Paterson, Kenny wrote: >>>> @Stephen: thanks for making this thorough study of the draft. >>>> >>>> @draft authors: can you please go through this feedback carefully an= d >>>> implement the necessary changes? >>>> >>>> The toughest part will likely be selecting one set of parameters. If= >>>> Stephen is amenable (but maybe he is not), I'd suggest highlighting = one >>>> set amongst the several listed as being your "preferred" set (rather= than >>>> including just one set as Stephen suggests) - that'd be a halfway ho= use >>>> between what you currently have and what Stephen suggests. >>> I'm always amenable:-) >>> >>> For me, the key thing is to avoid folks using the RFC feeling >>> the need to debate which set(s) of parameters to choose to use. >>> Such debates are really wasteful, so reducing the set to the >>> minimum is very helpful. If there's really a need for loads >>> of parameters to be defined, (and I don't think there is for >>> this), then that creates a need to explain when to use which, >>> in sufficient detail for developers. >>> >>> So I do think it's easier to just delete options, and since >>> there's an IANA registry, if it turns out more variants are >>> needed later then those can be added as needed. So, absent >>> someone saying that they need loads of options for their code, >>> I'd say just one XMSS and one XMSS^MT option would be best. >>> >>> Cheers, >>> S. >>> >>>> Cheers, >>>> >>>> Kenny=20 >>>> >>>> >>>> On 16/06/2017 01:56, "Stephen Farrell" w= rote: >>>> >>>>> Hi all, >>>>> >>>>> Apologies for being slow in reviewing this. My comments are below. >>>>> I have two things that I think really ought be checked before this >>>>> is ready for publication. When that's done, then I think this will >>>>> be ready to publish. >>>>> >>>>> I also have two further comments/suggestions that I think would >>>>> be significant and relatively easy improvements to the document. >>>>> Those don't affect the IRSG review process though, considering the >>>>> RG were presumably happy enough as-is. (I'd still argue for those >>>>> changes though:-) >>>>> >>>>> And I've a bunch of mostly editorial comments that the authors can >>>>> choose to take on board or not as they see fit. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>> possible errors: >>>>> ---------------- >>>>> >>>>> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >>>>> missing parenthesis around the "(w-1)" to me. Without those >>>>> brackets I could interpret that test to always result in false. >>>>> >>>>> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >>>>> as-is you seem to have incremented the index too soon so >>>>> that when alg 11 does getIdx it'd presumably get the >>>>> incremented index and cause verification failure. I think >>>>> the same is true of alg 16 as well, in section 4.2.4. >>>>> >>>>> significant comments, but likely fixable: >>>>> ----------------------------------------- >>>>> >>>>> - section 5: there are waaaay too many options defined here. >>>>> As-is, this will damage potential deployment of xmss. I >>>>> would strongly suggest deleting all of the options except the >>>>> minimum, that being one (and only one) set of parameters for >>>>> XMSS and one for XMSS^MT. If others are needed later, those >>>>> can be defined later. (Note that the damage done here includes >>>>> the hours of developer time that would be wasted debating >>>>> which of these choices to implement/use. Consider the case of >>>>> pre-hash variants of eddsa for an ongoing example.) >>>>> >>>>> - section 5 (or an appendix) should contain some test vectors >>>>> (including intermediate values). Without those, implementers >>>>> have a much harder time of getting their code right. >>>>> >>>>> nits, near-nits and other ignorable things: >>>>> ------------------------------------------- >>>>> >>>>> - abstract: I'd suggest s/can withstand attacks/ can withstand >>>>> so-far known attacks/ >>>>> >>>>> - 1.1: You say if used >1 time "no cryptographic security >>>>> guarantees remain." It might be clearer to give some >>>>> examples of consequences, e.g. that the attacker can forge new >>>>> signatures or whatever. >>>>> >>>>> - 1.1: I think you might mention that XMSS and other OTS ideas >>>>> require some new crypto APIs. I'm not aware if anyone has >>>>> developed proposals for such, but would be interested if >>>>> someone has. >>>>> >>>>> - 2.3, 2nd last para: you might want to say what happens with >>>>> e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but >>>>> someone might think it's 0x3c0 or even 0xc3. >>>>> >>>>> - 2.5: having the "type word" as octet 15 of a 32 byte address >>>>> seems odd. Is there a reason why? (Just wondering.) >>>>> >>>>> - 2.6: It seems odd to given an example where the input and >>>>> output of base_w() are the same. A different example may be >>>>> more useful. (More examples generally would be great.) >>>>> >>>>> - 3.1.3: maybe note that "/" means nothing? Which I assume it >>>>> does? Better might be to just say that. >>>>> >>>>> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >>>>> units >>>>> >>>>> - 3.1.5: "the variable" - which one? >>>>> >>>>> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >>>>> unsigned integer is sufficient." Sufficient for what? >>>>> >>>>> - 3.1.5: The ascii art at the end of p16 doesn't help much. >>>>> >>>>> - 3.1.7: The "MUST match" statement doesn't seem enforceable >>>>> nor testable so I'm not sure it's a good idea to include. >>>>> OTOH, I do get the idea of using 2119 terms for emphasis. >>>>> >>>>> - 3.1.7: I think it might be useful to point out any specific >>>>> problems associated with using a low entropy human memorable >>>>> secret (password) for the value S. No matter what you say, >>>>> people will do that, so better if you can say you told them >>>>> specifically about downsides of doing that. >>>>> >>>>> - 4.1.12: I'm not sure if the MAY there is correct or not. If >>>>> it means "you MAY use a different algorithm to get the same >>>>> output as alg 12" then that'd be fine. If something else is >>>>> meant I'm not sure what you're saying, and it'd probably be >>>>> better to not even mention it. >>>>> >>>>> - section 5 should also spell out the signature and >>>>> public key sizes in bytes and ideally, if you keep multiple >>>>> options, (but please don't:-) describe relative or measured >>>>> timings. >>>>> >>>>> >>>>> >> >> >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 --8UqSvgB2JroPgVuaP35pJPtet54PmUtxr-- --eNs3IVVKko6GO4o2jdEB1uW6t6bQ613ia Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSQrHAAoJEC88hzaAX42ib/4H/iOQOyjGvHzx7b354owFk0j/ jal7yJGj2uNSzDSOkuJ2Xsz7ijnAozATljNbVVDc2Vw3pjfpowRzxgzvuftoPUSq DosGmDUo5Q0mtVxGlOqBhN0iMgaJK1GbTQZvh6mZuhApQ3O7+fMEiUY6+DGTM+Qq S4Nzs5sXW80Ql/B4J072QYDlfxbnH6syuokrkAYEvGTqKGqB64dVq0015mY5lbLm Hp+ejdW3yti7n59ZYSxtCxFljsM3GRUHkAIWJh1YYUcPLwXJXpzKWoht8b7/Bvp/ Lwni2giC3H0PHHq5W/spHD7xr8Nx+/pl6T4EID9v3g7JYNtP7Z9i7Km96kkaREA= =dfKs -----END PGP SIGNATURE----- --eNs3IVVKko6GO4o2jdEB1uW6t6bQ613ia-- From nobody Tue Jun 20 05:42:03 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF5129BCD for ; Tue, 20 Jun 2017 05:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 PvPLlYmWoRuj for ; Tue, 20 Jun 2017 05:41:59 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 C8C1A129BCF for ; Tue, 20 Jun 2017 05:41:58 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id u12so132376374qth.0 for ; Tue, 20 Jun 2017 05:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1gWmSl1PVoWMlHYgkttsAk+r/govcW/8E17ts4dDGKY=; b=MvTTirqRx4vjmfs9w2/V/GiApNnkrgsAslcKlb9FOvPbzAGZ6E16WkH2DiGEBQ0Sy3 2QUlDoogQxZ+Su8TrEoeKLi1lf0MdQ2w7LxuLtMX6EuVbnoOFxz+BSWlFP0uVMPm011s ES9UPnTfZxh7VJYtsG5wv6Mdpop3lWMNe7g9AaSgFSFbRh+CrddkArY1VL3Gg5UtUz9a 0WuMgIh831aGRSukWgV3Gkeo8ci6B343q0vWTNIp11P72hJbZuxKlUavAtKzvKX5ZEGn 8+W2VS0YGy4nHHw++iaitZ+b28OchKvkSzm0jq3jGr6RkuTLBHP+g3hbqTJroC4XfPXz ECBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1gWmSl1PVoWMlHYgkttsAk+r/govcW/8E17ts4dDGKY=; b=By+VMA6ykVjWTDTchy476VjTK7m++ZP0Ep1g4JRKH6V/61yRHnufok6sccjfeg0VOb 9F3y4Y2+W9SIexcx3bn1kRh4hdY8Kqv5OqCNH8sgW3kMB4ISi6iDpV9kT0ivwak3bTiV 0Ga3o2pPempal1kVg1k2GNeEXZvm9kcJ/8tYnndMXrpT4TLVCoUIW6Y9qEU9znCF74/E 9mOv66t4mNzy8V7O8EDndrKyVqEgc54hAQjLGLMmQkM0fXfIaPGjb7rXMlV2jB/GcxBQ 0D/PPO40tRw7puvzwUGwRiBfjfw8Ywzb83tFuCwlsG6KtxbQrM/l8R0A+hU3ARNnE0// dd1Q== X-Gm-Message-State: AKS2vOzoNnw1h89H2tLNyjsy0QGnn0BQExcy94g9O5iOfFXOsIQNzU19 RhniG6wJ0ELZWLvJDN/LAREiEpOg4e0i X-Received: by 10.200.9.47 with SMTP id t44mr2786836qth.107.1497962517977; Tue, 20 Jun 2017 05:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.77 with HTTP; Tue, 20 Jun 2017 05:41:57 -0700 (PDT) In-Reply-To: <89AFF43D-EFE7-4D7F-8ECE-877A4BEBD546@vigilsec.com> References: <149667340139.3152.10556340180920549215@ietfa.amsl.com> <89AFF43D-EFE7-4D7F-8ECE-877A4BEBD546@vigilsec.com> From: "Stanislav V. Smyshlyaev" Date: Tue, 20 Jun 2017 15:41:57 +0300 Message-ID: To: Russ Housley Cc: cfrg@ietf.org Content-Type: multipart/alternative; boundary="001a1144be4ac55eb805526393eb" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:42:01 -0000 --001a1144be4ac55eb805526393eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues, We've posted an updated version of the draft (see https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-03), in which we've tried to address received concerns (thanks again for all of them, by the way!). Almost all the comments were fully taken into account, with the following comments: 1. > Section 1, Last paragraph: Please separate the ideas here. First, TLS 1.3 is an example of a protocol with external re-key. Second, there is a discussion of the benefits of re-key. The first belongs elsewhere. We completely agree with this comment, but instead of separating these ideas, we deleted the first sentence, since the reference to TLS 1.3 is provided below. 2. > Section 4, first item number 3 says: . . . provides forward and backward security of session keys . . . This is only true if the previous traffic keys are securely deleted by all parties that have the keys. We added this clarification to Security Considerations section. 3. > Wouldn=E2=80=99t it be cleaner to say: L =3D min(L1, L2), q =3D min(q= 1, q2), q*m <=3D L We added this explanation, but we did not remove the old text, because it looks important to show that (as L1 is usually much less than L2) the key lifetime can be greatly increased, because re-keying lets us to forget about the "side-channel limitation" L1. Best regards, Stanislav 2017-06-09 0:39 GMT+03:00 Russ Housley : > I have a few comments on the most recent version of this document. > > Section 1: Please describe parallel and serial re-keying mechanisms in th= e > introduction. > > Section 1: I think we need to say more about internal re-key when it is > first introduced. I suggest: > > This specification presents two approaches that extend the key > lifetime for a single symmetric key while avoiding renegotiation: > external and internal re-keying. External re-keying is performed by a > protocol, and it is independent of block cipher, key size, and mode. > Internal re-keying is built into the mode, and it depends heavily on > the properties of the block cipher and key size. > > Section 1, Last paragraph: Please separate the ideas here. First, TLS 1.= 3 > is an example of a protocol with external re-key. Second, there is a > discussion of the benefits of re-key. The first belongs elsewhere. > > Section 4 says: > > . . . External re- > keying approach is recommended for usage in protocols that process > quite small messages. . . . > > It is obvious that the message size can exceed L. That said, external > re-keying is also very useful when there are lots of messages or the > protocol has a way to break a very large message into manageable chunks. > Obviously, TCP breaks a very large stream into many manageable chunks. > > Section 4, first item number 3 says: > > . . . provides forward and backward security of session keys . . . > > This is only true if the previous traffic keys are securely deleted by al= l > parties that have the keys. > > Section 5, bottom of page 8: Wouldn=E2=80=99t it be cleaner to say: > > L =3D min(L1, L2) > q =3D min(q1, q2) > q*m <=3D L > > > > Nits: > > Please use figure numbers and captions on the illustrations. > > Section 1: s/С/C/ > > Section 4: s/Homever/However/ > > Section 4: s/it almost does not affect performance/minimal impact on > performance/ > > Section 4: s/sessin keys/session keys/ > > Section 4: s/always have an access/always has access/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a1144be4ac55eb805526393eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

We'= ;ve posted an updated version of the draft (see https://tools.ietf.org/html/draft= -irtf-cfrg-re-keying-03), in which we've tried to address received = concerns (thanks again for all of them, by the way!).=C2=A0
Almos= t all the comments were fully taken into account, with the following commen= ts:
1. > Section 1, Last paragraph: Please separate the ideas here.= First, TLS 1.3 is an example of a protocol with external re-key. Second, t= here is a discussion of the benefits of re-key. The first belongs elsewhere= .
We completely agree with this comment, but instead of separatin= g these ideas, we deleted the first sentence, since the reference to TLS 1.= 3 is provided below.
2. > Section 4, first item number 3 says:
. . . provides forward and backward security of session keys . . .
This is only true if the previous traffic keys are securely deleted= by all parties that have the keys.
We added this clarification t= o Security Considerations section.
3. > =C2=A0Wouldn=E2=80=99t it b= e cleaner to say: L =3D min(L1, L2), q =3D min(q1, q2), q*m <=3D L
=
We added this explanation, but we did not remove the old text, because= it looks important to show that (as L1 is usually much less than L2) the k= ey lifetime can be greatly increased, because re-keying lets us to forget a= bout the "side-channel limitation" L1.=C2=A0

=
Best regards,
Stanislav


2017-06-09 0:39 GMT+03:00 Russ Housley <= housley@vigilsec.com>:
I have a few comments on the most recent version of this doc= ument.

Section 1: Please describe parallel and serial re-keying mechanisms in the = introduction.

Section 1: I think we need to say more about internal re-key when it is fir= st introduced.=C2=A0 I suggest:

=C2=A0 =C2=A0This specification presents two approaches that extend the key=
=C2=A0 =C2=A0lifetime for a single symmetric key while avoiding renegotiati= on:
=C2=A0 =C2=A0external and internal re-keying.=C2=A0 External re-keying is p= erformed by a
=C2=A0 =C2=A0protocol, and it is independent of block cipher, key size, and= mode.
=C2=A0 =C2=A0Internal re-keying is built into the mode, and it depends heav= ily on
=C2=A0 =C2=A0the properties of the block cipher and key size.

Section 1, Last paragraph: Please separate the ideas here.=C2=A0 First, TLS= 1.3 is an example of a protocol with external re-key.=C2=A0 Second, there = is a discussion of the benefits of re-key.=C2=A0 The first belongs elsewher= e.

Section 4 says:

=C2=A0 =C2=A0. . .=C2=A0 =C2=A0External re-
=C2=A0 =C2=A0keying approach is recommended for usage in protocols that pro= cess
=C2=A0 =C2=A0quite small messages. . . .

It is obvious that the message size can exceed L.=C2=A0 That said, external= re-keying is also very useful when there are lots of messages or the proto= col has a way to break a very large message into manageable chunks.=C2=A0 O= bviously, TCP breaks a very large stream into many manageable chunks.

Section 4, first item number 3 says:

=C2=A0 =C2=A0. . .=C2=A0 provides forward and backward security of session = keys . . .

This is only true if the previous traffic keys are securely deleted by all = parties that have the keys.

Section 5, bottom of page 8:=C2=A0 Wouldn=E2=80=99t it be cleaner to say:
=C2=A0 =C2=A0L =3D min(L1, L2)
=C2=A0 =C2=A0q =3D min(q1, q2)
=C2=A0 =C2=A0q*m <=3D L



Nits:

Please use figure numbers and captions on the illustrations.

Section 1: s/&#1057;/C/

Section 4: s/Homever/However/

Section 4: s/it almost does not affect performance/minimal impact on perfor= mance/

Section 4: s/sessin keys/session keys/

Section 4: s/always have an access/always has access/

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--001a1144be4ac55eb805526393eb-- From nobody Wed Jun 21 06:30:44 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D492129B08 for ; Wed, 21 Jun 2017 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 K6HegIt1ZhPs for ; Wed, 21 Jun 2017 06:30:36 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30047.outbound.protection.outlook.com [40.107.3.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA736129AE7 for ; Wed, 21 Jun 2017 06:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kKxx6j5GqAbEuNQ/0SwBzj4lWivE23i9Jzogt7eJ5yc=; b=AE/bz7wkaaxxGXhXiIF1zAjG9FdDOwQ+Rz215YOpB7d/QLUPbdcDUORaVq56uivxas2dHtvLheBTPSjSXwFWB7i+riDbjffKRY/z2CHqTuzaVZRB9+8+0UHs5VaqzWNiF2S+ccGrL+t80DXztu9PPZiRcLHGKlBNSfCl/akfxf8= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Wed, 21 Jun 2017 13:30:28 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a0cf:ee9d:63a3:d1ab]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a0cf:ee9d:63a3:d1ab%14]) with mapi id 15.01.1178.023; Wed, 21 Jun 2017 13:30:27 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Call for agenda items for meeting at IETF99 Thread-Index: AQHS6pKL31iWsAdm/UaibQCNZCcQIQ== Date: Wed, 21 Jun 2017 13:30:27 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.62.179] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:vvXZPp+wXNOKNsPnSBZPEd0yX2ZgKyeCdL774Kewsjjue46SUYzsWruqVahFpiwwFQRm+Do8gKEepejTcoCYy+zEYOxrIFoL+Cs2HfOKtZ4vGcx5PfsnpARasnxHA38CbYNIikMhBINV3P4/IvoJcSAvPhcRbWjo/fzYmlWK3d2CHlsxAZwie7BLie+07Z8XHNNHr71jzffwUtHBlmUoNMVqMSlvDYO/1maFON2FmqR5QWEC9gE9nfL6oCBlbI86gAJG5VzcsGSIcT2YDDXDqhXMogweatf1if0mROchtMMUi8yHjQ+C2zn/1lOeBORJnaITYYTnSbcKoEqBSMTO47ySyyKdPdf3CcsTcY0QpE8BnT6k8L0Ld1jxVMd+QkrV6FpjkL7hX90yTfOLNbW4YnWY5o0kUliAc+XUK6GQAkyesEG4pn6zyaIoaz8iubgmvttGmGCjVkKtyi21FvXvCcUvLHUXXNZ1jPB3WLTp4mTEVZ8jDm+aFsIP1icjJVrwBnqxNyO52/2Yq+vji106OW6F/Z+AG7aa9ajgmwhLTglUJcna/K8zNMZSK6eBWrnLPcBiJhvWa+kMW0JVqnzwgCekkeB0VbuGsA3YOBtfKlFNIryMRo2RpmqdABOwKnURXVVZqL3XKsE2yfa9jpeUVkoY4owI3L8wRUB+zeg2GdLwDlIt/uiS/mLtdifYkhIteoS2OV4J4Vxb8lx825g6hLnZY312l4BQRZ9X+yCH2jwBm4uZYVRrhgHgoIBbUZ4ndLqjG2LzKTmA0gfROcKqbfGeFJA/2dzF+24GzJ7Ic0o= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(7736002)(99286003)(6436002)(5640700003)(25786009)(53936002)(54356999)(4326008)(110136004)(6486002)(38730400002)(50986999)(3660700001)(1730700003)(81166006)(8676002)(3280700002)(6512007)(8936002)(74482002)(102836003)(3846002)(6116002)(36756003)(4001350100001)(2900100001)(2351001)(6506006)(189998001)(305945005)(5660300001)(2906002)(413944005)(66066001)(478600001)(86362001)(72206003)(83506001)(5250100002)(42882006)(6916009)(14454004)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 77e363e2-a116-4d09-263d-08d4b8a9ae1b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0345CFD558 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8F2D7FACC962C64180760B603D3076E3@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 13:30:27.5143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: [Cfrg] Call for agenda items for meeting at IETF99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:30:43 -0000 RGVhciBDRlJHLA0KDQpDRlJHIHdpbGwgYmUgbWVldGluZyBpbiBQcmFndWUgYXQgSUVURjk5IGlu IG1pZC1KdWx5LiBXZSBhcmUgc2NoZWR1bGVkIGZvcg0KMTU1MC0xNzUwIChBZnRlcm5vb24gU2Vz c2lvbiBJSSkgb24gVHVlc2RheSAxOHRoIEp1bHkuDQoNCldlIGFscmVhZHkgaGF2ZSBwbGFubmVk IHByZXNlbnRhdGlvbnMgYW5kIGRpc2N1c3Npb25zIG9uOg0KDQotLSBLZXkgdXBkYXRpbmcgKFN0 YW5pc2xhdiBTbXlzaGx5YWV2KQ0KLS0gVmVyaWZpYWJsZSBSYW5kb20gRnVuY3Rpb25zIChTaGFy b24gR29sZGJlcmcpDQotLSBOZXcgcHJpbWVzIChEYW4gQnJvd24pDQoNCldlIHByb2JhYmx5IGhh dmUgc3BhY2UgZm9yIGEgY291cGxlIG9mIGFkZGl0aW9uYWwgdG9waWNzLg0KDQpJZiB5b3Ugd291 bGQgbGlrZSBzb21lIHRpbWUgdG8gcHJlc2VudCBvciB0byBwcm9wb3NlIGEgdG9waWMgZm9yDQpk aXNjdXNzaW9uLCBwbGVhc2UgY29udGFjdCBtZSBhbmQgQWxleGV5ICh0aGUgY2hhaXJzKSBieSBG cmlkYXkgMzB0aCBKdW5lLg0KDQpUaGFua3MsDQoNCktlbm55ICANCg0K From nobody Wed Jun 21 06:41:21 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE6120724; Wed, 21 Jun 2017 06:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Cc: irsg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149805248063.15521.14113442600107079860.idtracker@ietfa.amsl.com> Date: Wed, 21 Jun 2017 06:41:20 -0700 Archived-At: Subject: [Cfrg] The CFRG RG has placed draft-nir-cfrg-rfc7539bis in state "Candidate RG Document" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:41:21 -0000 The CFRG RG has placed draft-nir-cfrg-rfc7539bis in state Candidate RG Document (entered by Amy Vezza) The document is available at https://datatracker.ietf.org/doc/draft-nir-cfrg-rfc7539bis/ From nobody Fri Jun 23 00:07:20 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9647B129C32 for ; Fri, 23 Jun 2017 00:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.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 Ff6yZQ89MGzv for ; Fri, 23 Jun 2017 00:07:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0074.outbound.protection.outlook.com [104.47.36.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C1F1200CF for ; Fri, 23 Jun 2017 00:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NCzQirTQ8pQ1Zln3gE8VWtfhmTSrjTtwkoZnOqvWSng=; b=YcEf1fzWzpQTUT81TiUqYirC1olanLvaeM8PQ6ecQ8pghRBhBK0ZHh8Zu/BVNB00Ugg98LaeRRDV0ahGueY5LuFBcSt4v2Bbtud1OijimbQaEq0CQ/nLU7Hqsjis/Oy+Psy+G4zRVj9P9hdsvLHsU7Ft316adZyPbdJAyfiPqAo= Received: from BLUPR0201MB1585.namprd02.prod.outlook.com (10.163.120.140) by BLUPR0201MB1585.namprd02.prod.outlook.com (10.163.120.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Fri, 23 Jun 2017 07:07:13 +0000 Received: from BLUPR0201MB1585.namprd02.prod.outlook.com ([10.163.120.140]) by BLUPR0201MB1585.namprd02.prod.outlook.com ([10.163.120.140]) with mapi id 15.01.1178.023; Fri, 23 Jun 2017 07:07:13 +0000 From: Antonio Sanso To: Peter Dettman CC: Francisco Rodriguez- Henriquez , "cfrg@irtf.org" , =?Windows-1252?Q?Julio_C=E9sar_Lopez?= , Thomaz Oliveira , "huseyin.hisil@yasar.edu.tr" Thread-Topic: [Cfrg] How to (pre-)compute a ladder [revised version] Thread-Index: AQHSyrVtu4VVdn8k90q2mdRQReJ0C6InJRYAgAskMgA= Date: Fri, 23 Jun 2017 07:07:13 +0000 Message-ID: References: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> In-Reply-To: <02899a12-8cf7-c318-32ea-9491ec2a22c2@bouncycastle.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bouncycastle.org; dkim=none (message not signed) header.d=none; bouncycastle.org; dmarc=none action=none header.from=adobe.com; x-originating-ip: [192.147.117.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0201MB1585; 7:UgCheSLSqY2KLoEs0YmRufMo10S6DX+Km/hJtJtuoeykUykd7AheV0LH4O02+tHhz6YQbnNU//P9PQ0G6wwC0BLIgJSizFl4vxwC0D6f5aZIHQ9gfJ5fDQCLbyl2hdEP5CPzk5iaKITTqbTDvBnnHTtdvksKxFEFy1QPI0NIne210xczxC1oDSLyKBZGCJcjX1O6e3XpDda8GeZ4z7oRpCDFIwhEYoq+s8BRB/unmoXlkJasHzsuM5bIQxz7R/emFN24tllbfXguJeEDzL8cWM7exnQP0BndG7xqfvzgklhYU+ERlhpVYewQY8AEj9UF+mz2a9BUXnuuAt06hh0oNKBqr/UXb7uUuJbZtOL0czviDHQr5vVm9U8HkyLrkYSNu6ts5rBW4pC1TDUHCVIR4Uyc6aXb74g+qq+WPqDtdCQbGY+oPvbzBg2kq3JWgoulVFT++6X4B61hffb5S/+PDypwaka4ym+SKOQO5V6Cf1ycng/Cgb9bv2T0tw5hK9iawWr6ddVPGiQzxwRabUKja4rdeKQOSh2f5ZbsR7MCxnBkmGshVuuCleg0+J4Bu1+xgKhAFCXvVrVmsSAlyQc+/RO02ReLTXWawTa5uQn8Vf/dJHD1ShyVi9sFREWLzIedtjSN+RVKEQVGUlqk+bna/cR2zHobzCSJbyzQXZtmBNSEumStetksLH6Ukr4Qi0V/E5khHgZxCUCijh5KjJSsp2guPsL/fL0fD7BtdDHol2O7PTOB8BCuU0L2k1U//ssjVvwBnSxNEsIOoDbfs8w4T3z9mJjkCFgMQ+cTl/rJHRY= x-ms-office365-filtering-correlation-id: 3e00fb1b-6269-4bbd-f6d4-08d4ba06793f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0201MB1585; x-ms-traffictypediagnostic: BLUPR0201MB1585: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0201MB1585; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0201MB1585; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39860400002)(39400400002)(39410400002)(39450400003)(24454002)(377454003)(83716003)(10090500001)(2906002)(50986999)(54356999)(76176999)(3846002)(229853002)(38730400002)(110136004)(7736002)(53936002)(561944003)(478600001)(39060400002)(6116002)(102836003)(122556002)(2900100001)(33656002)(6916009)(8676002)(6436002)(2950100002)(81166006)(3280700002)(6246003)(25786009)(53546010)(3660700001)(66066001)(36756003)(86362001)(305945005)(5660300001)(6506006)(4326008)(6306002)(6512007)(966005)(54906002)(189998001)(14454004)(8936002)(6486002)(99286003)(77096006)(82746002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0201MB1585; H:BLUPR0201MB1585.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2017 07:07:13.1793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1585 Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 07:07:19 -0000 hi Peter On Jun 16, 2017, at 6:58 AM, Peter Dettman = wrote: > Hi Francisco, >=20 > I've updated my (java) implementations of X25519 and X448 in line with > your revised paper. out of curiosity is this a public repo I can look at ? :) regards antonio > My rough benchmark results for a complete ECDH are > -17.7% and -19.5% time required for X25519 and X448 respectively. >=20 > These are perhaps slightly more modest than the paper's estimates. Your > paper already anticipates that (uncounted) field add/sub are significant > in practice. >=20 > Part of the difference however is that my implementation of Algorithm 3 > handles the final 'q' bits using simple doublings, and removes redundant > cswaps - just as Algorithm 5 does. Of course Alg. 3 is just as presented > in RFC 7748, but it might be a fairer comparison to first apply to Alg. > 3 those of your optimizations that are applicable. >=20 > Also, my (32-bit) X448 implementation (Alg. 5) required a carry > propagation for 'A' (line 10), due to tight bounds on limbs when > squaring D, E. I did the same for (32-bit) X25519 although I haven't yet > proved it necessary. >=20 > An idea: for fixed-base X25519, why not precompute one doubling? i.e. > just calculate (k/2) * 2P, needing only 2 final doublings (you even > already have S of order 4). I am not sure whether this extends to > precomputing (q-1) doublings. >=20 > Another thought that occurred to me is that someone might get the idea > to use your fixed-base ladder with some other point. Couldn't this go > awry if that point were already "P + S" or similar? If so, a caution > somewhere in the paper on preconditions for the fixed point might be > advised. >=20 > Regards, > Pete Dettman >=20 >=20 > On 12/05/2017 7:14 AM, Francisco Rodriguez- Henriquez wrote: >> Dear CFRG community, >>=20 >> We would like to draw your attention to an improved version of our IACR >> pre-print 2017/264 now entitled: >>=20 >> "How to (pre-)compute a ladder" >>=20 >> In this revised version, we present an improved differential addition >> formula that uses pre-computation to match the computational cost of the >> classical Montgomery differential addition. >>=20 >> Accordingly, our estimates suggest that a full implementation of our >> pre-computable ladder proposal should outperform state-of-the-art >> software implementations of the X25519 and X448 functions by a 40% >> speedup when working in the fixed-point scenario. >>=20 >> We would be delighted to receive feedback (including sightings of typos) >> from the CFRG community. >>=20 >> With best regards, >>=20 >> Thomaz Oliveira, Julio L=F3pez, H=FCseyin Hisil and Francisco >> Rodr=EDguez-Henr=EDquez >>=20 >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >>=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Jun 23 14:19:12 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BCD129ADD for ; Fri, 23 Jun 2017 14:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVoojlhKMWmX for ; Fri, 23 Jun 2017 14:19:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7003B1294F8 for ; Fri, 23 Jun 2017 14:19:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DAA23300483 for ; Fri, 23 Jun 2017 17:19:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vLJkiOmDxzM5 for ; Fri, 23 Jun 2017 17:19:06 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DA78330029C for ; Fri, 23 Jun 2017 17:19:06 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <67210408-F27E-4AE9-9ED6-6777C70530DA@vigilsec.com> Date: Fri, 23 Jun 2017 17:19:06 -0400 To: cfrg@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cfrg] Review of draft-irtf-cfrg-argon2-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 21:19:11 -0000 Document: draft-irtf-cfrg-argon2-02 Reviewer: Russ Housley Review Date: 2017-06-23 Summary: Almost Ready Once the comments below are resolved, I think that the ISE should publish the document. Major Concerns: Section 3.3: The pseudo-code includes this line: V_{r+1} =3D H_{T-32*r}(V_{r}) Up to this point, I thought that the Argon2 construction could work with many different hash functions, but at this point I realized that Argon2 depends the ability of Blake2b to produce an output between 1 and 64 bytes. Please add a sentence or two to the introduction so that others can avoid this misunderstanding. Section 3.5: This section defines the compression function G. It makes use of the BLAKE2b round function P, which is explained in Section 3.6. Section 3.6 defines another function G, which is different than the=20 compression function. I realize that both G functions are discussed in other documents ([I-D.saarinen-blake2] and [ARGON2]), but there ought to be a way to avoid this name collision. Section 5: I tried to compile the code, and it does not work with gcc. Is there a missing include file? Minor Concerns: Section 2 defines "E_f" as a variable E with subscript index f; however, in Section 3.3, defines "H_x" as a hash function with x-byte output. Please use a different notation for variables and functions. Section 5: A main function would make it easier to use this reference code. Can you include something simple? Perhaps something that prints the tags associated with the test vectors in Section 6. Nits: Section 1: s/implementer oriented/implementer-oriented/ Section 1: s/data-depending memory access/data-dependent memory access/ Section 2: Please add a descriptions for the floor and ceil functions. Section 2: Please add a description for length(P), which always returns 32 bits. Section 2 defines "a ^ b", but Sections 3.2 and 3.5 use "a XOR b". Pick one. Most of the document uses "=3D" for assignment, but Section 3.6 uses = "<-". Please use "=3D" throughout. Several places, the document tells us that "integers are padded to 4 bytes and encoded in little endian". Maybe a "uint32" function should be specified to avoid repeating this phrase. Section 3.2: s/described in later section./described in later sections./ Section 6.3: Please correct the formatting. Section 9.1: s/calls to Blake2b is needed/calls to Blake2b are needed/ Section 9.2: s/number t of passes/the number of passes, t,/ Section 9.3: s/for Argon2i 3 passes/for Argon2i, 3 passes/ Section 9.3: s/for Argon2d and Argon2id 1 pass/for Argon2d and Argon2id, = 1 pass/ Personal preference: Section 3.5: s/applied rowwise, and then columnwise/ /applied to each row, and then to each column/ From nobody Fri Jun 23 14:28:26 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3B1293EE for ; Fri, 23 Jun 2017 14:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EATM9rFhdeWy for ; Fri, 23 Jun 2017 14:28:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8CF1294F8 for ; Fri, 23 Jun 2017 14:28:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E808300483 for ; Fri, 23 Jun 2017 17:28:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id akIkTMwjgP5j for ; Fri, 23 Jun 2017 17:28:21 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BDB6730029C for ; Fri, 23 Jun 2017 17:28:21 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 23 Jun 2017 17:28:21 -0400 References: <67210408-F27E-4AE9-9ED6-6777C70530DA@vigilsec.com> To: cfrg@ietf.org In-Reply-To: <67210408-F27E-4AE9-9ED6-6777C70530DA@vigilsec.com> Message-Id: <9A5C8193-4A8B-4461-81E3-4D0E1DAFC0CA@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Review of draft-irtf-cfrg-argon2-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 21:28:25 -0000 I meant to say: Once the comments below are resolved, I think that the IRSG should publish the document. Russ > On Jun 23, 2017, at 5:19 PM, Russ Housley = wrote: >=20 > Document: draft-irtf-cfrg-argon2-02 > Reviewer: Russ Housley > Review Date: 2017-06-23 >=20 > Summary: Almost Ready >=20 > Once the comments below are resolved, I think that the ISE should > publish the document. >=20 >=20 > Major Concerns: >=20 > Section 3.3: The pseudo-code includes this line: >=20 > V_{r+1} =3D H_{T-32*r}(V_{r}) >=20 > Up to this point, I thought that the Argon2 construction could work = with > many different hash functions, but at this point I realized that = Argon2 > depends the ability of Blake2b to produce an output between 1 and 64 > bytes. Please add a sentence or two to the introduction so that = others > can avoid this misunderstanding. >=20 > Section 3.5: This section defines the compression function G. It = makes > use of the BLAKE2b round function P, which is explained in Section = 3.6. > Section 3.6 defines another function G, which is different than the=20 > compression function. I realize that both G functions are discussed = in > other documents ([I-D.saarinen-blake2] and [ARGON2]), but there ought = to > be a way to avoid this name collision. >=20 > Section 5: I tried to compile the code, and it does not work with gcc. > Is there a missing include file? >=20 >=20 > Minor Concerns: >=20 >=20 > Section 2 defines "E_f" as a variable E with subscript index f; = however, > in Section 3.3, defines "H_x" as a hash function with x-byte output. > Please use a different notation for variables and functions. >=20 > Section 5: A main function would make it easier to use this reference > code. Can you include something simple? Perhaps something that = prints > the tags associated with the test vectors in Section 6. >=20 >=20 > Nits: >=20 > Section 1: s/implementer oriented/implementer-oriented/ >=20 > Section 1: s/data-depending memory access/data-dependent memory = access/ >=20 > Section 2: Please add a descriptions for the floor and ceil functions. >=20 > Section 2: Please add a description for length(P), which always = returns > 32 bits. >=20 > Section 2 defines "a ^ b", but Sections 3.2 and 3.5 use "a XOR b". > Pick one. >=20 > Most of the document uses "=3D" for assignment, but Section 3.6 uses = "<-". > Please use "=3D" throughout. >=20 > Several places, the document tells us that "integers are padded to 4 > bytes and encoded in little endian". Maybe a "uint32" function should > be specified to avoid repeating this phrase. >=20 > Section 3.2: s/described in later section./described in later = sections./ >=20 > Section 6.3: Please correct the formatting. >=20 > Section 9.1: s/calls to Blake2b is needed/calls to Blake2b are needed/ >=20 > Section 9.2: s/number t of passes/the number of passes, t,/ >=20 > Section 9.3: s/for Argon2i 3 passes/for Argon2i, 3 passes/ >=20 > Section 9.3: s/for Argon2d and Argon2id 1 pass/for Argon2d and = Argon2id, 1 pass/ >=20 >=20 > Personal preference: >=20 > Section 3.5: s/applied rowwise, and then columnwise/ > /applied to each row, and then to each column/ >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Jun 23 17:07:10 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7A129B07; Fri, 23 Jun 2017 17:06:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cfrg@ietf.org, irtf-chair@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826281743.7840.7770744022632147959.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:06:57 -0700 Archived-At: Subject: [Cfrg] cfrg - Requested session has been scheduled for IETF 99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:06:57 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cfrg Session 1 (1:30:00) Tuesday, Afternoon Session II 1550-1750 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: kitten tcpinc uta dispatch dprive tls saag dmarc Second Priority: jmap mile People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: Please generally avoid conflicts with SEC Area WGs/BOFs --------------------------------------------------------- From nobody Mon Jun 26 22:45:16 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1A12EB77; Mon, 26 Jun 2017 22:45:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149854231542.14930.11413879693117689362@ietfa.amsl.com> Date: Mon, 26 Jun 2017 22:45:15 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-07.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 05:45:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Hash-Based Signatures Authors : David McGrew Michael Curcio Scott Fluhrer Filename : draft-mcgrew-hash-sigs-07.txt Pages : 45 Date : 2017-06-21 Abstract: This note describes a digital signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and naturally resist side-channel attacks. Unlike most other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-mcgrew-hash-sigs-07 https://datatracker.ietf.org/doc/html/draft-mcgrew-hash-sigs-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mcgrew-hash-sigs-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 06:01:11 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC8129B0A; Tue, 27 Jun 2017 06:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmIj4_J3QSRN; Tue, 27 Jun 2017 06:01:06 -0700 (PDT) Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (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 77347129B08; Tue, 27 Jun 2017 06:01:06 -0700 (PDT) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dPq73-00014d-BM; Tue, 27 Jun 2017 15:01:01 +0200 Received: from [2001:610:310:9881:bca7:4406:6617:1339] by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1dPq73-0006pm-3E; Tue, 27 Jun 2017 15:01:01 +0200 From: "A. Huelsing" To: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> Message-ID: <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> Date: Tue, 27 Jun 2017 15:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Authenticated-Sender: ietf@huelsing.net X-Virus-Scanned: Clear (ClamAV 0.99.2/23511/Tue Jun 27 06:22:26 2017) Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:01:09 -0000 Hi Stephen, hi Kenny, hi Alexey, We are currently going through the review. While we didn't handle the nits yet, we made up our mind about the first four points (see below). Regarding the last point of test vectors. We think it is better to add a reference implementation. We would now just add the C code as appendix. Would that be fine? Are there any conditions on code? We have dependencies to OpenSSL for SHA2. >>>> possible errors: >>>> ---------------- >>>> >>>> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >>>> missing parenthesis around the "(w-1)" to me. Without those >>>> brackets I could interpret that test to always result in false. Added parenthesis. >>>> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >>>> as-is you seem to have incremented the index too soon so >>>> that when alg 11 does getIdx it'd presumably get the >>>> incremented index and cause verification failure. I think >>>> the same is true of alg 16 as well, in section 4.2.4. Indeed, we now give idx_sig as additional input (and don't use the already updated index from SK anymore). >>>> significant comments, but likely fixable: >>>> ----------------------------------------- >>>> >>>> - section 5: there are waaaay too many options defined here. >>>> As-is, this will damage potential deployment of xmss. I >>>> would strongly suggest deleting all of the options except the >>>> minimum, that being one (and only one) set of parameters for >>>> XMSS and one for XMSS^MT. If others are needed later, those >>>> can be defined later. (Note that the damage done here includes >>>> the hours of developer time that would be wasted debating >>>> which of these choices to implement/use. Consider the case of >>>> pre-hash variants of eddsa for an ongoing example.) Got your point Our noted todos are: #### # 1.) Select 1 XMSS & 1 XMSS^MT parameter set as default options # 2.) Explain that all other h / d combis are fine but we can only give limited number # 3.) Add sizes & #sigs for parameter sets # 4.) Explain trade-offs # 5.) Make implementation of verification for all parameters mandatory / sign just a para suggestion #### Do you agree? >>>> - section 5 (or an appendix) should contain some test vectors >>>> (including intermediate values). Without those, implementers >>>> have a much harder time of getting their code right. See above. Cheers, Stefan & Andreas >>>> nits, near-nits and other ignorable things: >>>> ------------------------------------------- >>>> >>>> - abstract: I'd suggest s/can withstand attacks/ can withstand >>>> so-far known attacks/ >>>> >>>> - 1.1: You say if used >1 time "no cryptographic security >>>> guarantees remain." It might be clearer to give some >>>> examples of consequences, e.g. that the attacker can forge new >>>> signatures or whatever. >>>> >>>> - 1.1: I think you might mention that XMSS and other OTS ideas >>>> require some new crypto APIs. I'm not aware if anyone has >>>> developed proposals for such, but would be interested if >>>> someone has. >>>> >>>> - 2.3, 2nd last para: you might want to say what happens with >>>> e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but >>>> someone might think it's 0x3c0 or even 0xc3. >>>> >>>> - 2.5: having the "type word" as octet 15 of a 32 byte address >>>> seems odd. Is there a reason why? (Just wondering.) >>>> >>>> - 2.6: It seems odd to given an example where the input and >>>> output of base_w() are the same. A different example may be >>>> more useful. (More examples generally would be great.) >>>> >>>> - 3.1.3: maybe note that "/" means nothing? Which I assume it >>>> does? Better might be to just say that. >>>> >>>> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >>>> units >>>> >>>> - 3.1.5: "the variable" - which one? >>>> >>>> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >>>> unsigned integer is sufficient." Sufficient for what? >>>> >>>> - 3.1.5: The ascii art at the end of p16 doesn't help much. >>>> >>>> - 3.1.7: The "MUST match" statement doesn't seem enforceable >>>> nor testable so I'm not sure it's a good idea to include. >>>> OTOH, I do get the idea of using 2119 terms for emphasis. >>>> >>>> - 3.1.7: I think it might be useful to point out any specific >>>> problems associated with using a low entropy human memorable >>>> secret (password) for the value S. No matter what you say, >>>> people will do that, so better if you can say you told them >>>> specifically about downsides of doing that. >>>> >>>> - 4.1.12: I'm not sure if the MAY there is correct or not. If >>>> it means "you MAY use a different algorithm to get the same >>>> output as alg 12" then that'd be fine. If something else is >>>> meant I'm not sure what you're saying, and it'd probably be >>>> better to not even mention it. >>>> >>>> - section 5 should also spell out the signature and >>>> public key sizes in bytes and ideally, if you keep multiple >>>> options, (but please don't:-) describe relative or measured >>>> timings. >>>> >>>> >>>> From nobody Tue Jun 27 06:20:51 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A566F129B07 for ; Tue, 27 Jun 2017 06:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yaYUuqlbINVl for ; Tue, 27 Jun 2017 06:20:46 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 340BB127078 for ; Tue, 27 Jun 2017 06:20:46 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id r62so24638531qkf.0 for ; Tue, 27 Jun 2017 06:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vuI5I6aFFntB2NAcSsV2kWMszJ3IoQzQEkQO+fXzQKM=; b=fXKConxkWGyi1v2nygD4SZ8RTIlNZnVn4AyGKwritlR4nMT48Lw66NhMpE39sd39kg jY6Jal1/WuLAwCj5bBbfo9CaOaHdhyu8WaYnS6ofsDkZxVJ6eLQgipZFiMMAqC0+SOXo idkuytRNLshkBNtgOoz9Wq24xVkUj4Z5Ml96R7X28vHUOeKNVnsOlwsWlqsqIFlV33Qj hsM/qYHgW8XruajICecT5eeUaQ0LVQxVGCFfB3DZkJgA3AU1/hzP1KYUaHz/fSv/Z0M3 gu6QwpsDRQpT9Nyk8KpXsFmPrCgwEo/eQz3kFhPCURGWs0aZqtRo1QSoCmmrM2ojSywW q+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vuI5I6aFFntB2NAcSsV2kWMszJ3IoQzQEkQO+fXzQKM=; b=It4zqlo9F1YueyMJNFG5BiaqlKJLi/kIGZUuAZr9EkFVtvXZiMceAMkXR2OhcIr9MK 9bSln6Ifw71R0VDyqO4gv3qGC+SD2NmGfnM4CyeMqXUzWqKOv6qaZpZnPlDeYm23CLV4 rs915gMP7SUm6yyH8dVYQt3igy69YE0EOhtB1FCS0O4ZTiPa2VpRR7eo6yf75dBQlDMG Eg9YNzBKklJZ722WhTkOztJ0GWknC/8AVkP/TjeFwJraNrU0bxqrLYVh8b8CxlYnmfUw hGNadXcqXuQ2bZA22d8YXxNRpwrk1uZgf4u6kYRa/upf63jQWaX/bD8UkFMS/qJ6vn6l LPkA== X-Gm-Message-State: AKS2vOwLFOgVUqkjgDs7h27EtaDzOTEyZ7cV75kHrWjJpyiIxZlCI9CR 5xB3XaTxVa1GZ9ByCm3oi8aGdfo8vuYq X-Received: by 10.55.191.197 with SMTP id p188mr6377359qkf.69.1498569645034; Tue, 27 Jun 2017 06:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.77 with HTTP; Tue, 27 Jun 2017 06:20:44 -0700 (PDT) In-Reply-To: <9A5C8193-4A8B-4461-81E3-4D0E1DAFC0CA@vigilsec.com> References: <67210408-F27E-4AE9-9ED6-6777C70530DA@vigilsec.com> <9A5C8193-4A8B-4461-81E3-4D0E1DAFC0CA@vigilsec.com> From: "Stanislav V. Smyshlyaev" Date: Tue, 27 Jun 2017 16:20:44 +0300 Message-ID: To: cfrg@ietf.org, "Paterson, Kenny" , "alexey.melnikov@isode.com" Cc: Russ Housley Content-Type: multipart/alternative; boundary="94eb2c04308e5d2cba0552f0ef48" Archived-At: Subject: Re: [Cfrg] Review of draft-irtf-cfrg-argon2-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:20:50 -0000 --94eb2c04308e5d2cba0552f0ef48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Document: draft-irtf-cfrg-argon2-02 Reviewer: Stanislav Smyshlyaev Review Date: 2017-06-27 Summary: Minor revision needed The draft defines a family of Argon2 functions, Argon2i, Argon2d and Argon2id, which are designed to be memory-hard functions for password hashing and PoW. The function design is reasonable and well-thought. The security analysis is deep enough - a number of adequate adversary models are considered (see https://www.cryptolux.org/images/0/0d/Argon2.pdf). Nevertheless, in my opinion, more words (not in the I-D but in the cited design reference) about comparison of results for Argon2 with most recent results for Balloon and sCrypt would be very helpful: for instance, considering the model and results in Eurocrypt 2017 best paper "Scrypt is Maximally Memory-Hard", or results in the pROM model. Are there any complete results (existing or planned for future research) in the pROM model? Also some (at least, formal) words should be said about security analysis of recommended Argon2id (I understand that results for Argon2i lead to corollaries for Argon2id - but it should be said explicitly, I think). Another major concern is the following: I'd prefer the number of variants to be reduced. Now there are 3 functions with several parameters. It is great that the Section 9.4 with recommendations to use Argon2id with t=3D1 and maximum available memory has been added in -02 version - but do we need the whole set of alternative options in the document? It seems to me that it is not a good idea to have a large set of parameterized functions standardized and I'd like it to be reduced in the future RFC - for example, by getting rid of Argon2i and Argon2d, leaving only Argon2id. Comments: 1) General comments about notation: - Section 2 defines =E2=80=9C^=E2=80=9D, but later "XOR=E2=80=9D is used in= the formulas below (sections 3.2, 3.5). Please select one notation, and if =E2=80=9CXOR=E2=80= =9D is chosen, then it makes sense to use =E2=80=9C^=E2=80=9D instead of =E2=80=9C**=E2=80= =9D. - It will be better to put spaces for arithmetic operations in a unified way. For example, put them before and after all binary operations (/, -, *, ^ (or XOR), =E2=80=A6) and do not put them in case of unary operations (= **). - "Kibibytes", "GiB" and "GB" are used. It would be better to select one measurement system. 2) Please use figure numbers and captions for the illustrations. 3) Notation in Section 2: - Symbol =E2=80=9Ca=E2=80=9D is used to denote integers and strings without= any comments. It will be good to clarify the type of the arguments for defined functions and operations. - The function extract(a, i) should be defined more clearly: e.g. which set is the 1-st one for a? - Such simple things as =E2=80=9C*=E2=80=9D, =E2=80=9C-=E2=80=9D, =E2=80=9C= /=E2=80=9D, =E2=80=9CI(j)=E2=80=9D are defined (do we really need it?) but there are no words about =E2=80=9C-P->=E2=80=9D, =E2=80=9C->= =E2=80=9D, =E2=80=9Cceil=E2=80=9D. In particular, on a first encounter one may read string =E2=80=9CG: (X, Y) -> R =3D X XOR = Y -P-> Q -P-> Z -P-> Z XOR R=E2=80=9D in an incorrect way. 4) Transformation rules (from int to str and back) are not always provided in the draft: in Section 3.4.1 J_1, J_2 deal with strings; in Section 3.4.2 J_1, J_2 deal with integers. Think about defining int() and str() functions to avoid repeating the same phrases. 5) Function H is BLAKE2b function, which takes 4 arguments as an input (d[0..dd-1], ll, kk, nn). But it takes 14 arguments in Section 3.2 and 1 argument in Section 3.3. Please, clarify it. 6) Section 3.2. The link [I-D.saarinen-blake2] is for a version of draft, but now there is RFC 7693. 7) Section 3.2. "Establish H_0 as the 64-bit value as shown in the figure below." The nearest figure is =E2=80=9CSingle-pass Argon2 with p lanes and 4 slices= =E2=80=9D - and H_0 is described in the formula (string) below. 8) Section 3.2. "G and H' are described in later section." The number of the section here would look better than just "later". 9) Section 3.3 specifies function H=E2=80=99 with one argument X, but H=E2= =80=99 uses 3 arguments in Section 3.3. (B[i][0] =3D H'(H_0, 0, i)). 10) Section 3.3: "in our case H_x is BLAKE2b, which supports x between 1 and 64 inclusive" It would be better to clarify that x is "nn" in terms of BLAKE2b. 11) - Section 3.3. "Here integers are padded to 4 bytes and encoded in little endian." The question "Padded with what?" can be raised. Maybe it will be better just to say =E2=80=9Cencoded in little-endian as 4-byte integer=E2=80=9D . - Section 3.3. "little-endian as 32-bit integer". "4 bytes" instead of "32 bits" looks better to me here. 12) Section 3.3. "The block indices i' and j' are determined differently for Argon2d, Argon2i, and Argon2id." Please, insert the link to a section that determines this. 13) In Section 3.4.2 and Section 3.5 =E2=80=9CR=E2=80=9D is used for differ= ent purposes 14) In Section 3.4.1.2 and Section 3.4.2 =E2=80=9Cx=E2=80=9D is used for di= fferent purposes 15) Notation looks too cumbersome for an RFC. For some readers it can be hard to understand the meaning of the string =E2=80=9CJ_1 in [0, 2**32) -> = |R|(1 - J_1**2 / 2**64)=E2=80=9D. 16) Section 3.5. Maybe it would be better to use =E2=80=9Cv=E2=80=9D instea= d of "\ /". 17) Section 6.3. Extra spaces in the first string. 18) Lines =E2=80=9CPassword[32]:=E2=80=A6=E2=80=9D, =E2=80=9CPre-hashing di= gest=E2=80=A6", ", "Tag: 0d 64 0d f5 =E2=80=A6" go off the edge of the page. 19) Section 3.5. G: (X, Y) -> R =3D X XOR Y -P-> Q -P-> Z -P-> Z XOR R Is the third =E2=80=9C-P->=E2=80=9D needed here? However, the document is very important and, in my opinion, it should be published after resolving the comments. Of course I'll be happy to discuss the mentioned concerns with the authors. Best regards, Stanislav 2017-06-24 0:28 GMT+03:00 Russ Housley : > I meant to say: > > Once the comments below are resolved, I think that the IRSG should > publish the document. > > Russ > > > > > On Jun 23, 2017, at 5:19 PM, Russ Housley wrote: > > > > Document: draft-irtf-cfrg-argon2-02 > > Reviewer: Russ Housley > > Review Date: 2017-06-23 > > > > Summary: Almost Ready > > > > Once the comments below are resolved, I think that the ISE should > > publish the document. > > > > > > Major Concerns: > > > > Section 3.3: The pseudo-code includes this line: > > > > V_{r+1} =3D H_{T-32*r}(V_{r}) > > > > Up to this point, I thought that the Argon2 construction could work wit= h > > many different hash functions, but at this point I realized that Argon2 > > depends the ability of Blake2b to produce an output between 1 and 64 > > bytes. Please add a sentence or two to the introduction so that others > > can avoid this misunderstanding. > > > > Section 3.5: This section defines the compression function G. It makes > > use of the BLAKE2b round function P, which is explained in Section 3.6. > > Section 3.6 defines another function G, which is different than the > > compression function. I realize that both G functions are discussed in > > other documents ([I-D.saarinen-blake2] and [ARGON2]), but there ought t= o > > be a way to avoid this name collision. > > > > Section 5: I tried to compile the code, and it does not work with gcc. > > Is there a missing include file? > > > > > > Minor Concerns: > > > > > > Section 2 defines "E_f" as a variable E with subscript index f; however= , > > in Section 3.3, defines "H_x" as a hash function with x-byte output. > > Please use a different notation for variables and functions. > > > > Section 5: A main function would make it easier to use this reference > > code. Can you include something simple? Perhaps something that prints > > the tags associated with the test vectors in Section 6. > > > > > > Nits: > > > > Section 1: s/implementer oriented/implementer-oriented/ > > > > Section 1: s/data-depending memory access/data-dependent memory access/ > > > > Section 2: Please add a descriptions for the floor and ceil functions. > > > > Section 2: Please add a description for length(P), which always returns > > 32 bits. > > > > Section 2 defines "a ^ b", but Sections 3.2 and 3.5 use "a XOR b". > > Pick one. > > > > Most of the document uses "=3D" for assignment, but Section 3.6 uses "<= -". > > Please use "=3D" throughout. > > > > Several places, the document tells us that "integers are padded to 4 > > bytes and encoded in little endian". Maybe a "uint32" function should > > be specified to avoid repeating this phrase. > > > > Section 3.2: s/described in later section./described in later sections.= / > > > > Section 6.3: Please correct the formatting. > > > > Section 9.1: s/calls to Blake2b is needed/calls to Blake2b are needed/ > > > > Section 9.2: s/number t of passes/the number of passes, t,/ > > > > Section 9.3: s/for Argon2i 3 passes/for Argon2i, 3 passes/ > > > > Section 9.3: s/for Argon2d and Argon2id 1 pass/for Argon2d and Argon2id= , > 1 pass/ > > > > > > Personal preference: > > > > Section 3.5: s/applied rowwise, and then columnwise/ > > /applied to each row, and then to each column/ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c04308e5d2cba0552f0ef48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Do= cument: draft-irtf-cfrg-argon2-02
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-06= -27

<= br>

Summary: Minor revision needed


The draft defines a famil= y of Argon2 functions, Argon2i, Argon2d and Argon2id, which are designed to= be memory-hard functions for password hashing and PoW.


The function design is reasonable and= =C2=A0well-thought. The security analysis is deep enough - a number of adeq= uate adversary models are considered (see https://www.cryptolux.org/images/0/0d/Argon2.pd= f).=C2=A0


Neve= rtheless, in my opinion, more words (not in the I-D but in the cited design= reference) about comparison of results for Argon2 with most recent results= for Balloon and sCrypt would be very helpful: for instance, considering th= e model and results in Eurocrypt 2017 best paper "Scrypt is Maximally = Memory-Hard", or results in the pROM model. Are there any complete res= ults (existing or planned for future research) in the pROM model?=C2=A0

=


Also some (at least, = formal) words should be said about security analysis of recommended Argon2i= d (I understand that results for Argon2i lead to corollaries for Argon2id -= but it should be said explicitly, I think).


=

Another major concern is the following: I'd = prefer the number of variants to be reduced.=C2=A0

Now there are 3 functions with several parameters. It is great that the S= ection 9.4 with recommendations to use Argon2id with t=3D1 and maximum avai= lable memory has been added in -02 version - but do we need the whole set o= f alternative options in the document?=C2=A0

It s= eems to me that it is not a good idea to have a large set of parameterized = functions standardized and I'd like it to be reduced in the future RFC = - for example, by getting rid of Argon2i and Argon2d, leaving only Argon2id= .


Comments:

1)=C2=A0Genera= l comments about notation:=C2=A0

<= p class=3D"MsoNormal">- Section 2 defines =E2=80=9C^=E2=80=9D, but later &q= uot;XOR=E2=80=9D is used in the formulas below (sections 3.2, 3.5). Please = select one notation, and if =E2=80=9CXOR=E2=80=9D is chosen, then it makes = sense to use =E2=80=9C^=E2=80=9D instead of =E2=80=9C**=E2=80=9D.

- It will be better to put spaces for arithmetic operation= s in a unified way. For example, put them before and after all binary opera= tions =C2=A0(/, -, *, ^ (or XOR), =E2=80=A6) and do not put them in case of= unary operations (**).

- "Kibibytes", = "GiB" and "GB" are used. It would be better to select o= ne measurement system.

2) Please use figure numbe= rs and captions for the illustrations.

3) Notatio= n in Section 2:

- Symbol =E2=80=9Ca=E2=80=9D is u= sed to denote integers and strings without any comments. It will be good to= clarify the type of the arguments for defined functions and operations.=C2= =A0

-=C2=A0T= he=C2=A0function extract(a, i) should be defined more clearly: e.g. = which set is the 1-st one for a?

- Such simple th= ings as =E2=80=9C*=E2=80=9D, =E2=80=9C-=E2=80=9D, =E2=80=9C/=E2=80=9D, =E2= =80=9CI(j)=E2=80=9D are defined (do we really need it?) but there are no wo= rds about =E2=80=9C-P->=E2=80=9D, =E2=80=9C->=E2=80=9D, =E2=80=9Cceil= =E2=80=9D. In particular, on a first encounter one may read string =E2=80= =9CG: (X, Y) -> R =3D X XOR Y -P-> Q -P-> Z -P-> Z XOR R=E2=80= =9D in an incorrect way.=C2=A0

4) Transformation rules (from int to str and back) are not always = provided in the draft: in Section 3.4.1 J_1, J_2 deal with strings; in Sect= ion 3.4.2 J_1, J_2 deal with integers.=C2=A0

Thin= k about defining int() and str() functions to avoid repeating the same phra= ses.=C2=A0

5) Function H is BLAKE2b function, whi= ch takes 4 arguments as an input (d[0..dd-1], ll, kk, nn). But it takes 14 = arguments in Section 3.2 and 1 argument in Section 3.3. Please, clarify it.=

6) Section 3.2.=C2=A0 The link [I-D.saarinen-bla= ke2] is for a version of draft, but now there is RFC 7693.

7) Section 3.2. "Establish H_0 as the 64-bit value as shown = in the figure below."

The nearest figure is = =E2=80=9CSingle-pass Argon2 with p lanes and 4 slices=E2=80=9D - and H_0 is= described in the formula (string) below.=C2=A0

8= ) Section 3.2. "G and H' are described in later section."

=

The number of the section here would look better tha= n just "later".

9) Section 3.3 specifie= s function H=E2=80=99 with one argument X, but H=E2=80=99 uses 3 arguments = in Section 3.3. (B[i][0] =3D H'(H_0, 0, i)).=C2=A0

10) Section 3.3: "in our case H_x is BLAKE2b, which supports x b= etween 1 and 64 inclusive"

It would be bette= r to clarify that x is "nn" in terms of BLAKE2b.=C2=A0

11)=C2=A0

- Section 3.3. "He= re integers are padded to 4 bytes and encoded in little endian."

The question "Padded with what?" can be rais= ed. Maybe it will be better just to say =E2=80=9Cencoded in little-endian a= s 4-byte integer=E2=80=9D .

- Section 3.3. "= little-endian as 32-bit integer". "4 bytes" instead of "= ;32 bits" looks better to me here.

12) S= ection 3.3. "The block indices i' and j' are determined differ= ently for Argon2d, Argon2i, and Argon2id."

P= lease, insert the link to a section that determines this.

13)=C2=A0In=C2=A0Secti= on 3.4.2 and Section 3.5 =E2=80=9CR=E2=80=9D is used for different purposes=

14)=C2=A0In= =C2=A0Section 3.4.1.2 and Section 3.4.2 =E2=80=9Cx=E2=80=9D is used = for different purposes

15)=C2=A0Notation looks too cumbersome for an RFC.=C2=A0F= or some readers it can be hard to understand the meaning of the string =E2= =80=9CJ_1 in [0, 2**32) -> |R|(1 - J_1**2 / 2**64)=E2=80=9D.

16)=C2=A0Section= 3.5. Maybe it would be better to use =E2=80=9Cv=E2=80=9D instead of "= \ /".

17)=C2=A0Section 6.3. Extra spaces in the first string.

18)=C2=A0Lines = =E2=80=9CPassword[32]:=E2=80=A6=E2=80=9D, =E2=80=9CPre-hashing digest=E2=80= =A6", ", "Tag: 0d 64 0d f5 =E2=80=A6" go off the edge o= f the page.

19) Section 3.5. G: (X, Y) -> R = =3D X XOR Y -P-> Q -P-> Z -P-> Z XOR R

I= s the third =E2=80=9C-P->=E2=80=9D needed here?



However, th= e document is very important and, in my opinion, it should be published aft= er resolving the comments.


Of course I'll be=C2=A0happy=C2=A0to discuss the mentioned concerns with the aut= hors.


<= p>Best regards,

Stanislav



2017-06-24 0:28 GMT+03:00 Russ Housley <= housley@vigilsec.com>:
I me= ant to say:

Once the comments below are resolved, I think that the IRSG should
publish the document.

Russ



> On Jun 23, 2017, at 5:19 PM, Russ Housley <housley@vigilsec.com> wrote:
>
> Document: draft-irtf-cfrg-argon2-02
> Reviewer: Russ Housley
> Review Date: 2017-06-23
>
> Summary: Almost Ready
>
> Once the comments below are resolved, I think that the ISE should
> publish the document.
>
>
> Major Concerns:
>
> Section 3.3: The pseudo-code includes this line:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0V_{r+1} =3D H_{T= -32*r}(V_{r})
>
> Up to this point, I thought that the Argon2 construction could work wi= th
> many different hash functions, but at this point I realized that Argon= 2
> depends the ability of Blake2b to produce an output between 1 and 64 > bytes.=C2=A0 Please add a sentence or two to the introduction so that = others
> can avoid this misunderstanding.
>
> Section 3.5: This section defines the compression function G.=C2=A0 It= makes
> use of the BLAKE2b round function P, which is explained in Section 3.6= .
> Section 3.6 defines another function G, which is different than the > compression function.=C2=A0 I realize that both G functions are discus= sed in
> other documents ([I-D.saarinen-blake2] and [ARGON2]), but there ought = to
> be a way to avoid this name collision.
>
> Section 5: I tried to compile the code, and it does not work with gcc.=
> Is there a missing include file?
>
>
> Minor Concerns:
>
>
> Section 2 defines "E_f" as a variable E with subscript index= f; however,
> in Section 3.3, defines "H_x" as a hash function with x-byte= output.
> Please use a different notation for variables and functions.
>
> Section 5: A main function would make it easier to use this reference<= br> > code.=C2=A0 Can you include something simple?=C2=A0 Perhaps something = that prints
> the tags associated with the test vectors in Section 6.
>
>
> Nits:
>
> Section 1: s/implementer oriented/implementer-oriented/
>
> Section 1: s/data-depending memory access/data-dependent memory access= /
>
> Section 2: Please add a descriptions for the floor and ceil functions.=
>
> Section 2: Please add a description for length(P), which always return= s
> 32 bits.
>
> Section 2 defines "a ^ b", but Sections 3.2 and 3.5 use &quo= t;a XOR b".
> Pick one.
>
> Most of the document uses "=3D" for assignment, but Section = 3.6 uses "<-".
> Please use "=3D" throughout.
>
> Several places, the document tells us that "integers are padded t= o 4
> bytes and encoded in little endian".=C2=A0 Maybe a "uint32&q= uot; function should
> be specified to avoid repeating this phrase.
>
> Section 3.2: s/described in later section./described in later sections= ./
>
> Section 6.3: Please correct the formatting.
>
> Section 9.1: s/calls to Blake2b is needed/calls to Blake2b are needed/=
>
> Section 9.2: s/number t of passes/the number of passes, t,/
>
> Section 9.3: s/for Argon2i 3 passes/for Argon2i, 3 passes/
>
> Section 9.3: s/for Argon2d and Argon2id 1 pass/for Argon2d and Argon2i= d, 1 pass/
>
>
> Personal preference:
>
> Section 3.5: s/applied rowwise, and then columnwise/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /applied to each row, = and then to each column/
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--94eb2c04308e5d2cba0552f0ef48-- From nobody Tue Jun 27 07:29:01 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA3129B49; Tue, 27 Jun 2017 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KKVx2_joXIrB; Tue, 27 Jun 2017 07:28:58 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 88063129B41; Tue, 27 Jun 2017 07:28:58 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id s66so17450814pfs.1; Tue, 27 Jun 2017 07:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HEtVr/8qiiw/9/LW0DMo+FHRBOrsg2ZPRnm09vhxgcI=; b=S9FUNYtZD/CpGLQ1l5babuEW05x4gUl+X9x52LaMEHrBo3+BsuCqH+i95BrgcP9HQ2 5nQ7BLXPElJ3LoT5IlUkwZIX6u8XshVEjVb4J7UStocDzWBVbHhYvRb88jGOL/9RuqgM YW63TmnuVn5xOaEmFJWIVRx0EaLUmrm4mVoIIvn0R+bJmbYyXKiLXt81LYIoF5pzF7PB NXM5FM5Hb9b1KD1hY6ySSqddAb0ADB8r/+Lb+OzjAZBAirAnV6ymO87UxBzM3oVqO+XQ RAG/gN5rCpi+DQFtnGYixRZ7xTlBM257QGABxAySjLfXVR9aI/HvL/jQBOxhEEOXBY2b zVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HEtVr/8qiiw/9/LW0DMo+FHRBOrsg2ZPRnm09vhxgcI=; b=dWXjUrKMgGEp0pLH5h7CMJd+lDDrKse2GAr+Oozf9xOxkWZeTr6I9DGrlJF6SsEKix lOzRcpx03XfKTQoj3rso35eFPN762hMTiSmeTbqAXwBx2/LOsCvM5tvilA4/9kskuWPI AVIprQQHOuOk5At3zmghocilwi7P3DtaTQ3dmF4l2xVI/QIeCRafveNz0uq7tyBQ3QMq lg8wE4pODD6FW3IddwcRJEn4AV4m7gzMsZsnbaF7fJHNmFpTj9MfNOSePSX0kWOb5E0B IOL+Si2aH2sMdtqAaOW4HIme8dfILlQaFhG0FQ3bFBLEoXYt+wdkf4EsztfnCYJNy/Mm nJjQ== X-Gm-Message-State: AKS2vOyxpGVNiATtIM/tNhNzTNUmRJtjAxxKi7gTRxoDOpuObhWMGofM mDo1bNoQgWjfjwXA99AXyDbRJPS2vA== X-Received: by 10.84.169.36 with SMTP id g33mr6067441plb.52.1498573738169; Tue, 27 Jun 2017 07:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.187.77 with HTTP; Tue, 27 Jun 2017 07:28:57 -0700 (PDT) In-Reply-To: <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> From: Watson Ladd Date: Tue, 27 Jun 2017 07:28:57 -0700 Message-ID: To: "A. Huelsing" Cc: Stephen Farrell , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" , "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 14:29:00 -0000 On Tue, Jun 27, 2017 at 6:01 AM, A. Huelsing wrote: > Hi Stephen, hi Kenny, hi Alexey, > > We are currently going through the review. While we didn't handle the nits yet, > we made up our mind about the first four points (see below). Regarding the last > point of test vectors. > We think it is better to add a reference implementation. We would now just add > the C code as appendix. Would that be fine? Are there any conditions on code? We > have dependencies to OpenSSL for SHA2. I would prefer just calls to sha256(unsigned char *out, unsigned char *in, size_t inlen). OpenSS's API is a mess. Sincerely, Watson From nobody Tue Jun 27 08:41:29 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD331200C1; Tue, 27 Jun 2017 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3X814mQRKbV; Tue, 27 Jun 2017 08:41:25 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC11200B9; Tue, 27 Jun 2017 08:41:24 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v5RFf09H045591; Tue, 27 Jun 2017 11:41:03 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Watson Ladd , "A. Huelsing" CC: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" , "cfrg@irtf.org" , "irsg@irtf.org" Thread-Topic: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 Thread-Index: AQHS6RrEaGRypUrjFEGVgLUVEN9hFaIsqIuAgAD+a4CAC1S7AIAAGJOA///REwA= Date: Tue, 27 Jun 2017 15:41:00 +0000 Message-ID: <56C14C05-5562-49AA-85C9-DF5B7593BFED@ll.mit.edu> References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.23.0.170610 x-originating-ip: [172.25.177.195] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3581408460_1427055620" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-27_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270252 Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:41:28 -0000 --B_3581408460_1427055620 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 6/27/17, 10:28, "Cfrg on behalf of Watson Ladd" wrote: > We think it is better to add a reference implementation. We would now just add > the C code as appendix. Would that be fine? Are there any conditions on code? We > have dependencies to OpenSSL for SHA2. I would prefer just calls to sha256(unsigned char *out, unsigned char *in, size_t inlen). OpenSS's API is a mess. I would prefer calls to sha-3-256. SHA-2 is not a randomizer by design. --B_3581408460_1427055620 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgSPP7KEqDCgP9tiPL fmlnnK3tUNX0JocFFG4Xe82jzyUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNjI3MTU0MTAwWjANBgkqhkiG9w0BAQEFAASCAQAWdTG0uMHndnPDvmkY Ynw2FsulEeVZ2AxuWkUpcONk5DgLNwkjXky7L/p3v3O2TyBtwUOPIE7XEyyhmWCvoYOZwcjj dtmhARaVnUU0XFutKGCB3KDIYAC6RkCwXETwsWEaD33ryEbh/U+ebeEZhN7FU5gFVpx2Nx9U CfZBWfRSCTVtkt1Ah0Ih5kP51TlLx92OW2bajR1ipuoZblcXAhTOMQeOj9ZIRAA3WNGWUm9H e2ZivsadErYtiZglIdpqobjGcKVsVFVXHMveDzZpj0ZwfbI4QLYWZCXWeo3PdgcCLFlMW1NJ ZtdT0Md3OsvgmnhIyZSPXQkb1iVLSCT/hlrI --B_3581408460_1427055620-- From nobody Tue Jun 27 08:50:06 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58A8129ADF; Tue, 27 Jun 2017 08:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 prAIf3Mwr6y3; Tue, 27 Jun 2017 08:50:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C04128BA2; Tue, 27 Jun 2017 08:50:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89108BE55; Tue, 27 Jun 2017 16:49:59 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZFgyzyxa3VN; Tue, 27 Jun 2017 16:49:59 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F1108BE50; Tue, 27 Jun 2017 16:49:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498578599; bh=QodNXlmWZwD5Ae6Y2oshtDdWlJvmavhDSm7sYsH/c3s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MSKIavTz501j1dzGvTg02gpAUIx6KeLvayMH7e2KEUAAbzikjhItH3pi4sQ3Ruzcq FlzbZPhrmvkj5FULbGRXuCdM2tC34k/+2UksuZ6lznNYWtNJo5dLnc7v1HVMaWtflU qI6SgrjxFeV2TRua7NZ5hIa3TddZMSH0/l9uyrqw= To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> Date: Tue, 27 Jun 2017 16:49:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ueEfgrN5Q7W2NvIjnt9uDtnLDV4uRsdVS" Archived-At: Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:50:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ueEfgrN5Q7W2NvIjnt9uDtnLDV4uRsdVS Content-Type: multipart/mixed; boundary="aCMNwTqfopOUxHqtTKvVS9hnMLDOFsUxJ"; protected-headers="v1" From: Stephen Farrell To: "A. Huelsing" , "Paterson, Kenny" , Alexey Melnikov , "irsg@irtf.org" , "cfrg@irtf.org" Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" Message-ID: <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie> Subject: Re: [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08 References: <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> In-Reply-To: <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> --aCMNwTqfopOUxHqtTKvVS9hnMLDOFsUxJ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Andreas, On 27/06/17 14:01, A. Huelsing wrote: > Hi Stephen, hi Kenny, hi Alexey, >=20 > We are currently going through the review. While we didn't handle the n= its yet, > we made up our mind about the first four points (see below). Regarding = the last > point of test vectors. > We think it is better to add a reference implementation. We would now j= ust add > the C code as appendix. Would that be fine? Your call entirely IMO. An appendix is just fine, or a reference to a git repo could be as good, if test vectors aren't the right thing to do. > Are there any conditions on code? We > have dependencies to OpenSSL for SHA2. If you include code directly in the RFC, there's a license issue - it needs to be BSD basically and marked out as such (via "CODE_BEGINS" or some such, I forget the detail;-). If your current code doesn't use the BSD license, then it'll be easier to just add a URL referring to it somewhere. >=20 >>>>> possible errors: >>>>> ---------------- >>>>> >>>>> - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be >>>>> missing parenthesis around the "(w-1)" to me. Without those >>>>> brackets I could interpret that test to always result in false. > Added parenthesis. >>>>> - 4.1.9: should the call to setIdx in alg 12 be after treeSig? >>>>> as-is you seem to have incremented the index too soon so >>>>> that when alg 11 does getIdx it'd presumably get the >>>>> incremented index and cause verification failure. I think >>>>> the same is true of alg 16 as well, in section 4.2.4. > Indeed, we now give idx_sig as additional input (and don't use the alre= ady > updated index from SK anymore). Ok great - those were the only two changes that I think should have been blocking for publication. All the rest is just my opinion that you (and/or the RG chairs) should take into account however you see fit. >>>>> significant comments, but likely fixable: >>>>> ----------------------------------------- >>>>> >>>>> - section 5: there are waaaay too many options defined here. >>>>> As-is, this will damage potential deployment of xmss. I >>>>> would strongly suggest deleting all of the options except the >>>>> minimum, that being one (and only one) set of parameters for >>>>> XMSS and one for XMSS^MT. If others are needed later, those >>>>> can be defined later. (Note that the damage done here includes >>>>> the hours of developer time that would be wasted debating >>>>> which of these choices to implement/use. Consider the case of >>>>> pre-hash variants of eddsa for an ongoing example.) > Got your point Our noted todos are: > #### > # 1.) Select 1 XMSS & 1 XMSS^MT parameter set as default options > # 2.) Explain that all other h / d combis are fine but we can only gi= ve > limited number > # 3.) Add sizes & #sigs for parameter sets > # 4.) Explain trade-offs > # 5.) Make implementation of verification for all parameters mandator= y / sign > just a para suggestion > #### > Do you agree? I think those would be fine improvements yes. Cheers and thanks for considering the review, S. >>>>> - section 5 (or an appendix) should contain some test vectors >>>>> (including intermediate values). Without those, implementers >>>>> have a much harder time of getting their code right. > See above. >=20 > Cheers, >=20 > Stefan & Andreas >>>>> nits, near-nits and other ignorable things: >>>>> ------------------------------------------- >>>>> >>>>> - abstract: I'd suggest s/can withstand attacks/ can withstand >>>>> so-far known attacks/ >>>>> >>>>> - 1.1: You say if used >1 time "no cryptographic security >>>>> guarantees remain." It might be clearer to give some >>>>> examples of consequences, e.g. that the attacker can forge new >>>>> signatures or whatever. >>>>> >>>>> - 1.1: I think you might mention that XMSS and other OTS ideas >>>>> require some new crypto APIs. I'm not aware if anyone has >>>>> developed proposals for such, but would be interested if >>>>> someone has. >>>>> >>>>> - 2.3, 2nd last para: you might want to say what happens with >>>>> e.g. B<<2 where B=3D0xf0. I assume the result is 0xc0 but >>>>> someone might think it's 0x3c0 or even 0xc3. >>>>> >>>>> - 2.5: having the "type word" as octet 15 of a 32 byte address >>>>> seems odd. Is there a reason why? (Just wondering.) >>>>> >>>>> - 2.6: It seems odd to given an example where the input and >>>>> output of base_w() are the same. A different example may be >>>>> more useful. (More examples generally would be great.) >>>>> >>>>> - 3.1.3: maybe note that "/" means nothing? Which I assume it >>>>> does? Better might be to just say that. >>>>> >>>>> - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing >>>>> units >>>>> >>>>> - 3.1.5: "the variable" - which one? >>>>> >>>>> - 3.1.5: "For the parameter sets given in Section 5 a 32-bit >>>>> unsigned integer is sufficient." Sufficient for what? >>>>> >>>>> - 3.1.5: The ascii art at the end of p16 doesn't help much. >>>>> >>>>> - 3.1.7: The "MUST match" statement doesn't seem enforceable >>>>> nor testable so I'm not sure it's a good idea to include. >>>>> OTOH, I do get the idea of using 2119 terms for emphasis. >>>>> >>>>> - 3.1.7: I think it might be useful to point out any specific >>>>> problems associated with using a low entropy human memorable >>>>> secret (password) for the value S. No matter what you say, >>>>> people will do that, so better if you can say you told them >>>>> specifically about downsides of doing that. >>>>> >>>>> - 4.1.12: I'm not sure if the MAY there is correct or not. If >>>>> it means "you MAY use a different algorithm to get the same >>>>> output as alg 12" then that'd be fine. If something else is >>>>> meant I'm not sure what you're saying, and it'd probably be >>>>> better to not even mention it. >>>>> >>>>> - section 5 should also spell out the signature and >>>>> public key sizes in bytes and ideally, if you keep multiple >>>>> options, (but please don't:-) describe relative or measured >>>>> timings. >>>>> >>>>> >>>>> >=20 >=20 --aCMNwTqfopOUxHqtTKvVS9hnMLDOFsUxJ-- --ueEfgrN5Q7W2NvIjnt9uDtnLDV4uRsdVS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZUn6lAAoJEC88hzaAX42i8PoIAJAgKSX+hj/VfuLQczzTqSBh s1qVaPo9Lne3UixcMZYg6hrhbiDrG6zXBj3UyFBcg81y3b/1zu5HuNiPZPyVE7Zp Ig+/Zj3X7g1KJC6D+ved7wJ8WHXE+tLbbFGQdcDdqntKXbWvPxZlGDRqGYkhWiyx EnVOjqL9qnoqJZREqvPF8bYLuDEO5HZqBkEyoOCwytinXAEmh51lgMoQyNZgks5k Are3c7DHSKtPIQ9HDufUfyxZ1h1R+Si/XyQgaHcSv2dIv8BCnF1AddUxwWz0WM/E 6i3YQ9wIh68t1ob5S+CbexPp4XryWbN3Cg+OLYwfcErj35sMZ7fDojtcD8e3oFU= =qzds -----END PGP SIGNATURE----- --ueEfgrN5Q7W2NvIjnt9uDtnLDV4uRsdVS-- From nobody Tue Jun 27 13:44:33 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3368E12EAE9 for ; Tue, 27 Jun 2017 13:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozhe4oiwRrrL for ; Tue, 27 Jun 2017 13:44:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD1612EB2D for ; Tue, 27 Jun 2017 13:44:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0FA75300463 for ; Tue, 27 Jun 2017 16:44:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eg-PIlCj6Sge for ; Tue, 27 Jun 2017 16:44:25 -0400 (EDT) Received: from [5.5.33.139] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 956A030043A for ; Tue, 27 Jun 2017 16:44:25 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Jun 2017 16:44:25 -0400 References: <149854231542.14930.11413879693117689362@ietfa.amsl.com> To: cfrg@ietf.org In-Reply-To: <149854231542.14930.11413879693117689362@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-07.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:44:31 -0000 Thanks for posting the updated draft. As you know, I have a document = that depends on it. I did a quick read, and I have a few comments. All of them are = editorial. Section 1, last paragraph: s/public formats/signature and public key = formats/ Section 2: please correct the indenting of the middle paragraphs. Section 3.2: s/bytes 20, 21/bytes 20-21/ Russ > On Jun 27, 2017, at 1:45 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Crypto Forum of the IETF. >=20 > Title : Hash-Based Signatures > Authors : David McGrew > Michael Curcio > Scott Fluhrer > Filename : draft-mcgrew-hash-sigs-07.txt > Pages : 45 > Date : 2017-06-21 >=20 > Abstract: > This note describes a digital signature system based on = cryptographic > hash functions, following the seminal work in this area of Lamport, > Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in > 1995. It specifies a one-time signature scheme and a general > signature scheme. These systems provide asymmetric authentication > without using large integer mathematics and can achieve a high > security level. They are suitable for compact implementations, are > relatively simple to implement, and naturally resist side-channel > attacks. Unlike most other signature systems, hash-based signatures > would still be secure even if it proves feasible for an attacker to > build a quantum computer. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-mcgrew-hash-sigs-07 > https://datatracker.ietf.org/doc/html/draft-mcgrew-hash-sigs-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-hash-sigs-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Jun 30 08:20:58 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DAD129AFE; Fri, 30 Jun 2017 08:20:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883604895.4622.9519418011195110864@ietfa.amsl.com> Date: Fri, 30 Jun 2017 08:20:48 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-04.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 15:20:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-04.txt Pages : 47 Date : 2017-06-30 Abstract: A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called "key lifetime". This specification describes a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms based on hash functions and on block ciphers, that can be used with modes of operations such as CTR, GCM, CCM, CBC, CFB, OFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-04 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/