From nobody Mon Oct 2 09:42:04 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 32B2713234B for ; Mon, 2 Oct 2017 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 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, 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 aYT4IUGfgbkX for ; Mon, 2 Oct 2017 09:41:58 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30079.outbound.protection.outlook.com [40.107.3.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAC0133052 for ; Mon, 2 Oct 2017 09:41:57 -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=ycRLd1w26PMtXXkvG4YYqa81ahDknInHNNUAfRjQJ74=; b=ST0qiWX5xWJgtCS8iBkHU5Wk+eAjzz6eFa/Hns/+/fnSBq+pXOVSgfwETqwDFKbiIzE1f1P1dGWBQpvAscyAug8hp3IyyqJP5tgAsB4zNcWmC/qiDe2HJ/B8yiuJvfT9ZaIeD3ShM8B1I7ITovamyBbcljUdreZfr0QaTNd+DEQ= 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_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 16:41:54 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a90a:8fa5:3111:efe]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a90a:8fa5:3111:efe%13]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 16:41:53 +0000 From: "Paterson, Kenny" To: Stefano Tessaro , "cfrg@irtf.org" CC: Priyanka Bose , Viet Tung Hoang Thread-Topic: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06 Thread-Index: AQHTLv48nHq8en1/7kuyRQJV92Vw1qLNiuCAgANjBoA= Date: Mon, 2 Oct 2017 16:41:53 +0000 Message-ID: References: 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: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 6:FZTJuK9H49WzijSUqrXExeZ+iRoAv8yfuKKi6kHZ6njLcxwrrO7mcrnqqCA30H+OIcfx8sUsgeekAOPkf9rr6yL/fxUz7dsql71vF3kLIuRcrkZFkPufRc/vvRkAaZqD51FDjJKSiehnMSHOdf8+0tWFiQNqSwi3NmUURrHKXI/gbq0LOd15UzxqXn4xhHsoratvJ5xmwSTDrsarBcQOkd5qTS/alQZ+VYdcGMfKgZR0cxBtqmavPbqcc3vacroiljB4DCRDD9UqOpPGhfgYfBjC1Dp/spDgzuVFs4J8qjRgnbW1RerI605Jpr8uEvp/HS/h/EoKzbrdPUyOZs+ViQ==; 5:bNWi7OJUE/sIymnsrOZ7CbrnEPj/jiKjF7UTOhPWXCu+ALJUKjXDjQZycsAduibMh+J/2ho6KsRNS3GFywgFKWr40gUMC+8Dj6OYu/00Vd6EUz/+KpDeNfFmaAzMPW55mePkdSNcNStavbwd75vGMA==; 24:ArgFnGIAf/oe0AI219FW2TWkOPVYcqbkCiwltIolkAppl8+d+7ZPNkL74qm1ECBBCxxzT5hd4tV1ct9OT+LGNCcSx03y2VmFZll8zlQ2WLI=; 7:i1AHilU3n9wmeoC7cP7QESR4jTI+6I6CM22zrRV5/VBddBYLJCPlzbUNIEHgN8FM8YPxvoDtdxqMzhwMvioU1MkcM9Gzb7RcTOXtGAbvw3uLiEh4riIK1K7KweniIrJu8qoCib0xiCdFi0dizoaAybS5oY9wpHww+ADNlegM98bq6xJqvhoiAAjSUoWa7M/XlyvRDRjoO0LC2H+CB2+qdS8EHZ/s2tz64gUBhf0S3r4= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(377454003)(24454002)(199003)(189002)(110136005)(6116002)(3846002)(229853002)(50986999)(2900100001)(966005)(83506001)(189998001)(102836003)(5660300001)(25786009)(81166006)(81156014)(105586002)(305945005)(478600001)(7736002)(8676002)(413944005)(72206003)(101416001)(561944003)(86362001)(8936002)(2501003)(5250100002)(6486002)(66066001)(6512007)(53546010)(786003)(54906003)(2906002)(97736004)(106356001)(54356999)(316002)(76176999)(58126008)(6506006)(6436002)(74482002)(68736007)(3280700002)(3660700001)(53936002)(36756003)(230783001)(4326008)(6306002)(14454004)(42882006)(8666007)(6246003)(2950100002)(2171002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 189af7cf-5904-4977-2a10-08d509b47cdf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-exchange-antispam-report-test: UriScan:(192374486261705)(148717330147763); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(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: 0448A97BF2 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) 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: 02 Oct 2017 16:41:53.5931 (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: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06 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, 02 Oct 2017 16:42:03 -0000 RGVhciBTdGVmYW5vLCBQcml5YW5rYSBhbmQgVmlldCwNCg0KVGhhbmtzIGZvciBicmluZ2luZyB0 aGlzIG5ldyByZXNlYXJjaCB0byB0aGUgbGlzdC4gV2UgKHRoZSBjaGFpcnMpIHJlYWxseQ0Kd2Vs Y29tZSB5b3VyIHdvcmssIGFuZCBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHRoZSBkcmFm dCdzIGF1dGhvcnMgb24NCmhvdyB0aGV5IHdvdWxkIHZpZXcgdGhlIHByb3Bvc2VkIGNoYW5nZSB0 byB0aGUgZHJhZnQgdGhhdCBpcyBpbXBsaWNpdCBpbg0KeW91ciBtZXNzYWdlLiBUaGVyZSBpcyBu byBwcm9ibGVtIGZvciB1cyB0byBleHRlbmQgdGhlIGR1cmF0aW9uIG9mDQpvbi1nb2luZyAibGFz dCBjYWxsIiBmb3IgdGhlIGRyYWZ0IGluIG9yZGVyIHRvIGRpc2N1c3MgaXQgaW4gZGV0YWlsLg0K DQpBdCB0aGUgc2FtZSB0aW1lLCB3ZSB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIHB1dCB0aGUgZGV0 YWlscyBvZiB5b3VyDQphbmFseXNpcyBpbiB0aGUgcHVibGljIGRvbWFpbiBhcyBzb29uIGFzIHlv dSBoYXZlIGl0IHJlYWR5LCBzbyB0aGF0DQpldmVyeW9uZSBjYW4gc3RhcnQgdG8gbG9vayBhdCB0 aGUgZmluZSBkZXRhaWwuDQoNCkJlc3Qgd2lzaGVzLA0KDQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMp DQoNCk9uIDMwLzA5LzIwMTcgMTU6MDAsICJDZnJnIG9uIGJlaGFsZiBvZiBTdGVmYW5vIFRlc3Nh cm8iDQo8Y2ZyZy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiB0ZXNzYXJvQGNzLnVjc2Iu ZWR1PiB3cm90ZToNCg0KPkRlYXIgQ0ZSRzoNCj4NCj5XZSB3YW50ZWQgdG8gYnJpbmcgdG8geW91 ciBhdHRlbnRpb24gYSBwb3RlbnRpYWwgb3B0aW1pemF0aW9uIG9mIHRoZQ0KPmtleS1kZXJpdmF0 aW9uIHN0ZXAgaW4gQUVTLUdDTS1TSVYgdGhhdCBoYXMgY29tZSBvdXQgb2Ygc29tZSBvZiBvdXIN Cj5yZWxhdGVkIHJlc2VhcmNoIHdvcmsuIFNvcnJ5IHRoaXMgY29tZXMgc29tZXdoYXQgbGF0ZTog V2UgYXJlIGluIHRoZQ0KPnByb2Nlc3Mgb2YgZmluYWxpemluZyBhIGNsZWFuIHdyaXRlIHVwLCBi dXQgZHVlIHRvIHRpbWUgc2Vuc2l0aXZpdHksDQo+d2Ugd2FudGVkIHRvIG1ha2UgdGhlIENGUkcg bGlzdCBhd2FyZSBvZiB0aGlzIHJlbGF0ZWQgd29yay4NCj4NCj5DdXJyZW50bHksIHRoZSBrZXkt ZGVyaXZhdGlvbiBmdW5jdGlvbiBEZXJpdmVLZXkgb2YgQUVTLUdDTS1TSVYgdXNlcw0KPjQtNiBB RVMgY2FsbHMgKDQgdG8gZ2VuZXJhdGUgYSAyNTYtYml0IGtleSwgYW5kIDYgdG8gZ2VuZXJhdGUg YQ0KPjM4NC1iaXQga2V5KS4gVGhlIG92ZXJoZWFkIG9mIGtleSBkZXJpdmF0aW9uIG92ZXIgcGxh aW4gR0NNLVNJViBjYW4gYmUNCj51cCB0byAxMCUgZm9yIG1lc3NhZ2VzIHVuZGVyIDFLQiAoYWNj b3JkaW5nIHRvIHRoZSBhdXRob3Jz4oCZDQo+YmVuY2htYXJrcykuIE91ciBmaW5kaW5ncyBzdWdn ZXN0IGEgc2ltcGxlIG9wdGltaXphdGlvbiB0aGF0IGhhbHZlcw0KPnRoZSBudW1iZXIgb2YgY2Fs bHMuDQo+DQo+Q29uY3JldGVseTogU3VwcG9zZSB0aGF0IHdlIGhhdmUgYSBtYXN0ZXIga2V5IEsg YW5kIGEgOTYtYml0IG5vbmNlIE4uDQo+SWYgd2Ugd2FudCB0byBwcm9kdWNlIGEgMjU2LWJpdCBr ZXksIERlcml2ZUtleShLLE4pIHdpbGwgb3V0cHV0DQo+DQo+QUVTX0socGFkKE4sIDApKSB8fCBB RVNfSyhwYWQoTiwgMSkpLA0KPg0KPndoZXJlYXMgaWYgd2Ugd2FudCB0byBwcm9kdWNlIGEgMzg0 LWJpdCBrZXksIHdlIHdpbGwgaW5zdGVhZCBvdXRwdXQNCj4NCj5BRVNfSyhwYWQoTiwgMCkpIHx8 IEFFU19LKHBhZChOLCAxKSkgfHwgQUVTX0socGFkKE4sIDIpKS4NCj4NCj5IZXJlLCB3ZSBkZW1h bmQgdGhhdCBwYWQoTiwgMCksIHBhZChOLCAxKSwgcGFkKE4sIDIpIGlzIGRpZmZlcmVudCBmcm9t DQo+cGFkKE7igJksIDApLCBwYWQoTuKAmSwgMSksIHBhZChO4oCZLCAyKSwgYW5kIHRoYXQgcGFk KE4sIDApIGlzIG5vdCBhDQo+cG9zc2libGUgaW5wdXQgdG8gQUVTIHdpdGhpbiBDVFIgZW5jcnlw dGlvbi4gRHVlIHRvIHRoZSB3YXkgaW4gd2hpY2gNCj5BRVMtR0NNLVNJViBhbHJlYWR5IGFkb3B0 cyBkb21haW4gc2VwYXJhdGlvbiBlbHNld2hlcmUsIGl0IGlzIGVub3VnaA0KPnRvIGltcGxlbWVu dCBwYWQoTiwgaSkgYXMgdGhlIGNvbmNhdGVuYXRpb24gb2YgdGhlIDk2LWJpdCBub25jZSBOIGFu ZA0KPmEgMzItYml0IGNvdW50ZXIgb2YgdmFsdWUgaSwgYnV0IGhlcmUgbm90ZSB0aGF0IG9uZSBo YXMgdG8gc3dhcCB0aGUNCj5yZWxhdGl2ZSBvcmRlcmluZyBvZiBub25jZSBhbmQgY291bnRlciBp biB0aGUgY3VycmVudCBwcm9wb3NhbCwgbmFtZWx5DQo+dGhlIG5vbmNlIGNvbWVzIGZpcnN0LCBh bmQgdGhlbiB0aGUgY291bnRlci4NCj4NCj5UbyBzZWUgd2h5IHRoaXMgd291bGQgd29yaywgd2Ug bm90ZSB0aGF0IHRoZSBjdXJyZW50IERlcml2ZUtleQ0KPmZ1bmN0aW9uLCBhbmQgb3RoZXIgcHJv cG9zYWxzIGJ5IEl3YXRhIGFuZCBTZXVyaW4sIGFyZSByZXF1aXJlZCB0byBiZQ0KPmEgaGlnaGx5 LXNlY3VyZSBwc2V1ZG9yYW5kb20gZnVuY3Rpb24uIEludHVpdGl2ZWx5LCB0aGlzIGlzIGJlY2F1 c2UNCj50aGUgY3VycmVudCBhcHByb2FjaCB0byBwcm92ZSBzZWN1cml0eSBvZiBBRVMtR0NNLVNJ ViByZWR1Y2VzIChhcyBhbg0KPmludGVybWVkaWF0ZSBzdGVwKSB0byB0aGUgc2VjdXJpdHkgb2Yg R0NNLVNJViwgYW5kIGluIHR1cm4gb2YgQUVTLA0KPnVuZGVyIChtdWx0aXBsZSkgaW5kZXBlbmRl bnQgcmFuZG9tIGtleXMuIFRoaXMgaW5kZXBlbmRlbmNlIGlzIG5vdA0KPm5lY2Vzc2FyeSBpbiBn ZW5lcmFsLCBhbmQgc2VjdXJpdHkgcHJvb2ZzIGdvIHRocm91Z2ggZXZlbiB3aGVuIGtleQ0KPmRp c3RyaWJ1dGlvbnMgYXJlIG11Y2ggbW9yZSBzdHJ1Y3R1cmVkLCBzdWNoIGFzIHRoZSBvbmUgcHJv ZHVjZWQgYnkNCj5vdXIgc2ltcGxlIERlcml2ZUtleSBwcm9wb3NhbC4gKFRoaXMgY2FuIGJlIHZh bGlkYXRlZCBpbiB0aGUgc28tY2FsbGVkDQo+aWRlYWwgY2lwaGVyIG1vZGVsLCBhbmQgd2UgYXJl IG5vdCBhd2FyZSBvZiBhbnkgY3J5cHRhbmFseXRpYyBpbnNpZ2h0cw0KPnRoYXQgd291bGQgaW52 YWxpZGF0ZSB0aGlzIHdoZW4gdXNpbmcgQUVTLikgU2ltaWxhciBpZGVhcyBvZiBtb3JlDQo+c3Ry dWN0dXJlZCBibG9jay1jaXBoZXIgYmFzZWQga2V5LWRlcml2YXRpb24gaGF2ZSBiZWVuIHVzZWQg aW4NCj5kaWZmZXJlbnQgY29udGV4dHMsIGUuZy4sIGluIGh0dHBzOi8vZXByaW50LmlhY3Iub3Jn LzIwMTcvODc3Lg0KPg0KPldlIGNhbiBwcm92ZSBleGNlbGxlbnQgc2VjdXJpdHkgYm91bmRzIGZv ciB0aGlzIHZhcmlhbnQgb2YNCj5BRVMtR0NNLVNJViwgaW4gcGFydGljdWxhciBpbiB0aGUgc28t Y2FsbGVkIOKAnG11bHRpLXVzZXIgc2V0dGluZ+KAnSwNCj53aGVyZSBhdHRhY2tlcnMgYXJlIGFj Y2Vzc2luZyBtdWx0aXBsZSBpbnN0YW50aWF0aW9ucyBvZiB0aGUgc2NoZW1lDQo+dW5kZXIgaW5k ZXBlbmRlbnQga2V5cyAodGhpbmsgb2YgdGhpcyBhcyBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMgdXNp bmcNCj50aGUgc2NoZW1lKS4gSW4gdGhpcyBjYXNlLCB3ZSBvYnRhaW4gYSBib3VuZCBvZiB0aGUg b3JkZXIgTEIgLyAyXnsxMjh9DQo+KyBkKFQgKyBMKSAvIDJeaywgd2hlcmU6IEwgaXMgYSBib3Vu ZCBvbiB0aGUgbnVtYmVyIG9mIGJsb2NrcywgQiBpcyBhDQo+Ym91bmQgb24gdGhlIG51bWJlciBv ZiBibG9ja3MgZW5jcnlwdGVkL3ZlcmlmaWVkIGZvciBhIG5vbmNlLXVzZXINCj5wYWlyLCBkIGlz IHRoZSBtYXhpbXVtIG51bWJlciBvZiB1c2VycyB0aGF0IHJlLXVzZSBhIG5vbmNlIGluDQo+ZW5j cnlwdGlvbiBxdWVyaWVzLCBUIGlzIGEgYm91bmQgb24gdGhlIHRpbWUtY29tcGxleGl0eSBvZiB0 aGUNCj5hdHRhY2tlciwgYW5kIGsgaXMgdGhlIGtleSBsZW5ndGggb2YgQUVTLCB3aGljaCBpcyBl aXRoZXIgMTI4IG9yIDI1Ng0KPmJpdHMuIChGb3IgdGhlIHNpbmdsZS11c2VyIHNldHRpbmcgdGhl biBvYnZpb3VzbHkgZCA9IDEuKSBJZiBub25jZXMgaW4NCj5lbmNyeXB0aW9uIHF1ZXJpZXMgYXJl IHBpY2tlZCBhdCByYW5kb20gdGhlbiBkIGlzIGEgc21hbGwgY29uc3RhbnQsDQo+YW5kIHRodXMg dGhlIG11bHRpLXVzZXIgc2VjdXJpdHkgaXMgcm91Z2hseSB0aGUgc2FtZSBhcyB0aGUNCj5zaW5n bGUtdXNlciBzZWN1cml0eS4gKEluIHBhcnRpY3VsYXIsIHRoZXJlIGlzIGEgZm9sa2xvcmUNCj51 bmRlcnN0YW5kaW5nIHRoYXQgbXVsdGktdXNlciBzZWN1cml0eSBmYWlscyB3aGVuIG1vcmUgdGhh biAyXns2NH0NCj51c2VycyBhcmUgaW52b2x2ZWQsIGZvciBrID0gMTI4LCBhcyB0d28gb2YgdGhl bSB3aWxsIGxpa2VseSBoYXZlIHRoZQ0KPnNhbWUga2V5LCBidXQgc2hvdyB0aGF0IHRoaXMgaXMg bm90IGFuIGlzc3VlIGZvciBBRVMtR0NNLVNJVi4pDQo+DQo+SWYgbm9uY2VzIGFyZSBwaWNrZWQg YXJiaXRyYXJpbHkgdGhlbiBkIGNhbiBiZSBhcyBiaWcgYXMgdGhlIG51bWJlciBvZg0KPnF1ZXJp ZXM7IGluIHRoaXMgY2FzZSB3ZSBuZWVkIHRvIHBpY2sga2V5IGxlbmd0aCBrID0gMjU2IGZvciBo aWdoDQo+c2VjdXJpdHkgaW4gdGhlIG11bHRpLXVzZXIgc2V0dGluZy4NCj4NCj5XZSBub3RlIHRo YXQgcHJldmlvdXMgYW5hbHlzZXMgZG8gbm90IGNvbnNpZGVyIHRoZSBtdWx0aS11c2VyIHNldHRp bmcuDQo+DQo+QmVzdCwNCj4NCj5Qcml5YW5rYSBCb3NlIChVQyBTYW50YSBCYXJiYXJhKQ0KPlZp ZXQgVHVuZyBIb2FuZyAoRmxvcmlkYSBTdGF0ZSBVbml2ZXJzaXR5KQ0KPlN0ZWZhbm8gVGVzc2Fy byAoVUMgU2FudGEgQmFyYmFyYSkNCj4NCj4NCj5PbiBTYXQsIFNlcCAxNiwgMjAxNyBhdCA1OjE1 IFBNLCBBbGV4ZXkgTWVsbmlrb3YNCj48YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbT4gd3JvdGU6 DQo+PiBEZWFyIENGUkcgcGFydGljaXBhbnRzLA0KPj4NCj4+IFRoaXMgbWVzc2FnZSBzdGFydHMg MiB3ZWVrIFJHTEMgb24gIkFFUy1HQ00tU0lWOiBOb25jZSBNaXN1c2UtUmVzaXN0YW50DQo+PiBB dXRoZW50aWNhdGVkIEVuY3J5cHRpb24iIChkcmFmdC1pcnRmLWNmcmctZ2Ntc2l2LTA2KSwgdGhh dCB3aWxsIGVuZCBvbg0KPj4gT2N0b2JlciAxc3QuIFBsZWFzZSBzZW5kIHlvdSBjb21tZW50cywg YXMgd2VsbCBhcyBleHByZXNzaW9uIG9mIHN1cHBvcnQNCj4+dG8NCj4+IHB1Ymxpc2ggYXMgYW4g UkZDIChvciBwb3NzaWJsZSByZWFzb25zIGZvciBub3QgZG9pbmcgc28pIGluIHJlcGx5IHRvDQo+ PnRoaXMNCj4+IG1lc3NhZ2Ugb3IgZGlyZWN0bHkgdG8gQ0ZSRyBjaGFpcnMuIFlvdXIgZmVlZGJh Y2sgd2lsbCBoZWxwIGNoYWlycyB0bw0KPj5kZWNpZGUNCj4+IHdoZXRoZXIgdGhlIGRvY3VtZW50 IGlzIHJlYWR5IGZvciByZXZpZXcgYnkgSVJTRyBhbmQgc3Vic2VxdWVudA0KPj5wdWJsaWNhdGlv bg0KPj4gYXMgYW4gUkZDLg0KPj4NCj4+IFRoYW5rIHlvdSwNCj4+IEtlbm55IGFuZCBBbGV4ZXkN Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4+IENmcmdAaXJ0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmly dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPj4NCj4NCj4NCj4NCj4tLSANCj5TdGVmYW5v IFRlc3Nhcm8NCj5Bc3Npc3RhbnQgUHJvZmVzc29yIG9mIENvbXB1dGVyIFNjaWVuY2UNCj5Vbml2 ZXJzaXR5IG9mIENhbGlmb3JuaWEsIFNhbnRhIEJhcmJhcmENCj5odHRwOi8vY3MudWNzYi5lZHUv fnRlc3Nhcm8vDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5DZnJnIG1haWxpbmcgbGlzdA0KPkNmcmdAaXJ0Zi5vcmcNCj5odHRwczovL3d3dy5p cnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg0K From nobody Mon Oct 2 22:30: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 56CF11342D0 for ; Mon, 2 Oct 2017 22:30:00 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=biu365.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 k2yiuK_3d2dw for ; Mon, 2 Oct 2017 22:29:57 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0096.outbound.protection.outlook.com [104.47.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3D513301B for ; Mon, 2 Oct 2017 22:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=biu365.onmicrosoft.com; s=selector1-biu-ac-il; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j5CYtGY0TpkmAT2GSl+7r0CDwMp9ezQQ2peMugTNjjY=; b=ON3qjaMu0YQ2eU7wyIyl/DKd8OsAX0PwdNTNMPE7Mt+fMv+9zCqUyKzKnTevTPgRyezkqlrCMrbqe1qZ7PVvcsIUJZc9WpLP61pa32hqhL/CTRlacZSsOpqxYL2XWURalX9AAGzmTKe1GkjIOO3SoG2bTZluNrIkhvwQydwLL6Q= Received: from VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) by VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 3 Oct 2017 05:29:48 +0000 Received: from VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::7d5a:9e3a:92f:7b3c]) by VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::7d5a:9e3a:92f:7b3c%13]) with mapi id 15.20.0077.018; Tue, 3 Oct 2017 05:29:48 +0000 From: Yehuda Lindell To: "cfrg@irtf.org" , Paterson Kenny Thread-Topic: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06 Thread-Index: AQHTPAie8f6pbpDtCkaVEQgXSqmCwA== Date: Tue, 3 Oct 2017 05:29:44 +0000 Message-ID: <6FE8E700-E7F8-46F5-8EC4-E948FDB1D9BE@biu.ac.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [81.218.146.18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR04MB3021; 6:9VL0QkOIWt4+hKqja798mmm1uz3uwLly/o/MQ+vwnP7vuAxRtxR8ocDdaSHDPcqCvNTTGJpalkC1ZroWGzhusmB/X6TaPgxQDDmYJWSfO6+zH8NFoHEm/OQKcWliTztHU6HXE7XGX9bjHDYqcHmlG63Q27H9PAlplG8vkrKgaFIHKUYVPtoDpeCUL5HxBH9ZflYB/u3bxiljCtEPKweGKsHx+rncBXHSy0GznysP7ttqwq+lhyvygnI6ljGpm8nToWMtLlLcW45KHFxeffTH9cOGQGVJK27c5uSAoHcgHiwnsm55RX/1gT7VU5prVL9bua2P2pIX9NY8aC0UCuEveg==; 5:eK3B3vTVzXSsIKLGwH4Wz5h3RkqHxKAMKCv5zEnz8vurtnqgyxrQkrNHomm6HRpUuSpQQ/5XX/xtExpkNWvPPmVeBvxG7Rr5eCZEEd3mZRcV+yAU/MrajXJw/BvYqJZVbxhFSnBW191mnG+Fu9jszw==; 24:92qo+3Xs8Z16kz4yx2SfrElcehBRWkgtbzCnuNqpaLnYovUwCDqXEpf9RUH4V4QbqPF2Mrvvkcpp0+6bC9k21xMR7GcFh4ncg1edTEC1xN4=; 7:JjNjQJSlMFqrgxk+fcs1XtckTtg8P+HWaSiz9Ho+7Ahj6MeTjWHg444+GdYuMx6B63LknxrAHp0Jzk5kgZ3CLuM3uuwDcOR2lAir7zsuOuzP7jbczk4BVPkLgaRStbHwEl94aOwFY6/68ud3NHD5GRFnufVOCsMVO1xWGPKlsYlJstwHcwA2G82FmupB5Z/Wwgb4bH3XyWBd10y7MXqXUxOLXZpT3sJt7EaKqA6BvTg= x-ms-office365-filtering-correlation-id: bee9fcdb-ade8-4600-5654-08d50a1fc39b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR04MB3021; x-ms-traffictypediagnostic: VI1PR04MB3021: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yehuda.Lindell@biu.ac.il; x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR04MB3021; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR04MB3021; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39830400002)(189002)(199003)(6116002)(105586002)(99286003)(3846002)(102836003)(82746002)(97736004)(6246003)(8656003)(305945005)(66066001)(230783001)(6512007)(478600001)(413944005)(2501003)(83716003)(5250100002)(106356001)(54356999)(50986999)(3660700001)(72206003)(99936001)(8936002)(8676002)(2900100001)(786003)(81156014)(229853002)(6436002)(6666003)(68736007)(6486002)(316002)(86362001)(101416001)(33656002)(81166006)(14454004)(3280700002)(189998001)(7736002)(53936002)(25786009)(42882006)(74482002)(36756003)(5660300001)(2906002)(74826001)(110136005)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB3021; H:VI1PR04MB3021.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: biu.ac.il does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_0D26DFB4-7619-4952-877D-18549780D505"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: biu.ac.il X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2017 05:29:44.9325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61234e14-5b87-4b67-ac19-8feaa8ba8f12 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3021 Archived-At: Subject: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06 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, 03 Oct 2017 05:30:00 -0000 --Apple-Mail=_0D26DFB4-7619-4952-877D-18549780D505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, The paper by Bose, Hoang and Tessaro (BHT) shows that AES-GCM-SIV has = excellent multi-user security bounds (according to the authors, this is = the first scheme that has been shown to have the property that the = multi-user security is essentially as good as the single user security). = Thus, this is great support for AES-GCM-SIV as a standard. Conceptually, the reason why AES-GCM-SIV gets much better multi-user = security than other modes is due to the continual key derivation that = ensures that even if two users have the same key, the damage is minimal = since they must also use the same IV in order to face a problem. The authors also show that the ORIGINAL key derivation mode proposed for = AES-GCM-SIV is actually good enough (i.e., simple key derivation via CTR = mode, and without truncation). They say that it is more efficient, and = this is true theoretically. However, practically, when using AES-NI, the = cost of 2 additional encryptions for the key derivation is almost zero = due to the pipeline (2 more cycles), and negligible even for reasonably = small messages. Especially, since these are shadowed by the key = expansion that is required in any case. At the time, there were objections to the plain CTR derivation method, = during the CFRG discussions (e.g., due to the fact that for 256-bit = keys, this rules out the possibility of keys of the form K||K). Instead, = an OCB style derivation was promoted. Subsequently, we ended up with the = current truncated CTR method. We therefore propose to not change the key = derivation method (again). Thanks, Shay, Adam and Yehuda --Apple-Mail=_0D26DFB4-7619-4952-877D-18549780D505 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEELaoRJT8y/J6kd2e6gpgt7E/5w4gFAlnTHAcACgkQgpgt7E/5 w4gjeQ/+MeafSORfEhNMEnWbRNEcv9Ne/bY5audDwlnX8H/5JdCzCJFnBGIXoptu O75cmx6FgekSBgyW3S0Yj8sVm7u57j3pA1k+ZFKUVaHDGNZiUu3PXkm4L1zYxd/z 4YK7EC+DnkZt1lKm3dRSPaOBOLtyrGjAB+QCay2LtHFHji4uOHf+lb2hTK8s87xi r8ZcHewDr9VP8hyknSucfY1+iac8QpKwIWdDukVgMoew5cwrqTd2IE2UEF5FzVaI +LbeGodr9JuYoYnBKJb3TR8vycZnwG2puPCMOacyCiW6zdBdF9gqX7sYdruwPY+l tfTOJVMAVskyjl3nTeG9p0sMOAPRQSbR1CTq7VrG4ZT2CvZCQtiN1issow0U/Zhb svrWVELEgGLTfKghWFLTo8EL2oKeDatKQAuMpegJdXocRBPXsjV0vYJnuCRtSAp3 QrAubz8iFpjQEO/zAqoH0E6hIzLJygQA9imuS3T1aQ0OAXMZFpJ26QtQMJNiGo72 9ootNGaYf8ZN5hRCzlWDPfNT3FoFm3BJvQQS/PNfqf9iAI9zRjWpUwpp4LZcUM5E H5YkvAkf/X9BFZZ6nkWzd3GQDxBKCIneN+rdTCd+ISTUCjaQDnbukcaZWdV+LBGL RzzMUrC/WhlmOsSdgjKhs+A+7Frr8oBMewSx3ypsH+CjZITO6uU= =ZS43 -----END PGP SIGNATURE----- --Apple-Mail=_0D26DFB4-7619-4952-877D-18549780D505-- From nobody Wed Oct 4 04:28:46 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 A5571132355 for ; Wed, 4 Oct 2017 04:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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=isode.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 2yJp6xt1dBkS for ; Wed, 4 Oct 2017 04:28:43 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADAE126DD9 for ; Wed, 4 Oct 2017 04:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1507116522; d=isode.com; s=june2016; i=@isode.com; bh=USs1AuQlArCSav0DSV0Ii5JfNKGzkni6ArFmdfQGaRM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vc/B7Vjz/XyLVJwS5zpz5x2CTIY6Due5FSPgmHeGTE1a9uUsFATPNWpyExAeoK9KgWI8nG Vo8MA1XNFOWYANKqGQ+2B2eAFyUgzXtl0mNwlKAQz5anLjNjN3uOXZv73iNLy58U/op1E4 i5qI0yE/e/SYrPF7pZy8Q8idmDYSMNA=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Oct 2017 12:28:42 +0100 References: To: "cfrg@irtf.org" From: Alexey Melnikov X-Forwarded-Message-Id: Message-ID: <892677cc-4ca3-e6b0-a756-c3a9df52b25a@isode.com> Date: Wed, 4 Oct 2017 12:27:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C1DAB541A19FC6E60A0BAE9B" Content-Language: en-US Archived-At: Subject: [Cfrg] Fwd: [irsg] Please help publicise: Call for Nominations: 2018 Applied Networking Research Prize (ANRP) 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, 04 Oct 2017 11:28:45 -0000 --------------C1DAB541A19FC6E60A0BAE9B Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable FYI. -------- Forwarded Message -------- Subject: [irsg] Please help publicise: Call for Nominations: 2018=20 Applied Networking Research Prize (ANRP) Date: Wed, 4 Oct 2017 12:13:12 +0100 From: Matthew Ford To: anrp-select@irtf.org, irsg@irtf.org [Note: Prize money increased to $1k for 2018] Please help publicise by forwarding the CFP and/or sharing these social post= s: https://twitter.com/inretafo/status/915504636513128448 https://www.facebook.com/inretafo/posts/1474689725949012 Thanks, Mat CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2018 https://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2018 award period of the *** *** Applied Networking Research Prize until November 5, 2017! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: =E2=80=A2 invited talk at the IRTF Open Meeting =E2=80=A2 travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) =E2=80=A2 cash prize of $1000 (USD) =E2=80=A2 recognition at the IETF plenary =E2=80=A2 invitation to related social activities =E2=80=A2 potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self-nominations (nominating one=E2=80=99s own paper) and third-party nominations (nominating someone else=E2=80=99s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=E2=80=99s IETF meetings in person and in its entirety. Nominations must include: =E2=80=A2 the name and email address of the nominee =E2=80=A2 a bibliographic reference to the published (or accepted) nominated paper =E2=80=A2 a PDF copy of the nominated paper =E2=80=A2 a statement that describes how the nominated paper fulfills the goals of the award =E2=80=A2 a statement about which of the year=E2=80=99s IETF meetings the no= minee would be available to attend in person and in its entirety =E2=80=A2 a brief biography or CV of the nominee =E2=80=A2 optionally, any other supporting information (link to nominee=E2= =80=99s web site, etc.) Nominations are submitted via the submission site at https://irtf.org/anrp/2018/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. IMPORTANT DATES Applications close: November 5, 2017 (hard) Notifications: December 7, 2017 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC) in coordination with the Internet Research Task Forc= e (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at https://irtf.org/anrp-2018-flyer.pdf --------------C1DAB541A19FC6E60A0BAE9B Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

FYI.


-------- Forwarded Message --------
Subjec= t: [irsg] Please help publicise: Call for Nominations: 2018 Applied Networking Research Prize (ANRP)
Date: = Wed, 4 Oct 2017 12:13:12 +0100
From: = Matthew Ford <ford@isoc.org>
To: anrp-select@irtf.org, irsg@irtf.org 


[Note: Prize money increased to $1k for 2018]

Please help publicise by forwarding the CFP and/or sharing these social post=
s:

https://twitter.com/inretafo/status/91550463651312844=
8
https://www.facebook.com/inretafo/posts/14746897259=
49012

Thanks,
Mat

                   CALL FOR NOMINATIONS:

         APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2018

                    https://irtf.org/anrp

********************************************************************
***     Submit nominations for the 2018 award period of the      ***
***  Applied Networking Research Prize until November 5, 2017!   ***
***                                                              ***
***    (Please share this announcement with your colleagues.)    ***
********************************************************************

The Applied Networking Research Prize (ANRP) is awarded for recent
results in applied networking research that are relevant for
transitioning into shipping Internet products and related
standardization efforts. Researchers with relevant, recent results are
encouraged to apply for this prize, which will offer them the
opportunity to present and discuss their work with the engineers,
network operators, policy makers and scientists that participate in
the Internet Engineering Task Force (IETF) and its research arm, the
Internet Research Task Force (IRTF). Third-party nominations for this
prize are also encouraged. The goal of the Applied Networking Research
Prize is to recognize the best new ideas in networking, and bring them
to the IETF and IRTF especially in cases where they would not
otherwise see much exposure or discussion.

The Applied Networking Research Prize (ANRP) consists of:

=E2=80=A2 invited talk at the IRTF Open Meeting
=E2=80=A2 travel grant to attend a week-long IETF meeting (airfare, hotel,
 registration, stipend)
=E2=80=A2 cash prize of $1000 (USD)
=E2=80=A2 recognition at the IETF plenary
=E2=80=A2 invitation to related social activities
=E2=80=A2 potential for additional travel grants to future IETF meetings,
 based on community feedback

The Applied Networking Research Prize will be awarded once per
calendar year. Each year, several winners will be chosen and invited
to present their work at one of the three IETF meetings during the
year.


HOW TO NOMINATE

Only a single person can be nominated for the award. The basis of the
nomination is a peer-reviewed, original journal, conference or
workshop paper they authored, which was recently published or accepted
for publication. The nominee must be one of the main authors of the
nominated paper. Both self-nominations (nominating one=E2=80=99s own paper)
and third-party nominations (nominating someone else=E2=80=99s paper) are
encouraged.

The nominated paper should provide a scientific foundation for
possible future IETF engineering work or IRTF research and
experimentation, analyze the behavior of Internet protocols in
operational deployments or realistic testbeds, make an important
contribution to the understanding of Internet scalability,
performance, reliability, security or capability, or otherwise be of
relevance to ongoing or future IETF or IRTF activities.

Applicants must briefly describe how the nominated paper relates to
these goals, and are encouraged to describe how a presentation of
these research results would foster their transition into new IETF
engineering or IRTF experimentation, or otherwise seed new activities
that will have an impact on the real-world Internet.

The goal of the Applied Networking Research Prize (ANRP) is to foster
the transitioning of research results into real-world benefits for the
Internet. Therefore, applicants must indicate that they (or the
nominee, in case of third-party nominations) are available to attend
at least one of the year=E2=80=99s IETF meetings in person and in its
entirety.

Nominations must include:

=E2=80=A2 the name and email address of the nominee
=E2=80=A2 a bibliographic reference to the published (or accepted)
 nominated paper
=E2=80=A2 a PDF copy of the nominated paper
=E2=80=A2 a statement that describes how the nominated paper fulfills the
 goals of the award
=E2=80=A2 a statement about which of the year=E2=80=99s IETF meetings the no=
minee
 would be available to attend in person and in its entirety
=E2=80=A2 a brief biography or CV of the nominee
=E2=80=A2 optionally, any other supporting information (link to nominee=E2=
=80=99s
 web site, etc.)

Nominations are submitted via the submission site at
http=
s://irtf.org/anrp/2018/. In exceptional cases, nominations may also
be submitted by email to anrp@irtf.org.


IMPORTANT DATES

Applications close: November 5, 2017 (hard)
Notifications:      December 7, 2017


SPONSORS

The Applied Networking Research Prize (ANRP) is supported by the
Internet Society (ISOC) in coordination with the Internet Research Task Forc=
e
(IRTF).


HELP PUBLICIZE THE ANRP

If you would like to help publicize the ANRP within your
organization, you are welcome to print and use the flyer at
https://irtf.org/anrp-2018-flyer.pdf
--------------C1DAB541A19FC6E60A0BAE9B-- From nobody Fri Oct 6 11:00:57 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 2EF8C134B89; Fri, 6 Oct 2017 11:00:56 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150731285614.13237.7642661830582237112@ietfa.amsl.com> Date: Fri, 06 Oct 2017 11:00:56 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-mcgrew-hash-sigs-08.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, 06 Oct 2017 18:00:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : Hash-Based Signatures Authors : David McGrew Michael Curcio Scott Fluhrer Filename : draft-mcgrew-hash-sigs-08.txt Pages : 45 Date : 2017-10-06 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-08 https://datatracker.ietf.org/doc/html/draft-mcgrew-hash-sigs-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mcgrew-hash-sigs-08 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 Sat Oct 7 05:04:00 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 A91931348E5; Sat, 7 Oct 2017 05:03:58 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150737783865.11031.5119141582841414239@ietfa.amsl.com> Date: Sat, 07 Oct 2017 05:03:58 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-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: Sat, 07 Oct 2017 12:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-07.txt Pages : 50 Date : 2017-10-06 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, CBC, CFB 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-07 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-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 Mon Oct 9 07:36:44 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 1DB15132944; Mon, 9 Oct 2017 07:36:42 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150755980208.18384.2936406403472477741@ietfa.amsl.com> Date: Mon, 09 Oct 2017 07:36:42 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-08.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, 09 Oct 2017 14:36:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-08.txt Pages : 49 Date : 2017-10-09 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, CBC, CFB 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-08 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-08 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 Mon Oct 9 08:22:27 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 27278134EEF for ; Mon, 9 Oct 2017 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 PRC0wvKVDobm for ; Mon, 9 Oct 2017 08:22:21 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 CB17A134F8E for ; Mon, 9 Oct 2017 08:14:16 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id b15so21771957qkg.9 for ; Mon, 09 Oct 2017 08:14:16 -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=X6xOfDhJMvAu7e4goROehqbq+ZL3LyS0T+XrukwlexI=; b=ZAH+2kI16KCauGaZN4Ukm9Dz8Jlfp/3SycPGJdaiqgyVTQqAtZPsIlQjbGtoGamF6D 8Guyol9DoZ2OYc4yf9AQPJ8SHD9NmZXhNcF0KSJxIGAnFxfEj6r1NlruE3w0KEvV9hdC LkgdsEXxL4WD+SXKV/EtIWDh2hq9vT11m5yrhvp/eJ5F/y8e0DBfKdaLn/9jLs4sKato 0Zw7GZAImb+iVXdpFLW4nSZjT7thFDXMNuISHgcMCUu2qT6DVypDLgOdyeHrI05qRDFo OPoezh7I2zqrJHVsiGRtN9WkZ935SQZ5usEqOvHvx9XL5UT78oRkIZvhthwpBTDrPd18 A6wg== 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=X6xOfDhJMvAu7e4goROehqbq+ZL3LyS0T+XrukwlexI=; b=Gn8fm/mA43Hugk1MCJLQ9dmQZdvvd2dqhB+Bdhq44A16jxqg33ZeAgi2IbLCYwR759 OwmRLLQO+8SeonGfi98br5V9eahImRng6/FuaTEdYIsJubbdxoSzkNAfuh8RT4+dhcZw 4aqwPGe1x7tA6AKB8bRHXWVOS9trJqXDd027EvzlVKPUTPOUxPOYqsfWLUiT0SEuXEBM RH62gPOX2SuBliPPIQhjCXD4wRqq14MwI7gXVB0qMc+CBmcuWvx3koB6YZPaRBkTp8QZ fSbFrhInDOb8p+UQMtY9iARvGaZPYFhf2kJsItzel6K1U0kCovPJV3od6yk7LithXZsC 82VQ== X-Gm-Message-State: AMCzsaWNOdn03w2JMGnTnWGbveaRlG7ClWeXEnsTWlb9Zo7wadcoz+sU 8/BX/MWT/E0V1xHjiSG2mjfjxwfmJuhMe1fURYqRQmTB X-Google-Smtp-Source: AOwi7QCNdudG3XOFtDnBKPL8kQ8YgAJ442f6jwkfKAG8OmF/D3cuMadd6h0/R3v+XvB8vCsCIER5XX58GyMmFB0sCAQ= X-Received: by 10.55.197.152 with SMTP id k24mr9039398qkl.178.1507562055445; Mon, 09 Oct 2017 08:14:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.16 with HTTP; Mon, 9 Oct 2017 08:14:14 -0700 (PDT) In-Reply-To: <150755980208.18384.2936406403472477741@ietfa.amsl.com> References: <150755980208.18384.2936406403472477741@ietfa.amsl.com> From: "Stanislav V. Smyshlyaev" Date: Mon, 9 Oct 2017 18:14:14 +0300 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a1149ad0acac980055b1ea48c" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-08.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: Mon, 09 Oct 2017 15:22:26 -0000 --001a1149ad0acac980055b1ea48c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues, In Prague, we listed several todo's about our Re-keying draft; thanks to the efforts of the persons listed in the contributors and "thanks to" lists now we have a new version, addressing the comments and concerns that have been discussed earlier. There have been several updates of the draft, major changes from the July version (discussed at IETF 99 CFRG meeting) are the following: 1) New test examples have been added: external re-keying with a parallel construction based on AES-256, external re-keying with a serial construction based on SHA-256, OMAC-ACPKM-Master mode with AES-256, as agreed. 2) CCM-ACPKM and CCM-ACPKM-Master, OFB-ACPKM-Master modes have been removed from the document, as agreed. 3) =E2=80=9CKey Hierarchy Construction=E2=80=9D section has been added. 4) The more restrictive terminology for different types of keys has been introduced: "initial key", "section key" (data processing key in internal re-keying), "master key", "section key material", "subkey", "frame key" (data processing key in external re-keying). 5) The additional hash calculation for ICB value (if c!=3D32) has been removed from GCM-ACPKM and GCM-ACPKM-Master modes. The current version (https://tools.ietf.org/html/ draft-irtf-cfrg-re-keying-08) seems to take all concerns and considerations we've discussed (in Chicago, in Prague and in e-mails) into account =E2=80= =93 please let me know if we've missed something. If there won't be any objections, I think we should start thinking about moving to the review phase. Kindest regards, Stanislav 2017-10-09 17:36 GMT+03:00 : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Crypto Forum RG of the IRTF. > > Title : Re-keying Mechanisms for Symmetric Keys > Author : Stanislav Smyshlyaev > Filename : draft-irtf-cfrg-re-keying-08.txt > Pages : 49 > Date : 2017-10-09 > > 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, > CBC, CFB 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-08 > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-re-keying-08 > > > 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/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a1149ad0acac980055b1ea48c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,
<= br>
In Prague, we listed several todo&= #39;s about our Re-keying draft; thanks to the efforts of the persons liste= d in the contributors and "thanks to" lists now we have a new ver= sion, addressing the comments and concerns that have been discussed earlier= .
There have been several = updates of the draft, major changes from the July version (discussed at IET= F 99 CFRG meeting) are the following:

1) New test examples h= ave been added: external re-keying with a parallel construction based on AE= S-256, external re-keying with a serial construction based on SHA-256, OMAC= -ACPKM-Master mode with AES-256, as agreed.
2) CCM-ACPKM and CCM-ACPKM-Master, OFB-A= CPKM-Master modes have been removed from the document, as agreed.
3) =E2=80=9CKey Hi= erarchy Construction=E2=80=9D section has been added.
4) The more restrictive termin= ology for different types of keys has been introduced: "initial key&qu= ot;, "section key" (data processing key in internal re-keying), &= quot;master key", "section key material", "subkey"= , "frame key" (data processing key in external re-keying).
<= div dir=3D"ltr">5) The addition= al hash calculation for ICB value (if c!=3D32) has been removed from GCM-AC= PKM and GCM-ACPKM-Master modes.

The current versio= n (https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-0= 8) seems to take all concerns and considerations we've discussed (i= n Chicago, in Prague and in e-mails) into account=C2=A0=E2=80=93 please let= me know if we've missed something. If there won't be any objection= s, I think we should start thinking about moving to the review phase.
=

Kindest regards,
Stanislav

2017-10-09 17:36 GMT+03:00 <interne= t-drafts@ietf.org>:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Crypto Forum RG of the IRTF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Re-keying Mechanisms for Symmetric Keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Stan= islav Smyshlyaev
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-irt= f-cfrg-re-keying-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 49
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-09

Abstract:
=C2=A0 =C2=A0A certain maximum amount of data can be safely encrypted when<= br> =C2=A0 =C2=A0encryption is performed under a single key.=C2=A0 This amount = is called
=C2=A0 =C2=A0"key lifetime".=C2=A0 This specification describes a= variety of methods to
=C2=A0 =C2=A0increase the lifetime of symmetric keys.=C2=A0 It provides ext= ernal and
=C2=A0 =C2=A0internal re-keying mechanisms based on hash functions and on b= lock
=C2=A0 =C2=A0ciphers, that can be used with modes of operations such as CTR= , GCM,
=C2=A0 =C2=A0CBC, CFB and OMAC.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-irtf-cfrg-re-keying/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-= cfrg-re-keying-08
https://datatracker.ietf.org/= doc/html/draft-irtf-cfrg-re-keying-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-irtf-cfrg-re-keying-08


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--001a1149ad0acac980055b1ea48c-- From nobody Mon Oct 9 09:57: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 3369A1346DD for ; Mon, 9 Oct 2017 09:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nruMBtfNG6gq for ; Mon, 9 Oct 2017 09:56:59 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8BB1346E0 for ; Mon, 9 Oct 2017 09:56:59 -0700 (PDT) X-Spoof: Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2017 12:56:58 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Oct 2017 12:56:57 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 9 Oct 2017 12:56:57 -0400 From: Dan Brown To: Cfrg Thread-Topic: Deterministic signatures, revisit? Thread-Index: AdNBH50tQgHz3eF1TuGYa1rEbDjjnw== Date: Mon, 9 Oct 2017 16:56:56 +0000 Message-ID: <20171009165655.8609877.65333.18037@blackberry.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2017100916565586098776533318037blackberrycom_" MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Deterministic signatures, revisit? 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, 09 Oct 2017 16:57:01 -0000 --_000_2017100916565586098776533318037blackberrycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ0ZSRywNCg0KaWEuY3IvMjAxNy85NzUgYW5kIGlhLmNyLzIwMTcvOTg1IHN1Z2dlc3QgdHdl YWtzIHRvIGRldGVybWluaXN0aWMgc2lnbmluZywgZWcgRWREU0EsIGR1ZSB0byBzaWRlIGNoYW5u ZWxzLCBldGMuIERvIHRoZXNlIHR3ZWFrcyBtZXJpdCBjb25zaWRlcmF0aW9uIGluIENGUkc/4oCO IChJJ20gbm90IHN1cmUgaG93IGltcG9ydGFudCBzaWRlIGNoYW5uZWxzIGFyZSB0byBDRlJHIG9y IGhvdyBzdHJvbmcgdGhlIHR3ZWFrcyBhcmUuKQ0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRhbg0KDQo= --_000_2017100916565586098776533318037blackberrycom_ Content-Type: text/html; charset="utf-8" Content-ID: <962862AAA1FE9E4199280C1A88A0F287@rim.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4gYm9keSB7ICBmb250LWZhbWlseTog IkNhbGlicmkiLCJTbGF0ZSBQcm8iLHNhbnMtc2VyaWYsInNhbnMtc2VyaWYiOyBjb2xvcjojMjYy NjI2IH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tVVMiPg0KPGRpdj5IaSBDRlJH LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+aWEuY3IvMjAxNy85NzUgYW5kIGlhLmNy LzIwMTcvOTg1IHN1Z2dlc3QgdHdlYWtzIHRvIGRldGVybWluaXN0aWMgc2lnbmluZywgZWcgRWRE U0EsIGR1ZSB0byBzaWRlIGNoYW5uZWxzLCBldGMuIERvIHRoZXNlIHR3ZWFrcyBtZXJpdCBjb25z aWRlcmF0aW9uIGluIENGUkc/4oCOIChJJ20gbm90IHN1cmUgaG93IGltcG9ydGFudCBzaWRlIGNo YW5uZWxzIGFyZSB0byBDRlJHIG9yIGhvdyBzdHJvbmcgdGhlIHR3ZWFrcyBhcmUuKTwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLCA8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkRhbjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksICdTbGF0ZSBQcm8nLCBzYW5zLXNlcmlmLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9zcGFu PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2017100916565586098776533318037blackberrycom_-- From nobody Mon Oct 9 10:30: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 59F44133347 for ; Mon, 9 Oct 2017 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 lnt6ECv6j_nk for ; Mon, 9 Oct 2017 10:30:40 -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 9B405134710 for ; Mon, 9 Oct 2017 10:30:40 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id w134so24304344qkb.0 for ; Mon, 09 Oct 2017 10:30:40 -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=L8nj255dQLj21YZxVfnwm4c/V7Bwxzx5+bJWFAUZB2A=; b=NKYCIFM+d8jN9AT0TP8Lg7E1IJR4YHCF38ELWoG+q2G8p+pKPujTO0wpwhfdMS3GFO jmpr/WGF7oBeHNmWEw/0Y4Wsx+Cigo3IFVC+K0ft92xQDpy4WSE5bem2G1O+Q3gj4mQ8 BbKQY+3wUwE+2cDSjnve1mci57DQv6UhJCyT/6NlQeHjEEcPGM0yHf2ExVAlSmyFuT8F v617LT8/El//PIpR0RxunijyHfkf2eT821EacxJgmrw4Fdf3jFtT3EyI4LNESieWnbQ2 uoBoRLNOtcvy8auKE3iFp6hctg0Kr6hFcCj2QW+TQbGGe/rqAuEEbi4l8oly8GAEqnqv BAUw== 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=L8nj255dQLj21YZxVfnwm4c/V7Bwxzx5+bJWFAUZB2A=; b=AsQzICNpHxW3LAjsIIArXZIVT3/WcLSMYlQ0cUDtGRPDrAesJ1wWkwqji28vRSAoKc DpaGk8IAiV4uaUnYjQEHi/Qmwti49+jnYt7ut4zFq974LHPL40ru4LsohAmXk7NT0/Ec +KghTsoL+Tumg3VySBmFv1O9biLV/eQ/0JpNS8GlosSH2Odf9yzHLe/D2qc8x8Q7D1br G7doCkGN4cRJXLdOoTsRHvXoupNERWKsmp5RCnnhI93knzqEiaW5RQXB9iH++m6LnPIA wWNFUu6nq1l/4NQKMad41f5Y1jSdQSDAnKCGkP3u39SKDaxHT1ChGdJZGw8xSUTZLXD0 G8ZA== X-Gm-Message-State: AMCzsaVdr1OxZDjyTIalDV63nzxKJOAe/JPXqKOEgsSso1b/PpkpPsxV m/u5WJNwTDgw5Z2vcspzuGTbLGO62PAi/iTM+7E= X-Google-Smtp-Source: AOwi7QAK19dzB+vO1jZAXl9/oYPCh7Ef/KgKeX/taxsHVY5JPjSXmxgGWTYpey04U9NUpx5jpa4wMmz8xXvFtDZgX18= X-Received: by 10.55.44.68 with SMTP id s65mr9618458qkh.202.1507570239728; Mon, 09 Oct 2017 10:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.11 with HTTP; Mon, 9 Oct 2017 10:30:19 -0700 (PDT) In-Reply-To: <20171009165655.8609877.65333.18037@blackberry.com> References: <20171009165655.8609877.65333.18037@blackberry.com> From: Tony Arcieri Date: Mon, 9 Oct 2017 10:30:19 -0700 Message-ID: To: Dan Brown Cc: Cfrg Content-Type: multipart/alternative; boundary="001a114f50a69cfb82055b208c28" Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 09 Oct 2017 17:30:42 -0000 --001a114f50a69cfb82055b208c28 Content-Type: text/plain; charset="UTF-8" This certainly keeps coming up. Beyond those papers see the previous "Side channel attack and Edwards curves" thread on this list: https://mailarchive.ietf.org/arch/msg/cfrg/V1JXfnf05uE88huYaQVKi7iZ6mY I think it's definitely a problem that needs to be addressed. I've seen various proposals to do so as well, i.e. synthesizing "r" as a combination of a random nonce and the message, so that fault attacks would, at the very least, require an RNG failure as opposed to always being possible, due to repeated "r" values for the same message. This should retain the extant defense against RNG failures in general as we saw with ECDSA "k" values, since it would still include hashing the message as part of the calculation. -- Tony Arcieri --001a114f50a69cfb82055b208c28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This certainly keeps coming up. Beyond those papers see th= e previous "Side channel attack and Edwards curves" thread on thi= s list:

https://mailarchive.ietf.org/arch/msg/cf= rg/V1JXfnf05uE88huYaQVKi7iZ6mY

I think it's definitely a pro= blem that needs to be addressed. I've seen various proposals to do so a= s well, i.e. synthesizing "r" as a combination of a random nonce = and the message, so that fault attacks would, at the very least, require an= RNG failure as opposed to always being possible, due to repeated "r&q= uot; values for the same message. This should retain the extant defense aga= inst RNG failures in general as we saw with ECDSA "k" values, sin= ce it would still include hashing the message as part of the calculation.
--
Tony Arcieri
--001a114f50a69cfb82055b208c28-- From nobody Mon Oct 9 10:49:57 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 87C1E134570 for ; Mon, 9 Oct 2017 10:49:54 -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 Uu2g_trMMf1d for ; Mon, 9 Oct 2017 10:49:52 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFD71346B0 for ; Mon, 9 Oct 2017 10:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 464F8B51AF; Mon, 9 Oct 2017 20:49:43 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id VqYl-SKWZTq7; Mon, 9 Oct 2017 20:49:43 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 88F0827F; Mon, 9 Oct 2017 20:49:39 +0300 (EEST) Date: Mon, 9 Oct 2017 20:49:39 +0300 From: Ilari Liusvaara To: Tony Arcieri Cc: Dan Brown , Cfrg Message-ID: <20171009174939.uaapnl772ynvjpoq@LK-Perkele-VII> References: <20171009165655.8609877.65333.18037@blackberry.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 09 Oct 2017 17:49:54 -0000 On Mon, Oct 09, 2017 at 10:30:19AM -0700, Tony Arcieri wrote: > This certainly keeps coming up. Beyond those papers see the previous "Side > channel attack and Edwards curves" thread on this list: > > https://mailarchive.ietf.org/arch/msg/cfrg/V1JXfnf05uE88huYaQVKi7iZ6mY > > I think it's definitely a problem that needs to be addressed. I've seen > various proposals to do so as well, i.e. synthesizing "r" as a combination > of a random nonce and the message, so that fault attacks would, at the very > least, require an RNG failure as opposed to always being possible, due to > repeated "r" values for the same message. This should retain the extant > defense against RNG failures in general as we saw with ECDSA "k" values, > since it would still include hashing the message as part of the calculation. The latter (2017/985) paper in original message seemingly proposed a countermeasure of that type. The description of countermeasure was not completely clear, but I _think_ they proposed adding 768 random bits between prefix and message in calculation of r. This change would not break compatiblity (the verifier never sees how r was generated), and if the random bits are bad, the scheme would not break catastrophically (can not predict r even if all this entropy was known). However, it would expose the scheme to additional kleptographic attacks. An ability to influence the random numbers used would be enough to compromise the private key. -Ilari From nobody Mon Oct 9 21:01:54 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 5F33D13207A for ; Mon, 9 Oct 2017 21:01:38 -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 RJSZy9X7RERE for ; Mon, 9 Oct 2017 21:01:36 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 35890120720 for ; Mon, 9 Oct 2017 21:01:36 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id a69so6466979lfe.5 for ; Mon, 09 Oct 2017 21:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jPvEjVFUkeenw7nDullIw5WGEpCL8Xci4iUcI0/Rglo=; b=D7/NtjCxq2qL2j0Vllfele2T+UiygUfj/WMto3xFv9dZS5XCMNZ3Rn1ZFtrSDckweZ ClIpLUz2sOVy1RWTO3SZcpaGjJxZH0AWvZ/hQfehZybdQg9RrcVlYoGu0RftieINc4dn zWo9zQ7Z32tNfagWfJfgKdQNVPNmdLoCpYoCHwKpeYeIhXDyl7pBQIz8MBRxeQWf+AwN zuhvpx0ypakK/tAVr073qYsS0guBuPTeBi3TOca4h6IdmMMzrCNTWl3Wgd18KOoE5i6H rAlzwT8XFTRKMhV2cnxb0D8+KVjVQ2ir/l5ODqde6u+SaX0iC6EG7b+OaJSuMYjusIAB Ug8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jPvEjVFUkeenw7nDullIw5WGEpCL8Xci4iUcI0/Rglo=; b=Q4fs5guNn5numZb8xx81yLKoVQd5F8JhbC21g1ppBWC6PErO/WfxbW6S3H8HShRYdB SiCxMaHaW1YD3eju20q5jwhGQGYYTOYi6q3oe/49DuXsh5/n2ub+mqkQkeGbs4oMhFuw kEpEop9MZxN93n8jDLHy4IYAw5ybimejKnlOb9iQh0gclzYHKoxRcANG9KbiPYHeZmxv ZCwiz4CRqloowfjQCCF9NkNfGw87gu06ZoUmQStXtId9JN8wx5ivZdPZJhlCv+8N7trf yZ/+ha6eqR2w8KCDvwEYU7Mnfpd6tItJPQHlmoEA+bMTdMFmuWjhooZCQpmElX/YJsZD fwKg== X-Gm-Message-State: AMCzsaWpFh3tG92cgUgjiII+MMl4f6JvyDGZRUDGU/1t38zpSVDNUCb2 H1VUad7oB5lVMJz6xw8/hrKOboOHYem5Q1qMBSA= X-Google-Smtp-Source: AOwi7QDH+Fvxn9+8NjGSDuM3sqKw58Un2s6w47AvYceHrZuGku6dZs9frkdORTC0Dr2lI8dCFNH14seC4UTNVFbZEw8= X-Received: by 10.46.56.12 with SMTP id f12mr5338852lja.106.1507608094211; Mon, 09 Oct 2017 21:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.2.162 with HTTP; Mon, 9 Oct 2017 21:01:33 -0700 (PDT) From: denis bider Date: Mon, 9 Oct 2017 23:01:33 -0500 Message-ID: To: Cfrg Content-Type: multipart/alternative; boundary="089e0823dca4ea80b4055b295c79" Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 10 Oct 2017 04:01:38 -0000 --089e0823dca4ea80b4055b295c79 Content-Type: text/plain; charset="UTF-8" Aren't the devices that are most susceptible to fault injection also least likely to implement a secure PRNG? My understanding is that these might be embedded devices, which often use PRNG based on a seed that's a simple timestamp, or even a hardcoded seed. Deterministic signatures have the property of being deterministic, i.e. there's a 1-to-1 mapping between { message, key } and { signature }. This makes the signing process idempotent, which could be useful in distributed systems. The deterministic property might also be welcome in forensics. Is it not cost-effective, or safe, to add mitigations such as the device verifying the signature, or the results of intermediate steps, before releasing the signature? If such mitigations are not viable, is injecting randomness into the signing process effective, if the devices most susceptible to fault injection are also likely to implement insecure PRNG? ----- Original Message ----- From: Tony Arcieri Sent: Monday, October 9, 2017 12:30 To: Dan Brown Cc: Cfrg Subject: Re: [Cfrg] Deterministic signatures, revisit? This certainly keeps coming up. Beyond those papers see the previous "Side channel attack and Edwards curves" thread on this list: https://mailarchive.ietf.org/arch/msg/cfrg/V1JXfnf05uE88huYaQVKi7iZ6mY I think it's definitely a problem that needs to be addressed. I've seen various proposals to do so as well, i.e. synthesizing "r" as a combination of a random nonce and the message, so that fault attacks would, at the very least, require an RNG failure as opposed to always being possible, due to repeated "r" values for the same message. This should retain the extant defense against RNG failures in general as we saw with ECDSA "k" values, since it would still include hashing the message as part of the calculation. -- Tony Arcieri _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --089e0823dca4ea80b4055b295c79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aren'= t the devices that are most susceptible to fault injection also least likel= y to implement a secure PRNG? My understanding is that these might be embed= ded devices, which often use PRNG based on a seed that's a simple times= tamp, or even a hardcoded seed.

Deterministic sign= atures have the property of being deterministic, i.e. there's a 1-to-1 = mapping between { message, key } and { signature }. This makes the signing = process idempotent, which could be useful in distributed systems. The deter= ministic property might also be welcome in forensics.

<= div>Is it not cost-effective, or safe, to add mitigations such as the devic= e verifying the signature, or the results of intermediate steps, before rel= easing the signature?

If such mitigations are not = viable, is injecting randomness into the signing process effective, if the = devices most susceptible to fault injection are also likely to implement in= secure PRNG?


----- Original Message= -----
From: Tony Arcieri
Sent: Monday, October 9, 2017 12:30
To: Dan Brown
Cc: Cfrg
Subject: Re: [Cfrg] Deterministic signatures, revisit?
=C2=A0
This certainly keeps coming up. Beyond those papers see the previous &= quot;Side=20 channel attack and Edwards curves" thread on this list:
=C2=A0
=C2=A0
I think it's definitely a problem that needs to be addressed. I= 9;ve seen=20 various proposals to do so as well, i.e. synthesizing "r" as a co= mbination of a=20 random nonce and the message, so that fault attacks would, at the very leas= t,=20 require an RNG failure as opposed to always being possible, due to repeated= "r"=20 values for the same message. This should retain the extant defense against = RNG=20 failures in general as we saw with ECDSA "k" values, since it wou= ld still=20 include hashing the message as part of the calculation.
=C2=A0
--
Tony Arcieri
=C2=A0
_______________________________________________
Cfrg mailing list

--089e0823dca4ea80b4055b295c79-- From nobody Tue Oct 10 03:23:38 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 CE89A134C47 for ; Tue, 10 Oct 2017 03:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3k_VyUwWia8h for ; Tue, 10 Oct 2017 03:23:34 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCC9134C71 for ; Tue, 10 Oct 2017 03:23:34 -0700 (PDT) X-Spoof: Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2017 06:23:33 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0319.002; Tue, 10 Oct 2017 06:23:32 -0400 From: Dan Brown To: Cfrg Thread-Topic: [Cfrg] Deterministic signatures, revisit? Thread-Index: AQHTQbHSfrJSeH1XP06gGlOqYlV79A== Date: Tue, 10 Oct 2017 10:23:31 +0000 Message-ID: <20171010102330.8609877.85759.18061@blackberry.com> References: <20171009165655.8609877.65333.18037@blackberry.com> In-Reply-To: <20171009165655.8609877.65333.18037@blackberry.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2017101010233086098778575918061blackberrycom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 10 Oct 2017 10:23:37 -0000 --_000_2017101010233086098778575918061blackberrycom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable =FDhttp://ia.cr/2017/890 gives a theoretical reason to prefer deterministic= signatures: some proofs work better. So, my question goes to side channels= (and subversion too, but less so) which is better at resisting them, deter= ministic or one of these tweaks in the 2 eprints below? From: Dan Brown Sent: Monday, October 9, 2017 12:57 PM To: Cfrg Subject: [Cfrg] Deterministic signatures, revisit? Hi CFRG, ia.cr/2017/975 and ia.cr/2017/985 suggest tweaks to deterministic signing, = eg EdDSA, due to side channels, etc. Do these tweaks merit consideration in= CFRG?=FD (I'm not sure how important side channels are to CFRG or how stro= ng the tweaks are.) Best regards, Dan --_000_2017101010233086098778575918061blackberrycom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

From: Dan Brown
Sent: Monday, October 9, 2017 12:57 PM
To: Cfrg
Subject: [Cfrg] Deterministic signatures, revisit?

Hi CFRG,

ia.cr/2017/975 and ia.cr/2017/985 suggest tweaks to deterministic sign= ing, eg EdDSA, due to side channels, etc. Do these tweaks merit considerati= on in CFRG?=FD (I'm not sure how important side channels are to CFRG or how= strong the tweaks are.)

Best regards,

Dan
=
--_000_2017101010233086098778575918061blackberrycom_-- From nobody Tue Oct 10 03:46: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 CB118134472 for ; Tue, 10 Oct 2017 03:46:19 -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 tlBVJZSb19Cs for ; Tue, 10 Oct 2017 03:46:17 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9B9134456 for ; Tue, 10 Oct 2017 03:46:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 243225372F; Tue, 10 Oct 2017 13:46:15 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id vOU7DAY09bGt; Tue, 10 Oct 2017 13:46:14 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 359982313; Tue, 10 Oct 2017 13:46:12 +0300 (EEST) Date: Tue, 10 Oct 2017 13:46:11 +0300 From: Ilari Liusvaara To: Dan Brown Cc: Cfrg Message-ID: <20171010104611.b3lwlawku5zh5aun@LK-Perkele-VII> References: <20171009165655.8609877.65333.18037@blackberry.com> <20171010102330.8609877.85759.18061@blackberry.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171010102330.8609877.85759.18061@blackberry.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 10 Oct 2017 10:46:20 -0000 On Tue, Oct 10, 2017 at 10:23:31AM +0000, Dan Brown wrote: > ‎http://ia.cr/2017/890 gives a theoretical reason to prefer > deterministic signatures: some proofs work better. So, my > question goes to side channels (and subversion too, but less so) > which is better at resisting them, deterministic or one of these > tweaks in the 2 eprints below? I think it depends... There are environments that do not have to care about fault attacks as long as the algorithm does not leak the key with random faults (*cough* RSA-CRT *cough*), e.g. stuff running on general purpose operating systems. However, such environments might very well care about other side channels like cache attacks. The value of defenses proposed by the paper for this are somewhat doubtful, altough those defenses would prevent trying to repeatedly scan r with the same message to sign (but proper constant-time algorithm would take care of that as well). Then there are environments that do care about fault attacks, like smartcards. These environments usually care about side channels such as timing and power analysis too. However, the sensitive parts are elsewhere, needing additional randomization beyond what was proposed in these papers. -Ilari From nobody Tue Oct 10 06:52: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 F2BA61331F2 for ; Tue, 10 Oct 2017 06:52:08 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 SCylPNa3kViP for ; Tue, 10 Oct 2017 06:52:02 -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 4417A134234 for ; Tue, 10 Oct 2017 06:52:01 -0700 (PDT) X-Spoof: Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Oct 2017 09:52:00 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 10 Oct 2017 09:52:00 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Tue, 10 Oct 2017 09:51:59 -0400 From: Dan Brown To: "ilariliusvaara@welho.com" CC: Cfrg Thread-Topic: [Cfrg] Deterministic signatures, revisit? Thread-Index: AQHTQbHSfrJSeH1XP06gGlOqYlV79KLdKaOA///uMwA= Date: Tue, 10 Oct 2017 13:51:58 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501BD099B@XMB116CNC.rim.net> References: <20171009165655.8609877.65333.18037@blackberry.com> <20171010102330.8609877.85759.18061@blackberry.com> <20171010104611.b3lwlawku5zh5aun@LK-Perkele-VII> In-Reply-To: <20171010104611.b3lwlawku5zh5aun@LK-Perkele-VII> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Deterministic signatures, revisit? 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, 10 Oct 2017 13:52:09 -0000 PCBIaSwgbXkgcmVzcG9uc2VzICg9cXVlc3Rpb25zKSBiZWxvdyAoJnNvcnJ5IGFib3V0IHRoZSBu b24tc3RhbmRhcmQgaW5kaWNhdG9ycykgPg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIFttYWlsdG86aWxhcmlsaXVzdmFhcmFAd2Vs aG8uY29tXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcgNjo0NiBBTQ0KDQpPbiBU dWUsIE9jdCAxMCwgMjAxNyBhdCAxMDoyMzozMUFNICswMDAwLCBEYW4gQnJvd24gd3JvdGU6DQo+ IOKAjmh0dHA6Ly9pYS5jci8yMDE3Lzg5MCBnaXZlcyBhIHRoZW9yZXRpY2FsIHJlYXNvbiB0byBw cmVmZXIgDQo+IGRldGVybWluaXN0aWMgc2lnbmF0dXJlczogc29tZSBwcm9vZnMgd29yayBiZXR0 ZXIuIFNvLCBteSBxdWVzdGlvbiANCj4gZ29lcyB0byBzaWRlIGNoYW5uZWxzIChhbmQgc3VidmVy c2lvbiB0b28sIGJ1dCBsZXNzIHNvKSB3aGljaCBpcyANCj4gYmV0dGVyIGF0IHJlc2lzdGluZyB0 aGVtLCBkZXRlcm1pbmlzdGljIG9yIG9uZSBvZiB0aGVzZSB0d2Vha3MgaW4gdGhlIA0KPiAyIGVw cmludHMgYmVsb3c/DQoNCkkgdGhpbmsgaXQgZGVwZW5kcy4uLg0KDQo8IC4uLiBza2lwIC4uLiA+ DQoNClRoZW4gdGhlcmUgYXJlIGVudmlyb25tZW50cyB0aGF0IGRvIGNhcmUgYWJvdXQgZmF1bHQg YXR0YWNrcywgbGlrZSBzbWFydGNhcmRzLiBUaGVzZSBlbnZpcm9ubWVudHMgdXN1YWxseSBjYXJl IGFib3V0IHNpZGUgY2hhbm5lbHMgc3VjaCBhcyB0aW1pbmcgYW5kIHBvd2VyIGFuYWx5c2lzIHRv by4gSG93ZXZlciwgdGhlIHNlbnNpdGl2ZSBwYXJ0cyBhcmUgZWxzZXdoZXJlLCBuZWVkaW5nIGFk ZGl0aW9uYWwgcmFuZG9taXphdGlvbiBiZXlvbmQgd2hhdCB3YXMgcHJvcG9zZWQgaW4gdGhlc2Ug cGFwZXJzLg0KDQo8IEFtIEkgcmlnaHQgdG8gaW50ZXJwcmV0IHlvdXIgInNlbnNpdGl2ZSAuLi4g bmVlZGluZyAuLi4gYmV5b25kIC4uLiB0aGVzZSBwYXBlcnMiIGFzIG1lYW5pbmcgeW91IGNhbiBh dHRhY2sgdGhlIHByb3Bvc2FscyBpbiB0aGUgSUFDUiBlcHJpbnRzIDIwMTcvezk3NSw5ODV9PyBP ciwgaXMgaXQganVzdCBhIGNhc2Ugb2Ygd2UgYWxyZWFkeSBnb3Qgb3RoZXIsIGxhcmdlciBwcm9i bGVtcyB0aGFuIHRoaXMgYW55d2F5PyA+DQoNCg== From nobody Mon Oct 16 08:08: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 DFA45132811 for ; Mon, 16 Oct 2017 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_AFFORDABLE=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI0y94QXCrgq for ; Mon, 16 Oct 2017 08:08:19 -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 6422213234B for ; Mon, 16 Oct 2017 08:08:19 -0700 (PDT) X-Spoof: Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2017 11:08:18 -0400 Received: from XCT196YKF.rim.net (10.2.25.4) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Oct 2017 11:08:18 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT196YKF.rim.net ([fe80::a15e:e4be:7302:3372%12]) with mapi id 14.03.0319.002; Mon, 16 Oct 2017 11:08:17 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCR4/duow Date: Mon, 16 Oct 2017 15:08:16 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 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, 16 Oct 2017 15:08:21 -0000 Hi CFRG, For those still interested, I've uploaded an Internet-Draft on ECC on 2y^2= =3Dx^3+x/GF(8^91+5): https://tools.ietf.org/html/draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-00 https://datatracker.ietf.org/doc/draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5= / It is very much a work-in-progress, maybe more so than a typical I-D. =20 If I have incorporated some CFRG list comments into the draft, then I hope = to properly acknowledge in the next update. The main point of this curve is to use it in a system of multiply-applied d= iverse crypto, where its security features (special CM curve, minimal room = for trapdoor) could complement those of other crypto algorithms (including = PQC and other ECC algorithms). Using this variant of ECC as the sole (PK) = crypto would be risky (due to lack of track-record/aegis/scrutiny/etc.). If the IETF and CFRG intend to generally pursue and encourage support of mu= ltiply-applied diverse crypto, at least where it is affordable (in the high= er user-to-user network layers?), then I would ask the CFRG to consider thi= s I-D as a work item. Otherwise, maybe this I-D should stay on the individ= ual submission stream. =20 Best regards, Dan -----Original Message----- From: Dan Brown=20 Sent: Tuesday, May 16, 2017 1:36 PM To: cfrg@irtf.org Subject: ECC mod 8^91+5 Hi all, I'm considering writing an I-D on doing ECC over the field of size 8^91+5 (=3D2^273+5), because it: ... For ECC with this field, I am also considering the special curve 2y^2=3Dx^3+x, because it: ... From nobody Mon Oct 16 22:40:33 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 9880C132D17; Mon, 16 Oct 2017 22:40:32 -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.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150821883254.21531.1671624165808113326@ietfa.amsl.com> Date: Mon, 16 Oct 2017 22:40:32 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-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: Tue, 17 Oct 2017 05:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : SPAKE2, a PAKE Authors : Watson Ladd Benjamin Kaduk Filename : draft-irtf-cfrg-spake2-04.txt Pages : 7 Date : 2017-10-16 Abstract: This Internet-Draft describes SPAKE2, a secure, efficient password based key exchange protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-spake2-04 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-spake2-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-spake2-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/ From nobody Tue Oct 17 04:18:19 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 ACF371320D9 for ; Tue, 17 Oct 2017 04:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Xwmd6ahtQb6v for ; Tue, 17 Oct 2017 04:18:13 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 7387812421A for ; Tue, 17 Oct 2017 04:18:12 -0700 (PDT) X-AuditID: 12074423-157ff700000017c9-85-59e5e6f0da0f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D8.28.06089.1F6E5E95; Tue, 17 Oct 2017 07:18:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9HBI7qA016572 for ; Tue, 17 Oct 2017 07:18:08 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9HBI4CT005277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Oct 2017 07:18:07 -0400 Date: Tue, 17 Oct 2017 06:18:04 -0500 From: Benjamin Kaduk To: cfrg@ietf.org Message-ID: <20171017111804.GP96685@kduck.kaduk.org> References: <150821883254.21531.1671624165808113326@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150821883254.21531.1671624165808113326@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUixCmqrfvx2dNIgwtvtC2O7mpjcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtIPQQUr+Sp+zXnH3MA4nbuLkZNDQsBE4t2/NyxdjFwcQgKL mSRuHOtgBUkICRxllFh4ThIi8ZJJYvXt/ewgCRYBVYnta78xgdhsAioSDd2XmbsYOThEBAQl OtbIgISFBWwl3u18ABbmBVow+0wuxEhniTONn1hAbF6g6pMzn4DZzAJaEjf+vWQCKWcWkJZY /o8DJMwp4CKx/kY3G4gtKqAsMW/fKrYJjPyzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd 4uTEvLzUIl0zvdzMEr3UlNJNjKCQY3dR3sH4ss/7EKMAB6MSD2/GoSeRQqyJZcWVuYcYJTmY lER5nQ2BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4d916GinEm5JYWZValA+TkuZgURLn3Ra0 K1JIID2xJDU7NbUgtQgmK8PBoSTB6/QUqFGwKDU9tSItM6cEIc3EwQkynAdoeDBIDW9xQWJu cWY6RP4Uo6KUOO8lkIQASCKjNA+uF5QSJLL317xiFAd6RRiiigeYTuC6XwENZgIavM7pCcjg kkSElFQDY87ukyYarWeEHOSc169Sc159W13zLSuf7RmVuae+Kl+NqWqvVJhyIXl27URWga83 ZvV/qpWdPOv7FB7VtA+HFm/4LtKz+5QPR+WWJxzfuP9PZWJ7yGfQKfs6hP/38oV+nzhD5n3z vBXM6HPnnNiROVyht169KErOrJFsnGx5dk7ztetvvbZe/6LEUpyRaKjFXFScCACEYC/65AIA AA== Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-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: Tue, 17 Oct 2017 11:18:19 -0000 This version is intended to have minimal changes from the -03, and was intended to un-expire the draft and add me as editor to effect that change. I want this draft to advance so that it can be used as a reference by draft-ietf-kitten-krb-spake-preauth. There is some reformatting due to having to rewrite the source into XML, and I took advantage of that opportunity to un-wrap the python snippet. -Ben On Mon, Oct 16, 2017 at 10:40:32PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Crypto Forum RG of the IRTF. > > Title : SPAKE2, a PAKE > Authors : Watson Ladd > Benjamin Kaduk > Filename : draft-irtf-cfrg-spake2-04.txt > Pages : 7 > Date : 2017-10-16 > > Abstract: > This Internet-Draft describes SPAKE2, a secure, efficient password > based key exchange protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-cfrg-spake2-04 > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-spake2-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-spake2-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/ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Oct 20 10:10:19 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 6D0B61342E8 for ; Fri, 20 Oct 2017 10:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YvY71_H2MBL9 for ; Fri, 20 Oct 2017 10:10:17 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 D18541342E3 for ; Fri, 20 Oct 2017 10:10:16 -0700 (PDT) X-AuditID: 1209190e-05fff70000001112-db-59ea2df7282d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D4.59.04370.7FD2AE95; Fri, 20 Oct 2017 13:10:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v9KHAEc3017708; Fri, 20 Oct 2017 13:10:15 -0400 Received: from [18.101.8.86] (VPN-18-101-8-86.MIT.EDU [18.101.8.86]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9KHACKD013867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Oct 2017 13:10:13 -0400 To: Benjamin Kaduk , cfrg@ietf.org References: <150821883254.21531.1671624165808113326@ietfa.amsl.com> <20171017111804.GP96685@kduck.kaduk.org> From: Greg Hudson Message-ID: Date: Fri, 20 Oct 2017 13:10:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171017111804.GP96685@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrPtd91WkQUe7kcXRXW0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPQ7oOCRUMXsrnXMDYzf+boYOTkkBEwkuldeZ+li5OIQEljM JNH8sZEZwtnIKHF4cRNU5hCTxMGPkxhBWoQFbCXe7XzADGKLCBhKXPrdygZiCwnkScyf9Qws ziagLLF+/1agZg4OXgEriY3T3EHCLAKqEj/WXwErERWIkHjYuYsdxOYVEJQ4OfMJC4jNKWAq ceD2FLAaZgE9iR3Xf7FC2PIS29/OYZ7AyD8LScssJGWzkJQtYGRexSibklulm5uYmVOcmqxb nJyYl5dapGusl5tZopeaUrqJERx6knw7GCc1eB9iFOBgVOLhrRB7FSnEmlhWXJl7iFGSg0lJ lDew8mWkEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeHWpA5bwpiZVVqUX5MClpDhYlcd5tQbsi hQTSE0tSs1NTC1KLYLIyHBxKEryPdIAaBYtS01Mr0jJzShDSTBycIMN5gIbPAqnhLS5IzC3O TIfIn2JUlBLnfQ2SEABJZJTmwfWCU0MqR9grRnGgV4R5GYGJQogHmFbgul8BDWYCGsxu/wJk cEkiQkqqgXHJ9/lPOO/fP8pV1/BiT9eiZ8/dKg6IvnG0MZfZcHf2Sds8iQNVDBPeZQq5Xy8y /dsX/XP19CvnT36Z0JRyZU7BKs81UnmuL2+Euxp/Si8vey8WslH73YTpwubK/Ut2rP1ttrd3 yf3Tx06JR5b4aj9apbu+0+DtTpHEfWZXV+hZ/3E+NMHf8MEZJZbijERDLeai4kQAlrrgEegC AAA= Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-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: Fri, 20 Oct 2017 17:10:18 -0000 On 10/17/2017 07:18 AM, Benjamin Kaduk wrote: > This version is intended to have minimal changes from the -03, and was > intended to un-expire the draft and add me as editor to effect that change. > I want this draft to advance so that it can be used as a reference by > draft-ietf-kitten-krb-spake-preauth. > > There is some reformatting due to having to rewrite the source into XML, > and I took advantage of that opportunity to un-wrap the python snippet. Thanks. I found my old feedback on this draft in https://www.ietf.org/mail-archive/web/cfrg/current/msg07928.html and this update resolves one of those issues (the misformatted Python code). I do not know how to resolve the problem that SPAKE2+ doesn't use w0 or w1 in the transcript hash, and therefore more closely resembles SPAKE1 than SPAKE2. I suggest the following edits for the other issues: * In section 2.2, remove the spaces around the || operators starting after K. * In section 2.3, replaces "here Bob" with "here B". * In the Python code, replace "ec.canon_pointstr" with "canon_pointstr". * Replace the introductory text of section 3 with: Every curve presented in the table below has an OID from [RFC5480]. We construct a string using the OID and the needed constant, for instance "1.3.132.0.35 point generation seed (M)" for P-512. This string is turned into a series of blocks by hashing with SHA256, and hashing that output again to generate the next 32 bytes, and so on. This pattern is repeated for each group and value, with the string modified appropriately. A byte string of length equal to that of an encoded group element is constructed by concatenating as many blocks as are required, starting from the first block, and truncating to the desired length. The byte string is then formatted as required for the group. In the case of Weierstrass curves, this means setting the first byte to 0x02 or 0x03 depending on the low-order bit. For Ed25519 style formats this means taking all the bytes as the representation of the group element. The byte string is then interpreted as an element in the group. If this interpretation yields a valid group element with the correct order (p), the byte string is the output. Otherwise, the initial hash block is discarded and the process is repeated until a valid element is found. From nobody Fri Oct 20 17:24:29 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 EDAF0134474; Fri, 20 Oct 2017 17:24:11 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545196.20809.1600025989998746887.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:11 -0700 Archived-At: Subject: [Cfrg] cfrg - Requested session has been scheduled for IETF 100 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, 21 Oct 2017 00:24:12 -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) Wednesday, Afternoon Session II 1520-1650 Room Name: VIP A size: 100 --------------------------------------------- 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 dcrup jmap Second Priority: 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 Sat Oct 21 10:28:42 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 1DB0A1320DC for ; Sat, 21 Oct 2017 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.98 X-Spam-Level: X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no 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 VJJ2aG3zHAEe for ; Sat, 21 Oct 2017 10:28:37 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20073.outbound.protection.outlook.com [40.107.2.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5371241F3 for ; Sat, 21 Oct 2017 10:28:36 -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=J2SnRDklokws+/3cLQ+q/nr271HM1OXIZm7To9M/pOk=; b=cqrdDRdRXDoiAFDI/A+7n1XaWY5oNaiW+Bne/wQjEStX0eGffmTuU31AM6nj11hk9mgI5moeCqOT4iJ/HtijzHusWKdckHuxv3Vf3vlC1a3IMIezOl5zOjgyzxBf7Rqe7kSW+zhFCnLOL51fkahpIllPQo2jHLZMjso0BWFqDeI= 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_256_CBC_SHA384_P256) id 15.20.77.7; Sat, 21 Oct 2017 17:28:33 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a90a:8fa5:3111:efe]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a90a:8fa5:3111:efe%13]) with mapi id 15.20.0077.023; Sat, 21 Oct 2017 17:28:33 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC mod 8^91+5 Thread-Index: AQHTSpIE07qAfhqOwEC/NqGWGcty2Q== Date: Sat, 21 Oct 2017 17:28:33 +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: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [134.219.215.127] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 6:tkVuxhRSumDGYlPzeOazjEcZ10k01/OdQKvo4l2wUa702fkCQcCKuus/Vsvd7iHUxQNxYt/d550Nr0ZepdF8fMBSRUS8OsVFxTOSzaY8+y/3MSbIFB4i8hjTknG2j8yIRMVbMGKfRa2vWDxSwa4ljqNi8xjkt/4yEdy8ztSC2QrgSbiYNgBYMF97eHk6D0Y/zXgDrpSgs0BwtWO8752B94x6OvYb6+/iSohn5B7qhfvNidROyg3F13KW5dlpcPgk6t0GeG63WHXl7ijIjOL0F52QwCIKLfEaD3IKXGrIsQU8WyKXKyvpnEvn1aNvJmikcXzZAZ5O0z3D5kTM4movOg==; 5:Nc+5YlEhsx4oJrdkKZcOS7q8UOAffZhsCPdJiRlc2TFmkdtGUqWimvtgKS1/S7aMDC10d6I/W5YJypvzPpSPXBw8HjPujTucXqXFR+zuazuY1mcg6cedGdOuNE5JQTFrW3Ik0vf2MQV4j8jFgaIkHw==; 24:rOKIc7aj3TZOldKJ3iKMd1wdOZLqub8dK0vKudfSNw7ZHEj3HO27aouNPv8+S0HWVtTwJBPekNYpxNFtxBtOBSwe/dYWh+OeulBY8P9dEHw=; 7:DshH5D0k38ZHzKbW15GWhjj/6nQ7PLEyydrwnZbnmzb+pMQprTd06SZHSFptABnze3/pY5RlwloFX4RISlcTyJ9o0RtPAbYfYxmXwZq6u0sB5OQsm2/LTZTTLD5yUK/v7TmXpqdxkRwNQcc0a/iHoEFQk/iUldGFyYo235HcR86CnGMMUBFCyiP+kXUTHgb0f4Upe2ss2WxEDwmtmP+hWiiEweMskdI0q7DkxiR4TjE= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(346002)(376002)(24454002)(13464003)(53754006)(189002)(199003)(2351001)(189998001)(81166006)(8936002)(3846002)(25786009)(8676002)(1730700003)(81156014)(2501003)(5250100002)(6916009)(42882006)(86362001)(7736002)(66066001)(2900100001)(106356001)(5660300001)(102836003)(6116002)(105586002)(101416001)(50986999)(54356999)(3660700001)(36756003)(3280700002)(68736007)(2906002)(74482002)(97736004)(478600001)(53546010)(83506002)(72206003)(413944005)(14454004)(6246003)(316002)(229853002)(5640700003)(6512007)(99286003)(6306002)(53936002)(6436002)(6506006)(6486002)(786003)(305945005)(58126008)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: d2e486d6-5810-4f96-819f-08d518a927a8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(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: 046753C63C received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8F9766DFCC565C4DB072E3C52943E767@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2017 17:28:33.6218 (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] ECC mod 8^91+5 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, 21 Oct 2017 17:28:40 -0000 RGVhciBDRlJHLA0KDQpEYW4gaGFzIHNwZWNpZmljYWxseSBhc2tlZCBmb3IgQ0ZSRyBhZG9wdGlv biBvZiBoaXMgZHJhZnQuIEFueSBzdXBwb3J0IGZvcg0KdGhpcyBmcm9tIHRoZSBncm91cD8NCg0K Q2hlZXJzLA0KDQpLZW5ueSANCg0KT24gMTYvMTAvMjAxNyAxNjowOCwgIkNmcmcgb24gYmVoYWxm IG9mIERhbiBCcm93biIgPGNmcmctYm91bmNlc0BpcnRmLm9yZw0Kb24gYmVoYWxmIG9mIGRhbmli cm93bkBibGFja2JlcnJ5LmNvbT4gd3JvdGU6DQoNCj5IaSBDRlJHLA0KPg0KPkZvciB0aG9zZSBz dGlsbCBpbnRlcmVzdGVkLCBJJ3ZlIHVwbG9hZGVkIGFuIEludGVybmV0LURyYWZ0IG9uIEVDQyBv bg0KPjJ5XjI9eF4zK3gvR0YoOF45MSs1KToNCj4NCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnJvd24tZWMtMnkyLXgzLXgtbW9kLTgtdG8tOTEtcGx1cy01LTAwDQo+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnJvd24tZWMtMnkyLXgzLXgtbW9kLTgt dG8tOTEtcGx1cy0NCj41Lw0KPg0KPkl0IGlzIHZlcnkgbXVjaCBhIHdvcmstaW4tcHJvZ3Jlc3Ms IG1heWJlIG1vcmUgc28gdGhhbiBhIHR5cGljYWwgSS1ELg0KPg0KPklmIEkgaGF2ZSBpbmNvcnBv cmF0ZWQgc29tZSBDRlJHIGxpc3QgY29tbWVudHMgaW50byB0aGUgZHJhZnQsIHRoZW4gSQ0KPmhv cGUgdG8gcHJvcGVybHkgYWNrbm93bGVkZ2UgaW4gdGhlIG5leHQgdXBkYXRlLg0KPg0KPlRoZSBt YWluIHBvaW50IG9mIHRoaXMgY3VydmUgaXMgdG8gdXNlIGl0IGluIGEgc3lzdGVtIG9mIG11bHRp cGx5LWFwcGxpZWQNCj5kaXZlcnNlIGNyeXB0bywgd2hlcmUgaXRzIHNlY3VyaXR5IGZlYXR1cmVz IChzcGVjaWFsIENNIGN1cnZlLCBtaW5pbWFsDQo+cm9vbSBmb3IgdHJhcGRvb3IpIGNvdWxkIGNv bXBsZW1lbnQgdGhvc2Ugb2Ygb3RoZXIgY3J5cHRvIGFsZ29yaXRobXMNCj4oaW5jbHVkaW5nIFBR QyBhbmQgb3RoZXIgRUNDIGFsZ29yaXRobXMpLiAgVXNpbmcgdGhpcyB2YXJpYW50IG9mIEVDQyBh cw0KPnRoZSBzb2xlIChQSykgY3J5cHRvIHdvdWxkIGJlIHJpc2t5IChkdWUgdG8gbGFjayBvZg0K PnRyYWNrLXJlY29yZC9hZWdpcy9zY3J1dGlueS9ldGMuKS4NCj4NCj5JZiB0aGUgSUVURiBhbmQg Q0ZSRyBpbnRlbmQgdG8gZ2VuZXJhbGx5IHB1cnN1ZSBhbmQgZW5jb3VyYWdlIHN1cHBvcnQgb2YN Cj5tdWx0aXBseS1hcHBsaWVkIGRpdmVyc2UgY3J5cHRvLCBhdCBsZWFzdCB3aGVyZSBpdCBpcyBh ZmZvcmRhYmxlIChpbiB0aGUNCj5oaWdoZXIgdXNlci10by11c2VyIG5ldHdvcmsgbGF5ZXJzPyks IHRoZW4gSSB3b3VsZCBhc2sgdGhlIENGUkcgdG8NCj5jb25zaWRlciB0aGlzIEktRCBhcyBhIHdv cmsgaXRlbS4gIE90aGVyd2lzZSwgbWF5YmUgdGhpcyBJLUQgc2hvdWxkIHN0YXkNCj5vbiB0aGUg aW5kaXZpZHVhbCBzdWJtaXNzaW9uIHN0cmVhbS4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+RGFu DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBEYW4gQnJvd24gDQo+U2Vu dDogVHVlc2RheSwgTWF5IDE2LCAyMDE3IDE6MzYgUE0NCj5UbzogY2ZyZ0BpcnRmLm9yZw0KPlN1 YmplY3Q6IEVDQyBtb2QgOF45MSs1DQo+DQo+SGkgYWxsLA0KPg0KPkknbSBjb25zaWRlcmluZyB3 cml0aW5nIGFuIEktRCBvbiBkb2luZyBFQ0Mgb3ZlciB0aGUgZmllbGQgb2Ygc2l6ZQ0KPiAgIDhe OTErNSAgICAoPTJeMjczKzUpLA0KPmJlY2F1c2UgaXQ6DQo+Li4uDQo+DQo+Rm9yIEVDQyB3aXRo IHRoaXMgZmllbGQsIEkgYW0gYWxzbyBjb25zaWRlcmluZyB0aGUgc3BlY2lhbCBjdXJ2ZQ0KPiAg IDJ5XjI9eF4zK3gsDQo+YmVjYXVzZSBpdDoNCj4uLi4NCj4NCj4NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNmcmcgbWFpbGluZyBsaXN0DQo+ Q2ZyZ0BpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Zy Zw0KDQo= From nobody Sat Oct 21 11:03: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 980CA1320DC for ; Sat, 21 Oct 2017 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, 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 sDRlClYbnqJE for ; Sat, 21 Oct 2017 11:03:26 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B84A13219B for ; Sat, 21 Oct 2017 11:03:26 -0700 (PDT) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 21 Oct 2017 20:03:23 +0200 id 0000000000000010.0000000059EB8BEB.00001419 Date: Sat, 21 Oct 2017 20:03:21 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: cfrg@irtf.org Message-ID: <20171021200321.38549d9a@pc1> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 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, 21 Oct 2017 18:03:29 -0000 On Mon, 16 Oct 2017 15:08:16 +0000 Dan Brown wrote: > The main point of this curve is to use it in a system of > multiply-applied diverse crypto, where its security features (special > CM curve, minimal room for trapdoor) could complement those of other > crypto algorithms (including PQC and other ECC algorithms). Using > this variant of ECC as the sole (PK) crypto would be risky (due to > lack of track-record/aegis/scrutiny/etc.). People rarely do multi-crypto these days, and if they do they usually have good reasons. I don't see those reasons here. As we all remember we had a very lengthy discussion about new ECC curves not so long ago. New curves were standardized with what many people consider desirable security properties. As you indicate some people want to combine that with pqc. In this case multi-crypto makes sense, because it can give you something that you can't have in a single algorithm: well-tested crypto and postquantum crypto. But standardizing yet another new ecc method seems a rather obscure threat scenario. You'd assume that you use multiple ECC methods and there's a security flaw that affects all others, but not your new curve. If you feel you want multiple different standardized ECC methods you can already use nist ecc + c25519 in combination. I'm not aware that anyone is doing this. In general I feel it's not desirable to have as many standardized algorithms as possible, as it only complicates algorithm choices. A new algorithm should always have good reasoning for its existence. Therefore I'm against standardizing this unless further arguments are brought up why it's advantageous compared to existing standardized ecc schemes. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Sat Oct 21 15:07: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 C8B48133715 for ; Sat, 21 Oct 2017 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 zWewOUHWPqyz for ; Sat, 21 Oct 2017 15:06:58 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 D909B1204DA for ; Sat, 21 Oct 2017 15:06:58 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9LM1l0h018497; Sat, 21 Oct 2017 23:06:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hV5FojfF5EyezgKv22c2aNr39sUS1uUwR3kW0iOvnxA=; b=hf0Vd664l/kysNLfMvDgwNB8rQ6jh9w158I59/S06r1bhyocYLiB4nOBv82QJoX8JPQO iBvtEIknA1NUqR6P9TYEqYZ6TJna0E+zmIaPyH2aaLQsjLsRya5eXphNVRuyF4kaBO1f cYUcaS8Nn6TqKl9B+tZQ2wL8G/MzyIew24ttEO/aNI8+C6rHsB6QkQDgOmUS4Vj31x+c sQ5H/D9cXdXwjdlZVt2f+6O7GEwDnuF5UNSVjz1wP6R0SC/aOxCl9jrN7RbC3A3VWStW +XAuKoCUB+CkWz/EolxwnINb6KxWXdcULZOV4YCNKrZ6HLFBg01YFQwlcZMaJxf4oDTC dw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dqwg4j3jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Oct 2017 23:06:52 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9LM6nA2010958; Sat, 21 Oct 2017 18:06:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju1bgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 21 Oct 2017 18:06:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 21 Oct 2017 18:06:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 21 Oct 2017 18:06:50 -0400 From: "Salz, Rich" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "cfrg@irtf.org" Thread-Topic: [Cfrg] ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCR4/duowAQrbcYAACIDpAA== Date: Sat, 21 Oct 2017 22:06:50 +0000 Message-ID: <85F11BFB-0A01-4EC1-AD2D-2574CF4973A1@akamai.com> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501BD8D19@XMB116CNC.rim.net> <20171021200321.38549d9a@pc1> In-Reply-To: <20171021200321.38549d9a@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.143] Content-Type: text/plain; charset="utf-8" Content-ID: <78CFD2BA04CA1449B70972B2851B9EA0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-21_06:, , 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-1707230000 definitions=main-1710210321 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710210320 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 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, 21 Oct 2017 22:07:00 -0000 QXQgZmlyc3QgSSB3YXMgb3Bwb3NlZCwgdW50aWwgSSByZWFkIEhhbm5v4oCZcyBub3RlLiAgQ0ZS RyBkb2VzbuKAmXQgZG8gc3RhbmRhcmRpemF0aW9uLCBpdCB3b3VsZCBiZSB1cCBmb3Igc29tZSBv dGhlciBXRyB0byBwaWNrIHRoaXMgdXAgYW5kIHVzZSBpdC4gIEkgZG9u4oCZdCB0aGluayBpdOKA mXMgbGlrZWx5LCBidXQgdGhhdOKAmXMgbm90IGZvciBDRlJHIHRvIGRlY2lkZSwgaXMgaXQ/DQoN Ck9uIHRoZSBvdGhlciBoYW5kLCBJIHN0aWxsIGRvbuKAmXQgc2VlIHdoeSwgYnV0IGlmIHNvbWVv bmUgd2FudHMgdG8gZG8gcmVzZWFyY2ggdmlhIENGUkcgSSBkb27igJl0IHNlZSB3aHkgbm90Lg0K IA0KDQo= From nobody Sat Oct 21 15:18: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 278EF1337FD for ; Sat, 21 Oct 2017 15:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_MED=-2.3, 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 zrpSUntItGEj for ; Sat, 21 Oct 2017 15:18:39 -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 5341513371A for ; Sat, 21 Oct 2017 15:18:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1704BED9; Sat, 21 Oct 2017 23:18:36 +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 7z1PZoPbT180; Sat, 21 Oct 2017 23:18:33 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E09BCBED6; Sat, 21 Oct 2017 23:18:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508624313; bh=IvguoDSccCAv9OYgMs5qTwb0JhW+NDRL8LGTaFGSbSw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=j8iiYGG4t4lhg5PIcJ8BgKB6quV27mvp7NdHpqHAi0YiAOsCp+wzb6dJKgwRIkphk RCQIkyhlDYpYeqAb0AUvlaYKhB8KWvux1gCPyv3krX+G5/awuPSazkeNvFnpEaVRUW 3OZHjefbyNPvPnXoRzsik2cQeEbvwJcTv2GkKouY= To: "Paterson, Kenny" , "cfrg@irtf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7de7999a-97ec-8ea7-6abb-69b18c784374@cs.tcd.ie> Date: Sat, 21 Oct 2017 23:18:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F6BNA42lG8aaSe81Gj6VE55xJKFbirCn9" Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 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, 21 Oct 2017 22:18:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F6BNA42lG8aaSe81Gj6VE55xJKFbirCn9 Content-Type: multipart/mixed; boundary="hMF0QXUbQU3XMBTKWG4O1OO9SFq4kbW8N"; protected-headers="v1" From: Stephen Farrell To: "Paterson, Kenny" , "cfrg@irtf.org" Message-ID: <7de7999a-97ec-8ea7-6abb-69b18c784374@cs.tcd.ie> Subject: Re: [Cfrg] ECC mod 8^91+5 References: In-Reply-To: --hMF0QXUbQU3XMBTKWG4O1OO9SFq4kbW8N Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I'd have no objection to CFRG producing an RFC for this, if there is support. I don't support doing so myself, but if the RG do go ahead with that I would really hope that the resulting RFC is clearly cast as not being as "preferred" as the curves already documented. If additional curves were to be documented by CFRG without such distinctions, then I would object to that on the grounds that the inevitable confusion arising would devalue CFRG for the IETF at least. So, while I'm not qualified wrt the crypt details myself, I'd prefer to not see this adopted. If it is adopted, I'd strongly argue that it be flagged as being less preferred vs. the currently documented curves. S. On 21/10/17 18:28, Paterson, Kenny wrote: > Dear CFRG, >=20 > Dan has specifically asked for CFRG adoption of his draft. Any support = for > this from the group? >=20 > Cheers, >=20 > Kenny=20 >=20 > On 16/10/2017 16:08, "Cfrg on behalf of Dan Brown" on behalf of danibrown@blackberry.com> wrote: >=20 >> Hi CFRG, >> >> For those still interested, I've uploaded an Internet-Draft on ECC on >> 2y^2=3Dx^3+x/GF(8^91+5): >> >> https://tools.ietf.org/html/draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5= -00 >> https://datatracker.ietf.org/doc/draft-brown-ec-2y2-x3-x-mod-8-to-91-p= lus- >> 5/ >> >> It is very much a work-in-progress, maybe more so than a typical I-D. >> >> If I have incorporated some CFRG list comments into the draft, then I >> hope to properly acknowledge in the next update. >> >> The main point of this curve is to use it in a system of multiply-appl= ied >> diverse crypto, where its security features (special CM curve, minimal= >> room for trapdoor) could complement those of other crypto algorithms >> (including PQC and other ECC algorithms). Using this variant of ECC a= s >> the sole (PK) crypto would be risky (due to lack of >> track-record/aegis/scrutiny/etc.). >> >> If the IETF and CFRG intend to generally pursue and encourage support = of >> multiply-applied diverse crypto, at least where it is affordable (in t= he >> higher user-to-user network layers?), then I would ask the CFRG to >> consider this I-D as a work item. Otherwise, maybe this I-D should st= ay >> on the individual submission stream. >> >> Best regards, >> >> Dan >> >> -----Original Message----- >> From: Dan Brown=20 >> Sent: Tuesday, May 16, 2017 1:36 PM >> To: cfrg@irtf.org >> Subject: ECC mod 8^91+5 >> >> Hi all, >> >> I'm considering writing an I-D on doing ECC over the field of size >> 8^91+5 (=3D2^273+5), >> because it: >> ... >> >> For ECC with this field, I am also considering the special curve >> 2y^2=3Dx^3+x, >> because it: >> ... >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 --hMF0QXUbQU3XMBTKWG4O1OO9SFq4kbW8N-- --F6BNA42lG8aaSe81Gj6VE55xJKFbirCn9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ68e4AAoJEC88hzaAX42i6fgH/2O1AoFrpUO8DcQB7ZPttxd5 Z9eoYgdUBkgveGoVSztM/jVi3ibUQF3weSZWJ122gPJYoFotDA5NGgUWq9bg+Gqq pcKneOeFPeDF8QbAL1mmJcVrjrRNMF1DiAf9nzV41bpBRz+/MPX9+qclhgEXyriG G1eO0SS1uivMTPK7NQf1C48D+JpBmqaFlSakGbmc2NBVlpGqAW/RYNW5HlQwWe18 dCditbuRglBEESLdmcx/Si2La3kpuNCJr50GYMs0Kglkl83FKks49yR72AylwtO4 4Bl0Q+KDf1ntY5SO+LCGRbpxsP8Jk/v/ZnVRdoNTp3xW+bEeCj3mGKEp4q3ucJc= =3rzV -----END PGP SIGNATURE----- --F6BNA42lG8aaSe81Gj6VE55xJKFbirCn9-- From nobody Mon Oct 23 20:30:15 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 587F713AB3E for ; Mon, 23 Oct 2017 20:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Dgmz6tG24bHQ for ; Mon, 23 Oct 2017 20:30:13 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 B5CA2139203 for ; Mon, 23 Oct 2017 20:30:12 -0700 (PDT) X-AuditID: 12074422-0e7ff700000071a4-75-59eeb3c11858 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.BC.29092.2C3BEE95; Mon, 23 Oct 2017 23:30:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9O3U5d8029384; Mon, 23 Oct 2017 23:30:06 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9O3U1gf007158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2017 23:30:04 -0400 Date: Mon, 23 Oct 2017 22:30:01 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: cfrg@ietf.org Message-ID: <20171024033001.GQ96685@kduck.kaduk.org> References: <150821883254.21531.1671624165808113326@ietfa.amsl.com> <20171017111804.GP96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrnto87tIg9bX+hZHd7WxODB6LFny kymAMYrLJiU1J7MstUjfLoErY9r0F2wF/ZwVP9eeZWlgXMTexcjJISFgIrHvw222LkYuDiGB xUwSV25sZ4RwNjJKHNzWxAhSJSRwlUni/iaWLkYODhYBVYmb0zJBwmwCKhIN3ZeZQWwRAUWJ Z6vmgpUwCwhKPJtqARIWFrCVeLfzAVgJL9CuFZfOM0FMnM8ocWmBOERcUOLkzCcsIDazgJbE jX8vmSDGSEss/8cBEuYUsJb49ncNWKuogLLEvH2r2CYwCsxC0j0LSfcshO4FjMyrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgoPRRWkH48R/XocYBTgYlXh4b1i+ixRiTSwr rsw9xCjJwaQkyvs7522kEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeSE+gct6UxMqq1KJ8mJQ0 B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCd7+TUCNgkWp6akVaZk5JQhpJg5OkOE8QMOt QWp4iwsSc4sz0yHypxh1OZ7NfN3ALMSSl5+XKiXO2wNSJABSlFGaBzcHlEQksvfXvGIUB3pL mPcySBUPMAHBTXoFtIQJaIms/RuQJSWJCCmpBkamvEzpuW9FbZx1ZyldPMZy87jhPN3iKT5h 8bUNHluO/xe41fgn8Y9vqHbur4nZJtZRTY/Kph44Mu+X1MQ5wmnJi3SX5+9/eUF/ZvCZu5zc ARP09C+dE9t3ojTqe6PI17sal1oDM7IsNu7lOFq57OGtd667/jdfSA/rUPnCfmf/15hm5mm1 G1uUWIozEg21mIuKEwHPsrZj/QIAAA== Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-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: Tue, 24 Oct 2017 03:30:14 -0000 Hi Greg, On Fri, Oct 20, 2017 at 01:10:12PM -0400, Greg Hudson wrote: > On 10/17/2017 07:18 AM, Benjamin Kaduk wrote: > > This version is intended to have minimal changes from the -03, and was > > intended to un-expire the draft and add me as editor to effect that change. > > I want this draft to advance so that it can be used as a reference by > > draft-ietf-kitten-krb-spake-preauth. > > > > There is some reformatting due to having to rewrite the source into XML, > > and I took advantage of that opportunity to un-wrap the python snippet. > > Thanks. I found my old feedback on this draft in > https://www.ietf.org/mail-archive/web/cfrg/current/msg07928.html and > this update resolves one of those issues (the misformatted Python code). > > I do not know how to resolve the problem that SPAKE2+ doesn't use w0 or > w1 in the transcript hash, and therefore more closely resembles SPAKE1 > than SPAKE2. I suggest the following edits for the other issues: Thanks for pulling up your old review comments. I do plan to go through the archives to see if there were any other outstanding review comments, for the next revision. -Ben From nobody Tue Oct 24 07:33: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 E2A1113F7F1 for ; Tue, 24 Oct 2017 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 Hg2dcfxBwzrV for ; Tue, 24 Oct 2017 07:33:42 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 F1BE713F3CC for ; Tue, 24 Oct 2017 07:33:41 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j2so13513600vki.4 for ; Tue, 24 Oct 2017 07:33:41 -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=5m0N7KPtmO8nWwna/JJ7hIc1mEcsBi/8FmGj8qL7J48=; b=HGbHXMFxA2zrXSoAzjKeC1xhYIElhg7FcNTHtB2K8vyMLjZlijau4nQOFiF6GiL8Kd TNbwvrcssSQ0YahR0SUnzv2xO6a2yT2jwY6EFkzSkIIT0QXsPsASpU/vnpmGlMi0X6AN 5hfU5wLdvVBsZFMXYmMp/qZU/0V+NqaGGFOkycvzAVa38DcufgkgzCCf2Wlo2bVThvEe X4AOtwXOoQMFvwUGOO4DXV/maF+w10PHwMQHWfh8pEGO1r6V+/SSoctQvdxvjjXnLmhm A57ZLPEs6usLgRLgtvHwESS3K2txcKvGcqxq8juwrc67z7WUG0X2xFYTy5lz6C9UDEg1 2zqQ== 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=5m0N7KPtmO8nWwna/JJ7hIc1mEcsBi/8FmGj8qL7J48=; b=EMAc18UliBQgDwJP3f3WP/tHinwuzxFzkBCIryep9mPHqyQcunmRvdXETsdT5+vDp1 p7A79DJrwzSXCZ+nOHslRy001dABbhqQc+d7N63D62M+iswFCKZqOqXkfmQIp2V3iCj9 Eyx9WKFj36plz88vTPzeid8Q3XLdL+7YW3jb/+IoAvcGzxba1hDP8L+ygO+Eo9kHedAS dL9DauHGTqtSlgaqio08dhejMd75zQRGtCQE7h04KlgczFkY5VpFDq1Nz5YdINHMe7qK MbOn25M6zpXvEMo6lgF2WhsbVcrbnEIre5L2sbFeftg48Oo5PPwCu2TzNs++ENJFdWHu tvag== X-Gm-Message-State: AMCzsaWb++1VDKNs1YzMuaeT7nnI8Kmsz1Cmn0zHSBgyd3gHKtpBj5cl j9VZLfW0UoTWavP62+/eZqvd1vvJBwfxU2l9LPo= X-Google-Smtp-Source: ABhQp+Swk1LnthxtFMtDXKonXSK+AUtWSF7cJpTwNAAsLxmPqc+KswmKK5kGQqfOA/eHUz/qw6SVwdgs0gCcFLqlyUk= X-Received: by 10.31.218.193 with SMTP id r184mr1735944vkg.92.1508855620864; Tue, 24 Oct 2017 07:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Tue, 24 Oct 2017 07:33:40 -0700 (PDT) In-Reply-To: References: <150821883254.21531.1671624165808113326@ietfa.amsl.com> <20171017111804.GP96685@kduck.kaduk.org> From: Watson Ladd Date: Tue, 24 Oct 2017 07:33:40 -0700 Message-ID: To: Greg Hudson Cc: Benjamin Kaduk , "cfrg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07b1f84c8fc4055c4bd301" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-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: Tue, 24 Oct 2017 14:33:49 -0000 --94eb2c07b1f84c8fc4055c4bd301 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 20, 2017 at 10:10 AM, Greg Hudson wrote: > On 10/17/2017 07:18 AM, Benjamin Kaduk wrote: > > This version is intended to have minimal changes from the -03, and was > > intended to un-expire the draft and add me as editor to effect that > change. > > I want this draft to advance so that it can be used as a reference by > > draft-ietf-kitten-krb-spake-preauth. > > > > There is some reformatting due to having to rewrite the source into XML, > > and I took advantage of that opportunity to un-wrap the python snippet. > > Thanks. I found my old feedback on this draft in > https://www.ietf.org/mail-archive/web/cfrg/current/msg07928.html and > this update resolves one of those issues (the misformatted Python code). > > I do not know how to resolve the problem that SPAKE2+ doesn't use w0 or > w1 in the transcript hash, and therefore more closely resembles SPAKE1 > than SPAKE2. I suggest the following edits for the other issues: > Yeah, I'll have to look at the source (SPAKE2+ comes from an upublished book...) > > * In section 2.2, remove the spaces around the || operators starting > after K. > > * In section 2.3, replaces "here Bob" with "here B". > > * In the Python code, replace "ec.canon_pointstr" with "canon_pointstr". > > * Replace the introductory text of section 3 with: > > Every curve presented in the table below has an OID from [RFC5480]. > We construct a string using the OID and the needed constant, for > instance "1.3.132.0.35 point generation seed (M)" for P-512. This > string is turned into a series of blocks by hashing with SHA256, and > hashing that output again to generate the next 32 bytes, and so on. > This pattern is repeated for each group and value, with the string > modified appropriately. > > A byte string of length equal to that of an encoded group element is > constructed by concatenating as many blocks as are required, > starting from the first block, and truncating to the desired length. > The byte string is then formatted as required for the group. In the > case of Weierstrass curves, this means setting the first byte to > 0x02 or 0x03 depending on the low-order bit. For Ed25519 style > formats this means taking all the bytes as the representation of the > group element. The byte string is then interpreted as an element in > the group. If this interpretation yields a valid group element with > the correct order (p), the byte string is the output. Otherwise, > the initial hash block is discarded and the process is repeated > until a valid element is found. > Thanks for you comments > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > -- "Man is born free, but everywhere he is in chains". --Rousseau. --94eb2c07b1f84c8fc4055c4bd301 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Oct 20, 2017 at 10:10 AM, Greg Hudson <ghudson@mit.edu> wrote:
On 10/17/2017 0= 7:18 AM, Benjamin Kaduk wrote:
> This version is intended to have minimal changes from the -03, and was=
> intended to un-expire the draft and add me as editor to effect that ch= ange.
> I want this draft to advance so that it can be used as a reference by<= br> > draft-ietf-kitten-krb-spake-preauth.
>
> There is some reformatting due to having to rewrite the source into XM= L,
> and I took advantage of that opportunity to un-wrap the python snippet= .

Thanks.=C2=A0 I found my old feedback on this draft in
https://www.ietf.org/mail-archi= ve/web/cfrg/current/msg07928.html and
this update resolves one of those issues (the misformatted Python code).
I do not know how to resolve the problem that SPAKE2+ doesn't use w0 or=
w1 in the transcript hash, and therefore more closely resembles SPAKE1
than SPAKE2.=C2=A0 I suggest the following edits for the other issues:
<= /blockquote>

Yeah, I'll have to look at the source (= SPAKE2+ comes from an upublished book...)=C2=A0

* In section 2.2, remove the spaces around the || operators starting
after K.

* In section 2.3, replaces "here Bob" with "here B".
* In the Python code, replace "ec.canon_pointstr" with "cano= n_pointstr".

* Replace the introductory text of section 3 with:

=C2=A0 Every curve presented in the table below has an OID from [RFC5480].<= br> =C2=A0 We construct a string using the OID and the needed constant, for
=C2=A0 instance "1.3.132.0.35 point generation seed (M)" for P-51= 2.=C2=A0 This
=C2=A0 string is turned into a series of blocks by hashing with SHA256, and=
=C2=A0 hashing that output again to generate the next 32 bytes, and so on.<= br> =C2=A0 This pattern is repeated for each group and value, with the string =C2=A0 modified appropriately.

=C2=A0 A byte string of length equal to that of an encoded group element is=
=C2=A0 constructed by concatenating as many blocks as are required,
=C2=A0 starting from the first block, and truncating to the desired length.=
=C2=A0 The byte string is then formatted as required for the group.=C2=A0 I= n the
=C2=A0 case of Weierstrass curves, this means setting the first byte to
=C2=A0 0x02 or 0x03 depending on the low-order bit.=C2=A0 For Ed25519 style=
=C2=A0 formats this means taking all the bytes as the representation of the=
=C2=A0 group element.=C2=A0 The byte string is then interpreted as an eleme= nt in
=C2=A0 the group.=C2=A0 If this interpretation yields a valid group element= with
=C2=A0 the correct order (p), the byte string is the output.=C2=A0 Otherwis= e,
=C2=A0 the initial hash block is discarded and the process is repeated
=C2=A0 until a valid element is found.

= Thanks for you comments=C2=A0

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



--
=
"Man= is born free, but everywhere he is in chains".
--Rousseau.
--94eb2c07b1f84c8fc4055c4bd301-- From nobody Tue Oct 24 17:42: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 BD07013AAC7 for ; Tue, 24 Oct 2017 17:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pivotal-io.20150623.gappssmtp.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 dlZxQWFrnBun for ; Tue, 24 Oct 2017 17:42:05 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 AA53D13C8B0 for ; Tue, 24 Oct 2017 17:42:04 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 47so16642996uas.8 for ; Tue, 24 Oct 2017 17:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PZobzVuuasYOfUuuh5kvGCXkCuwMUMynnPGBXhmv04o=; b=YUAU0ru9ujdCK5YlLoAfcdNqa5/1miL/H0shoLCqjWQ9y8uTPy4f3bsu9yYXGHJOuE H6HXurFxFSZdPsMewr6W2B7tfBkNloCamm7dzXeQYP306XLlcF/rJZLxtTZ7fPuJRSMJ 0r7qIGzsjP3B0hcXDRvmH66FwJeUh2BqhO/hFvnOa84cE4pg3FdGYu5e/lmYWm9/tNWI nXwGb6ajqKryhtiYTOz5btySn/B06atBX7oBGxgyfa5FGg2/RpAKc/JXMTOot17yUTAP ssJHt4n6TO7afGad9JhIVA6lVfccI/LZmgqmyOIn6x8mKZt5CwaR6wQZ32NaeuomqSM/ CqDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PZobzVuuasYOfUuuh5kvGCXkCuwMUMynnPGBXhmv04o=; b=YkvNeUdMLp9vEXu0BNdTRygeD4lsYkz/2zM2OFQiKYaZMgz3noBV3ywtEbbQRfyxnw 8v9qbDhhS7W1UsYchQ0cL9oZZoGwluZew/vjDOejfKOgT5/hMzOnIEhVocBwKPO0oYnb +ZAagOiVqzpwjphtXl8QVL3Z6gkzb+9jCI9h7BcsFvJECnPeKVsEsCpzvSkWddQfSM0U ZwFi9Xzr8PR8uGR4nEF+AARc6ucKIsbqPALyTWE9Hzo1veJSqiUde/tPiSAaurFKIIXe iWeaLPYVucC115kDqjKDayyms9xRKlSy1sEWcq2JhpDqhYJ+QLJ2MCrASa0M2k+X2b0o gNuQ== X-Gm-Message-State: AMCzsaW179fUX4br0J985JEb8KSpJbieQFRyMaNfbCTH7woR+ku5q4kf Xl1nF2kVtq1NQYZE7M27IEGx0qA3JBHhkqzkyoC8rq/Q X-Google-Smtp-Source: ABhQp+RhUyZGvXJEg0YAw0R4t7k0JqTvtM5HbY0rLCmoDb0ivLxzfulUHL/M22jTTlaOnr611mYW8TgzQMxQ0CrjKKM= X-Received: by 10.176.80.70 with SMTP id z6mr423318uaz.84.1508892123418; Tue, 24 Oct 2017 17:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.84 with HTTP; Tue, 24 Oct 2017 17:42:03 -0700 (PDT) From: Rohit Khera Date: Tue, 24 Oct 2017 17:42:03 -0700 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary="94eb2c192310057315055c545372" Archived-At: Subject: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-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, 25 Oct 2017 00:42:07 -0000 --94eb2c192310057315055c545372 Content-Type: text/plain; charset="UTF-8" Dear Members of the CFRG, I have started a draft to outline a key exchange method based on the ring-LWE (RLWE) assumption. Recent years have seen implementations of key exchange methods based on this problem. The basis for such implementations (and for the method detailed in this draft) is chiefly the foundational work of Ajtai, Micciancio, Regev, Lyubashevsky and Peikert on reductions from worst case problems on lattices, to the average case hardness of certain problems (including certain learning problems). I am not aware of any efforts within the IRTF, and the CFRG in particular, that are focused on the more recent lattice based schemes, and request the CFRG to consider adoption of this draft, which is available here: https://datatracker.ietf.org/doc/draft-khera-lpr-ring-lwe-ke x/?include_text=1 As you read through the draft, you will notice that some areas around specifying TLS extensions for hybrid RLWE cipher suites are a work in progress. Thanks for considering this draft, and I look forward to your feedback! Regards, Rohit --94eb2c192310057315055c545372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Members of the CFRG,

I have started a = draft to outline a key exchange method based on the ring-LWE (RLWE) assumpt= ion. Recent years have seen implementations of key exchange methods based o= n this problem.=C2=A0

The basis for such implementations (and fo= r the method detailed in this draft) is chiefly the foundational work of Aj= tai, Micciancio, Regev, Lyubashevsky and Peikert on reductions from worst c= ase problems on lattices, to the average case hardness of certain problems = (including certain learning problems).=C2=A0=C2=A0

I am not aware of an= y efforts within the IRTF, and the CFRG in particular, that are focused on = the more recent lattice based schemes, and request the CFRG to consider ado= ption of this draft, which is available here:
<= div style=3D"font-size:12.8px">https://datatracker.ietf.org/doc/draft-khera-lpr-rin= g-lwe-kex/?include_text=3D1

As you read through the draft,= you will notice that some areas around specifying TLS extensions for hybri= d RLWE cipher suites are a work in progress.=C2=A0

Thanks for consideri= ng this draft, and I look forward to your feedback!

Regards,
Rohit
--94eb2c192310057315055c545372-- From nobody Tue Oct 24 17:48: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 597D613ADF6 for ; Tue, 24 Oct 2017 17:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c9b5zqCWjaX8 for ; Tue, 24 Oct 2017 17:48:37 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 4D44613AAC7 for ; Tue, 24 Oct 2017 17:48:37 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id w45so16653903uac.3 for ; Tue, 24 Oct 2017 17:48:37 -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=ROjJTwD00ppcUf3ZO6AXrfxT4TdJLf7na/grHtCdwng=; b=RzjIeldpYLCEz+lsE/mU2L4MnRoeIKl43Y4Pj6WfoEeh46+NtXo7tHZcdcb+482NkD w/ZY2kYb7x8NuT6tO1dnUKdhFb7AO1Vfr5fdPALUxJhOsuGC3LGwf0RAqyPGoh/3PooK eeRI4O4WWYxDCZgvrngZuRd16HQa0ppZFCCN6mgdfd/U3WFND6yAdBv/zON2JO7bYrvq GguHGnKDPHlOkgQVyO6zp5+Qn5yOgoE2eB0sx+bbTJam6v9tm8Ra0orkzTqsPmUw50XP Q1obcl6uiOjrCBVaN1k8pSyEDMlnm0xMpUu8BbOUfFYorT8k/l9mVJ0kmWeJFUYkAXxD mRog== 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=ROjJTwD00ppcUf3ZO6AXrfxT4TdJLf7na/grHtCdwng=; b=tFgz061QMvNcMDHSd4ieaLcXycRA3Mr2TKO55nDAosre9uK+AEIl1iz6JY9R88Kvri wn8VqPsoP2gY9VTkbRBWk3MRqHYeoh0JqyHX+mY9Yf9baV2U5G+z7TGuSuzGMlcHWPbC PngN2SJ6dFWHBKX3/haP+hV7UolNaOB/eQOU9ydo8QcwbQQHKwLFNgKsnjXEIzFEc6qi yxxbwrQ/XEFngOkwrk1U12PahYI4C1bknaDDjqg2++hrBpnRGtpXiGay5wmgUDwk/amC rIBvH7WcV+VzrmxShuVuIdEM+H8z3Y1T/pZgiascoJp7n+yAraDiAUgZ0BL5SfMbZFrt L7ag== X-Gm-Message-State: AMCzsaUZcbLesPhp81fMZfWfSHFMQnGZudqyOMh3bgLNsU5U9EyQUVo2 i8JudAtXDwqq2/VsDkZLviKDA0rn+4Phcsqpp6mCTg== X-Google-Smtp-Source: ABhQp+QXYj9Q94LQBX/ceptwZhAzSgXweCzt6MllQBU4mWQRpxNicAyASmQsmzzQ8qdWvEi9ztDAvMkUEgKQXb5/Po8= X-Received: by 10.159.49.179 with SMTP id v48mr432088uad.101.1508892516358; Tue, 24 Oct 2017 17:48:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Tue, 24 Oct 2017 17:48:35 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Tue, 24 Oct 2017 17:48:35 -0700 Message-ID: To: Rohit Khera Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a11415848711e10055c546a80" Archived-At: Subject: Re: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-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, 25 Oct 2017 00:48:40 -0000 --001a11415848711e10055c546a80 Content-Type: text/plain; charset="UTF-8" Why don't we wait for the NIST process? On Tue, Oct 24, 2017 at 5:42 PM, Rohit Khera wrote: > Dear Members of the CFRG, > > I have started a draft to outline a key exchange method based on the > ring-LWE (RLWE) assumption. Recent years have seen implementations of key > exchange methods based on this problem. > > The basis for such implementations (and for the method detailed in this > draft) is chiefly the foundational work of Ajtai, Micciancio, Regev, > Lyubashevsky and Peikert on reductions from worst case problems on > lattices, to the average case hardness of certain problems (including > certain learning problems). > > I am not aware of any efforts within the IRTF, and the CFRG in particular, > that are focused on the more recent lattice based schemes, and request the > CFRG to consider adoption of this draft, which is available here: > https://datatracker.ietf.org/doc/draft-khera-lpr-ring-lwe-ke > x/?include_text=1 > > As you read through the draft, you will notice that some areas around > specifying TLS extensions for hybrid RLWE cipher suites are a work in > progress. > > Thanks for considering this draft, and I look forward to your feedback! > > Regards, > Rohit > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > -- "Man is born free, but everywhere he is in chains". --Rousseau. --001a11415848711e10055c546a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why don't we wait for the NIST process?

On Tue, Oct 24, 2017 at 5:= 42 PM, Rohit Khera <rkhera@pivotal.io> wrote:
Dear Me= mbers of the CFRG,

I have started a draft to outline a key exchange me= thod based on the ring-LWE (RLWE) assumption. Recent years have seen implem= entations of key exchange methods based on this problem.=C2=A0

T= he basis for such implementations (and for the method detailed in this draf= t) is chiefly the foundational work of Ajtai, Micciancio, Regev, Lyubashevs= ky and Peikert on reductions from worst case problems on lattices, to the a= verage case hardness of certain problems (including certain learning proble= ms).=C2=A0=C2=A0

I am not aware of any efforts within the IRTF, and th= e CFRG in particular, that are focused on the more recent lattice based sch= emes, and request the CFRG to consider adoption of this draft, which is ava= ilable here:

As you= read through the draft, you will notice that some areas around specifying = TLS extensions for hybrid RLWE cipher suites are a work in progress.=C2=A0<= /div>

Thanks for considering this draft, and I look forward to your feedback!=

Regards,
Rohit
=

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




--
"Man is born= free, but everywhere he is in chains".
--Rousseau.
--001a11415848711e10055c546a80-- From nobody Tue Oct 24 23:30: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 EF1F713942F for ; Tue, 24 Oct 2017 23:30:31 -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 vpclfMgr1lRY for ; Tue, 24 Oct 2017 23:30:28 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27DB139436 for ; Tue, 24 Oct 2017 23:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B48D397AB2; Wed, 25 Oct 2017 09:30:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id o-OrPM3s-9Ut; Wed, 25 Oct 2017 09:30:25 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3B1F1C4; Wed, 25 Oct 2017 09:30:23 +0300 (EEST) Date: Wed, 25 Oct 2017 09:30:22 +0300 From: Ilari Liusvaara To: Rohit Khera Cc: cfrg@irtf.org Message-ID: <20171025063022.xsue5cijlp2hy5s7@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-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, 25 Oct 2017 06:30:32 -0000 On Tue, Oct 24, 2017 at 05:42:03PM -0700, Rohit Khera wrote: > > As you read through the draft, you will notice that some areas around > specifying TLS extensions for hybrid RLWE cipher suites are a work in > progress. Some comments about the TLS stuff: - I expect that at least initially, post-quantum key exchange will be deployed in hybrids with ECC. - TLS 1.3 support is needed (as pseudogroup(s) encopassing hybrid key exchange). In fact, I consider such support higher priority than support for TLS 1.2. - Allowing mixing and matching different parameters seems dubious to me. I expect there to be predefined parameter sets. Such mixing and matching does not work well in TLS 1.3 anyway. - With TLS 1.2, one easily runs into protocol bugs. For example, the TLS 1.2 signing process is flawed, allowing attacks _between_ key exchange types. Analyzing these interactions is not trivial. There is no fix in TLS 1.2. Furthermore, the key derivation is also screwed, requiring very strong properties from key exchange for security. This is fixed by Extended Master Secret. - I expect there to be Chacha20-Poly1305 ciphersuites as well. -Ilari From nobody Wed Oct 25 01:24: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 503F6139436 for ; Wed, 25 Oct 2017 01:24:27 -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] 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 4yYkJEjeip3M for ; Wed, 25 Oct 2017 01:24:24 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20041.outbound.protection.outlook.com [40.107.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4051C13A292 for ; Wed, 25 Oct 2017 01:24:24 -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=4rdOTsBoeNEjQP0lN7EiKRH5CgTofHbJhc7acckB5W4=; b=gKQnUaMFwZJ47lwx+c6wZ31iv7Bw6Pl+iovbYbRDzCkeBSB4eILFJtaeI3yMiMB8I3HrQX7KCj07jXDa7u7IL8R6Vk/13QxncJwy206Zo18MI2s5W3ZJXNJB9bVpuEKQsRMCUo+hNO7ZdXBxrqNLEEMcySVQSKUQz06k/YUqD8M= 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_256_CBC_SHA384_P256) id 15.20.178.6; Wed, 25 Oct 2017 08:24:21 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::adb1:d3e2:d068:a07]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::adb1:d3e2:d068:a07%13]) with mapi id 15.20.0178.007; Wed, 25 Oct 2017 08:24:21 +0000 From: "Paterson, Kenny" To: Watson Ladd , Rohit Khera CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-00 Thread-Index: AQHTTSosfgiEyGIa0USqG4qlaSE7AKLzu6WAgACQm4A= Date: Wed, 25 Oct 2017 08:24:21 +0000 Message-ID: References: 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: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [78.146.55.193] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 6:5uhoVf9FbJLRNItCCktIaEtBmclCYHeH+AK28ZywQKGWw0s0NyJUgWGGeFxs+eWKKoDzIf9ekRDFnZvwUt+I1w3b7R1QbJ94PX7SuXIo7JTEytx2FmxvdMZf0Vjt9mlrZqWLW49DGQMRk9y0MX0zKhB9O1WYIwriP1ffZHnYKCl0QNoHttKum9DwCs9HkhgBggRf0c8qcqDiJZnFzXHog/7Di0pbmmFyQw01i4SQTHHQ3Si+S1oCLJBNXzNPx+RoZNg8i4V/vrHuy1t0v9L1dWZPHltJCIiYJ56B4gG7LvIaYMiyO9iHyV629ri5k9sIrBPD/grSLpnoe0oVJN4GDKKMQPA5em+vwQS0MLBGeOw=; 5:1dA+wmyKHDRpB0q+wESrc+hKJB4ppGyZL+IAVsAAjFJuW1T2pPWLyUgvHGGl8O+u8/SPyWe8S1XjTVf2pCfBT5WHB/ppShgQZ1osfvbGApxt5RUE4WlOjEu251nEqKFOBnPce/cgNisGwjae+gDtyKHTkg/PRCt3gp1f+WTcWNY=; 24:Kgpj2aoAd4+wHmtbbLfM2/saPkPb9IgymjIYc7Cl7iH2uGFlnADxwGbkKKt7A6gfFSwn6Wvma3a8bnuVd3mWdIVGPygo8bA9UiSDBeQnvrg=; 7:Z040B3Yc5iBk8RsPV2zgqOb9YjyRtNBYkvrUoq6NKtivs7AtYqXcISFyh77aruu6a2+k2YD4M5rvHcnNcgMYpyt9Vcxr79pU+eJgMsH9IWSCa/su+igNj+sSBJxEAPAoUMn//Ne2HSOxqH25lC82TFEGVKWy7Z2gi/kXTqdwSdk29UOJEcOFxvDJ710BgQRO+Qpri2f2cXhcqhr0qjeORXFwh/gwqQVEW2+EV1fzEZ5ePqLHznkSM3501QLxytna x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(24454002)(51414003)(305945005)(83506002)(3660700001)(189998001)(99286003)(3280700002)(86362001)(58126008)(6512007)(6306002)(106356001)(105586002)(110136005)(42882006)(6486002)(101416001)(2950100002)(54356999)(50986999)(76176999)(5660300001)(2906002)(230783001)(6436002)(68196006)(25786009)(229853002)(36756003)(14454004)(7736002)(6506006)(4326008)(66066001)(68736007)(8936002)(2900100001)(6116002)(81166006)(102836003)(81156014)(3846002)(5250100002)(53936002)(786003)(8676002)(6246003)(97736004)(72206003)(478600001)(74482002)(316002)(39060400002)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: ec8ee179-9283-4a6a-beb1-08d51b81cb2a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-exchange-antispam-report-test: UriScan:(120809045254105)(266576461109395); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231020)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(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: 0471B73328 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <623A396E9672064992445D9335DA362E@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ec8ee179-9283-4a6a-beb1-08d51b81cb2a X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 08:24:21.5319 (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: Re: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-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, 25 Oct 2017 08:24:27 -0000 VGhpcyBxdWVzdGlvbiBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIGxpc3Qgc2V2ZXJhbCB0aW1l cy4NCg0KSXQgaXMgdGhlIHNldHRsZWQgb3BpbmlvbiBvZiB0aGUgQ0ZSRyBjaGFpcnMgdGhhdCB3 ZSBzaG91bGQgd2FpdCBmb3IgdGhlDQpOSVNUIHByb2Nlc3MuIA0KDQpPdXIgYXBwcm9hY2ggY2Fu IGJlIHJldmlzaXRlZCwgYnV0IG9ubHkgaWYgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGVvcGxl DQpjb21lIGZvcndhcmQgd2l0aCBnb29kIGFyZ3VtZW50cyBmb3Igd2h5IHdlIHNob3VsZCBkbyBz by4NCg0KDQpSZWdhcmRzLA0KDQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQoNCg0KDQpPbiAyNS8x MC8yMDE3IDAxOjQ4LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgV2F0c29uIExhZGQiDQo8Y2ZyZy1ib3Vu Y2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiB3YXRzb25ibGFkZEBnbWFpbC5jb20+IHdyb3RlOg0K DQo+V2h5IGRvbid0IHdlIHdhaXQgZm9yIHRoZSBOSVNUIHByb2Nlc3M/DQo+DQo+T24gVHVlLCBP Y3QgMjQsIDIwMTcgYXQgNTo0MiBQTSwgUm9oaXQgS2hlcmENCj48cmtoZXJhQHBpdm90YWwuaW8+ IHdyb3RlOg0KPg0KPkRlYXIgTWVtYmVycyBvZiB0aGUgQ0ZSRywNCj4NCj5JIGhhdmUgc3RhcnRl ZCBhIGRyYWZ0IHRvIG91dGxpbmUgYSBrZXkgZXhjaGFuZ2UgbWV0aG9kIGJhc2VkIG9uIHRoZQ0K PnJpbmctTFdFIChSTFdFKSBhc3N1bXB0aW9uLiBSZWNlbnQgeWVhcnMgaGF2ZSBzZWVuIGltcGxl bWVudGF0aW9ucyBvZiBrZXkNCj5leGNoYW5nZSBtZXRob2RzIGJhc2VkIG9uIHRoaXMgcHJvYmxl bS4NCj4NCj4NCj5UaGUgYmFzaXMgZm9yIHN1Y2ggaW1wbGVtZW50YXRpb25zIChhbmQgZm9yIHRo ZSBtZXRob2QgZGV0YWlsZWQgaW4gdGhpcw0KPmRyYWZ0KSBpcyBjaGllZmx5IHRoZSBmb3VuZGF0 aW9uYWwgd29yayBvZiBBanRhaSwgTWljY2lhbmNpbywgUmVnZXYsDQo+THl1YmFzaGV2c2t5IGFu ZCBQZWlrZXJ0IG9uIHJlZHVjdGlvbnMgZnJvbSB3b3JzdCBjYXNlIHByb2JsZW1zIG9uDQo+bGF0 dGljZXMsIHRvIHRoZSBhdmVyYWdlDQo+IGNhc2UgaGFyZG5lc3Mgb2YgY2VydGFpbiBwcm9ibGVt cyAoaW5jbHVkaW5nIGNlcnRhaW4gbGVhcm5pbmcgcHJvYmxlbXMpLg0KPiANCj4NCj4NCj5JIGFt IG5vdCBhd2FyZSBvZiBhbnkgZWZmb3J0cyB3aXRoaW4gdGhlIElSVEYsIGFuZCB0aGUgQ0ZSRyBp bg0KPnBhcnRpY3VsYXIsIHRoYXQgYXJlIGZvY3VzZWQgb24gdGhlIG1vcmUgcmVjZW50IGxhdHRp Y2UgYmFzZWQgc2NoZW1lcywNCj5hbmQgcmVxdWVzdCB0aGUgQ0ZSRyB0byBjb25zaWRlciBhZG9w dGlvbiBvZiB0aGlzIGRyYWZ0LCB3aGljaCBpcw0KPmF2YWlsYWJsZSBoZXJlOg0KPg0KPg0KPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtoZXJhLWxwci1yaW5nLWx3ZS1r ZXgvP2luY2x1ZGVfdGV4DQo+dD0xDQo+DQo+DQo+DQo+QXMgeW91IHJlYWQgdGhyb3VnaCB0aGUg ZHJhZnQsIHlvdSB3aWxsIG5vdGljZSB0aGF0IHNvbWUgYXJlYXMgYXJvdW5kDQo+c3BlY2lmeWlu ZyBUTFMgZXh0ZW5zaW9ucyBmb3IgaHlicmlkIFJMV0UgY2lwaGVyIHN1aXRlcyBhcmUgYSB3b3Jr IGluDQo+cHJvZ3Jlc3MuIA0KPg0KPg0KPlRoYW5rcyBmb3IgY29uc2lkZXJpbmcgdGhpcyBkcmFm dCwgYW5kIEkgbG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJhY2shDQo+DQo+DQo+UmVnYXJkcywN Cj5Sb2hpdA0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Q2ZyZyBtYWlsaW5nIGxpc3QNCj5DZnJnQGlydGYub3JnDQo+aHR0cHM6Ly93 d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ DQo+LS0gDQo+Ik1hbiBpcyBib3JuIGZyZWUsIGJ1dCBldmVyeXdoZXJlIGhlIGlzIGluIGNoYWlu cyIuDQo+LS1Sb3Vzc2VhdS4NCj4NCg0K From nobody Thu Oct 26 11:06: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 6343913F5D8 for ; Thu, 26 Oct 2017 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 gukKg9sPApui for ; Thu, 26 Oct 2017 11:06:31 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 2119813F441 for ; Thu, 26 Oct 2017 11:06:31 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y23so5370680qkb.10 for ; Thu, 26 Oct 2017 11:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=J9bKlaysGRkA+V1ss0QhdSn9G8b8lhAm374Ykdt/gx0=; b=NJUOgqGtredHH1xNlwYgyWpleYNGTfaLDRZ1MmhdpE7tOhpWCtB9ND4AA4/jSoKAQR Yoexwx/B3+sgz/QwmolfYytyhXduUIloDk/fLaK6U2bzdYGV5VQconcpmJPaiTRLatL7 zTGy7kIXAW/FoRLS+udLR+Npd2M5ofunpumoiute2K4mp3RL1KxxI3ntkkiyrdduPuKq 5XucFp9kxpwr7ZAXHQjgI5MHtNrNCc4N65DlaeHZ2iAx2XF/Sf3E3AFUM/gzxKxqxIrU BfaeOsnBR/7h31catQeGZpUsk9rylqRbqb2zGaeX69W7RRGsH3nrdPIKCEyenTIKO1o9 0kAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J9bKlaysGRkA+V1ss0QhdSn9G8b8lhAm374Ykdt/gx0=; b=PJ1oj5DouT7+X6HqbNObs6NtyWuipk9AlB3afksAVH/qfNKuiyU8s7w7S2YVUSkOin m58B5Znexb4i7Y7FcTbadqPolgBLMQiQ0Lsl29g1lL16np0fr+6+Oc+yAzAnkbKTL9QN MRnxIqTnXDSlwkH5+7FrAxBfw65unafvwrYBoSTbHkSwsvWwQ6hsWHkKDiQVuQMLX64z ecXN7tdJWR5vVEWd4CP8pdqNHzBww2pGzACisu/U6dNF+oOs5eKoAlaoGeuJjQDesHDB Ux32le8xIr/zTqPxoc/n8UG+e0bBVgWEhNhfGYfZ9jBVXsfLBQ1XLt4jp+XPjojpuaPd YTNQ== X-Gm-Message-State: AMCzsaXtq0M6RtTQX6tAxfrd27SYAJzfhLUgmtjSftX6NVuJWCu78zBX ei5Gp87gNtYsxWkIxWKObkBAtL365p9KwwSffDswSA== X-Google-Smtp-Source: ABhQp+TtacbHPGJGsCjhqnc45W/GF0YwgtaYnzs9W/k0/Za2HEiiQBrVbexsT+yC2h6foenK7qEs9LJBr0v4d2sUjGg= X-Received: by 10.55.20.72 with SMTP id e69mr8928910qkh.194.1509041190006; Thu, 26 Oct 2017 11:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.103 with HTTP; Thu, 26 Oct 2017 11:06:29 -0700 (PDT) From: Peter Alexander Date: Thu, 26 Oct 2017 14:06:29 -0400 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary="001a1145eae814f40a055c7708ca" Archived-At: Subject: [Cfrg] Dynamic Key Changes on Encrypted Sessions. 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, 26 Oct 2017 18:06:32 -0000 --001a1145eae814f40a055c7708ca Content-Type: text/plain; charset="UTF-8" Greetings everyone, I have tried sending this message before but it was getting blocked. So I am trying again :) Eliot Lear from the SAGG mailing list pointed me in your direction. Have been meaning to post but got busy. Briefly; I co-invented a VPN-like method for securing transmissions where encryption keys could be changed without having to tear-down, and rebuild the entire session. At the time we also tried to patent the technology but essentially ran out of funding. The organization has since dissolved. This was back in 2010. Given that the invention always sparked interest, but never truly gone anywhere I would like to begin the process of opening it up to a wider audience. What follows are a few of the high-level design elements which we thought were unique to the art. - Dynamic key changes during encrypted sessions (no need to restart) - Initial key exchange agnostic. Ex: Possible to use IPSec/DH exchange to build initial tunnel - Packets containing keys are obfuscated using upto three methods - Can also utilize locally stored key arrays. Sending index of key instead of key itself. We were able to come up with working code (Linux 2.6 kernel & Android Gingerbread), which I can share once I remove the proprietary crypto libraries. I also have all of the documentation/presentation slides that I authored at the time. Kindly let me know if this is something worth moving forward with. I am open to discussion/criticism as needed. Cheers! --001a1145eae814f40a055c7708ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings everyone,=C2=A0<= /div>

I have tried sending this message before but it was getting blocked. So= I am trying again :)

Eliot Lear from the SAGG mailing list pointed me in= your direction. Have been meaning to post but got busy.

Briefly;

I co-invented a VPN-lik= e method for securing transmissions where encryption keys could be changed = without having to tear-down, and rebuild the entire session. At the time we= also tried to patent the technology but essentially ran out of funding. Th= e organization has since dissolved. This was back in 2010. Given that the i= nvention always sparked interest, but never truly gone anywhere I would lik= e to begin the process of opening it up to a wider audience.

What follo= ws are a few of the high-level design elements which we thought were unique= to the art.=C2=A0

- Dynamic key changes during encrypted sessions (no = need to restart)
- Initial key exchang= e agnostic. Ex: Possible to use IPSec/DH exchange to build initial tunnel
- Packets containing keys are obfuscate= d using upto three methods
- Can also = utilize locally stored key arrays. Sending index of key instead of key itse= lf.

We were able to come up with working code (Linux 2.6 kernel & A= ndroid Gingerbread), which I can share once I remove the proprietary crypto= libraries. I also have all of the documentation/presentation slides that I= authored at the time.

Kindly let me know if this is something worth mo= ving forward with. I am open to discussion/criticism as needed.

Cheers!=
--001a1145eae814f40a055c7708ca-- From nobody Fri Oct 27 02:22:30 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 332AF13A9F5 for ; Fri, 27 Oct 2017 02:22:30 -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] 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 YU2XbHg6-MRn for ; Fri, 27 Oct 2017 02:22:28 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40078.outbound.protection.outlook.com [40.107.4.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8291013A5CF for ; Fri, 27 Oct 2017 02:22:26 -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=4cByOKICvQBNgnPQuUy5k5bmvZk1Butf3V4mg+iPu9k=; b=UEKe50uLhxfyiA6oyJggFh4q9RKOgdt4pSTNlhUiDrZdiYIaHts48lIg8+55b4MlhiIGTj33bR6/4RLkpbLAttZKbWDrLMvzAS88xpX9XgdDiI6mGhCqfcR/VmGXtAG/qNubPTMKHw2DEzMwf17yKj6lLvKR16P2FEL1Lgjgz24= 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_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 09:22:23 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::adb1:d3e2:d068:a07]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::adb1:d3e2:d068:a07%13]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 09:22:23 +0000 From: "Paterson, Kenny" To: Peter Alexander , "cfrg@irtf.org" Thread-Topic: [Cfrg] Dynamic Key Changes on Encrypted Sessions. Thread-Index: AQHTToUxDalFOac93kqSKKIyxqaDbaL3fm+A Date: Fri, 27 Oct 2017 09:22:23 +0000 Message-ID: References: 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: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 6:ylEx2OtUPCDjUxChWJ17aD/v+sFJVfQUGKNlkbeCUe4jcOHBjDgl0Gd3vmNreTs7FhETmjHJEuPALIT/Ze7BhfFx4NH6ovhpO3gbNZTm7I1sOBX3tj59mj1Igp01fa4jCJuhBkMjaa0FB/VUIYrdQA9fH/z7DhiFziUZJ8M2R6CPj976P9EtwrLDOMi8e0HyWiT8ga9jtTD6if/DO2uNWi/dj0jPbuZHs6NYOabSEgmBHwK/yFa6IhiSmrZDfHe+5MxE4JlUWTkXt3+/94E82DOA3oX/OFUmSewmYbO4+hpZDndz//bwihanFBq1oh9HYQ0gKzAeI5u0PKxF46UuzAmBWPTuxIJlVyc3wZ4MbdQ=; 5:/gxgyKaWI3a4DnVdDm0fZ/fibDNCkY+6gntEmisnhgv3/IPD5ZsPoPe8Q+VQRJ/tosN3ceu8gwRMbcdvyZsqYGBqZdzy0bMxNLRt8VfFtKRqVEBYZdXpHV4HqZApH3kiqClYkn+XCWHyrlXeCGwSRGq6r3xv3Yi+3yTaEqO7lh0=; 24:+Oai0uiEuKscySWEAsMyB8pqq8riRWYOgr3ZPVXBQFaNo68MXEDXr2tAO8/1fr1J6ULzRYcyGLXDnyC1sATdzPilP8k5DoqVHrzWFaVaNNM=; 7:gQtJjqZYR+sF9Oev3mTtOSiMzUoNa+5FXshIDKntLtQp08CfAI6tBhjPnUljKh3/om3YtVT+B1nRbmWesAen37Rk4NklCumIKGMx66HV9nfAki/T+1zocGh55N50Seq0kejj++DKbWs88o4Vk/pCpNq8BMhCSj3UULo2h1Bi3T81jwfqAxx39nVZw1+wFJXs6kSO2plYUivKxow/s3A6uuDyuoVg8IrBQj6pC2/4ESEUmmpt9+fv2y0jSmyBeqUZ x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(8676002)(101416001)(7736002)(74482002)(105586002)(81166006)(54356999)(86362001)(786003)(316002)(6486002)(106356001)(2900100001)(305945005)(5250100002)(58126008)(2501003)(110136005)(83506002)(8936002)(76176999)(81156014)(97736004)(6116002)(6306002)(68736007)(72206003)(966005)(53936002)(6246003)(6512007)(39060400002)(66066001)(42882006)(102836003)(3846002)(99286003)(2950100002)(3280700002)(14454004)(6436002)(478600001)(3660700001)(50986999)(25786009)(36756003)(189998001)(2906002)(6506006)(53546010)(5660300001)(413944005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: c56150c5-c14f-4ac8-ed41-08d51d1c3b35 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0301MB1905; x-ms-traffictypediagnostic: AM4PR0301MB1905: x-exchange-antispam-report-test: UriScan:(131327999870524); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(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: 0473A03F3F received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1AF44E51C99FC74C8B79C97FEB16522B@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: c56150c5-c14f-4ac8-ed41-08d51d1c3b35 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 09:22:23.1691 (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] Dynamic Key Changes on Encrypted Sessions. 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, 27 Oct 2017 09:22:30 -0000 RGVhciBQZXRlciwNCg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHRvIHRoZSBsaXN0Lg0KDQpZ b3UgbWlnaHQgZmluZCB0aGlzIElEIGludGVyZXN0aW5nIHRvIGxvb2sgYXQgaW4gdGhlIGNvbnRl eHQgb2YgeW91ciB3b3JrOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0 Zi1jZnJnLXJlLWtleWluZy0wOA0KDQoNClJlZ2FyZHMNCg0KS2VubnkgDQoNCk9uIDI2LzEwLzIw MTcgMTk6MDYsICJDZnJnIG9uIGJlaGFsZiBvZiBQZXRlciBBbGV4YW5kZXIiDQo8Y2ZyZy1ib3Vu Y2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBwaXBuZmxpbnhAZ21haWwuY29tPiB3cm90ZToNCg0K PkdyZWV0aW5ncyBldmVyeW9uZSwNCj4NCj4NCj5JIGhhdmUgdHJpZWQgc2VuZGluZyB0aGlzIG1l c3NhZ2UgYmVmb3JlIGJ1dCBpdCB3YXMgZ2V0dGluZyBibG9ja2VkLiBTbyBJDQo+YW0gdHJ5aW5n IGFnYWluIDopDQo+DQo+DQo+RWxpb3QgTGVhciBmcm9tIHRoZSBTQUdHIG1haWxpbmcgbGlzdCBw b2ludGVkIG1lIGluIHlvdXIgZGlyZWN0aW9uLiBIYXZlDQo+YmVlbiBtZWFuaW5nIHRvIHBvc3Qg YnV0IGdvdCBidXN5Lg0KPg0KPg0KPg0KPg0KPg0KPkJyaWVmbHk7DQo+DQo+DQo+SSBjby1pbnZl bnRlZCBhIFZQTi1saWtlIG1ldGhvZCBmb3Igc2VjdXJpbmcgdHJhbnNtaXNzaW9ucyB3aGVyZQ0K PmVuY3J5cHRpb24ga2V5cyBjb3VsZCBiZSBjaGFuZ2VkIHdpdGhvdXQgaGF2aW5nIHRvIHRlYXIt ZG93biwgYW5kIHJlYnVpbGQNCj50aGUgZW50aXJlIHNlc3Npb24uIEF0IHRoZSB0aW1lIHdlIGFs c28gdHJpZWQgdG8gcGF0ZW50IHRoZSB0ZWNobm9sb2d5DQo+YnV0IGVzc2VudGlhbGx5IHJhbg0K PiBvdXQgb2YgZnVuZGluZy4gVGhlIG9yZ2FuaXphdGlvbiBoYXMgc2luY2UgZGlzc29sdmVkLiBU aGlzIHdhcyBiYWNrIGluDQo+MjAxMC4gR2l2ZW4gdGhhdCB0aGUgaW52ZW50aW9uIGFsd2F5cyBz cGFya2VkIGludGVyZXN0LCBidXQgbmV2ZXIgdHJ1bHkNCj5nb25lIGFueXdoZXJlIEkgd291bGQg bGlrZSB0byBiZWdpbiB0aGUgcHJvY2VzcyBvZiBvcGVuaW5nIGl0IHVwIHRvIGENCj53aWRlciBh dWRpZW5jZS4NCj4NCj4NCj5XaGF0IGZvbGxvd3MgYXJlIGEgZmV3IG9mIHRoZSBoaWdoLWxldmVs IGRlc2lnbiBlbGVtZW50cyB3aGljaCB3ZSB0aG91Z2h0DQo+d2VyZSB1bmlxdWUgdG8gdGhlIGFy dC4NCj4NCj4NCj4tIER5bmFtaWMga2V5IGNoYW5nZXMgZHVyaW5nIGVuY3J5cHRlZCBzZXNzaW9u cyAobm8gbmVlZCB0byByZXN0YXJ0KQ0KPi0gSW5pdGlhbCBrZXkgZXhjaGFuZ2UgYWdub3N0aWMu IEV4OiBQb3NzaWJsZSB0byB1c2UgSVBTZWMvREggZXhjaGFuZ2UgdG8NCj5idWlsZCBpbml0aWFs IHR1bm5lbA0KPi0gUGFja2V0cyBjb250YWluaW5nIGtleXMgYXJlIG9iZnVzY2F0ZWQgdXNpbmcg dXB0byB0aHJlZSBtZXRob2RzDQo+LSBDYW4gYWxzbyB1dGlsaXplIGxvY2FsbHkgc3RvcmVkIGtl eSBhcnJheXMuIFNlbmRpbmcgaW5kZXggb2Yga2V5DQo+aW5zdGVhZCBvZiBrZXkgaXRzZWxmLg0K Pg0KPg0KPldlIHdlcmUgYWJsZSB0byBjb21lIHVwIHdpdGggd29ya2luZyBjb2RlIChMaW51eCAy LjYga2VybmVsICYgQW5kcm9pZA0KPkdpbmdlcmJyZWFkKSwgd2hpY2ggSSBjYW4gc2hhcmUgb25j ZSBJIHJlbW92ZSB0aGUgcHJvcHJpZXRhcnkgY3J5cHRvDQo+bGlicmFyaWVzLiBJIGFsc28gaGF2 ZSBhbGwgb2YgdGhlIGRvY3VtZW50YXRpb24vcHJlc2VudGF0aW9uIHNsaWRlcyB0aGF0DQo+SSBh dXRob3JlZCBhdCB0aGUNCj4gdGltZS4NCj4NCj4NCj5LaW5kbHkgbGV0IG1lIGtub3cgaWYgdGhp cyBpcyBzb21ldGhpbmcgd29ydGggbW92aW5nIGZvcndhcmQgd2l0aC4gSSBhbQ0KPm9wZW4gdG8g ZGlzY3Vzc2lvbi9jcml0aWNpc20gYXMgbmVlZGVkLg0KPg0KPg0KPkNoZWVycyENCj4NCg0K From nobody Fri Oct 27 05:58:05 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 B601F13A8A1 for ; Fri, 27 Oct 2017 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 2m76LT7aKot0 for ; Fri, 27 Oct 2017 05:58:02 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 027D213F4CE for ; Fri, 27 Oct 2017 05:58:02 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id q83so8210773qke.6 for ; Fri, 27 Oct 2017 05:58:01 -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=RbLiLhiPaw7tBG450MlCeFvvl3RJUAXRRW29yWxwZr0=; b=EyVnm3Uf7DsuxbBZcLIfL2w79SeatlFJb3zEVfpN5LvKgVCC97QEvL/0NSRREk4h83 QavMfJWTAYbt04yrNfpbKim0iYKo4CREv3PQD3ZM/lczmhbPGLNWNtx3QFBBO5sOdNTX AvwehZ6DReKojz3H2qiVzieBO/Bm2Zpoo/+nbZufhAy2iOmc/s4mw1GlhMC1kzmL3PA4 n2YSKh6JPsFWGIIV1Nk+UoJ0vCNa89H0fchWSiFCL0N50fMguOu/hF8vFkKSFELhGwrl ujhVYnO9UlDOh7SNDimwKDxIRIdRQk/Ya4V+IsgCBBAcfGEKNusUPvylnvQIdom4k+oy qgSw== 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=RbLiLhiPaw7tBG450MlCeFvvl3RJUAXRRW29yWxwZr0=; b=SKzBBAjKYnbC7/u/sWvL0WIxotqdG6BeNBor+LSFoG2giXgQFjIvnzottEs16Ee6Xl qO5za/HLgtzCDhJqDDWMW6/n9OVYSpO2w15Tsb29Bgn3O4afOvQn9b3ozLgC1vmtbiGr m6DNYYNHcg9mVqXWcWEueur+Vl0KRA12IgAzvFuE6WF1+3vgcfhcY5e9eRQyud0Qm+Zb NVxhyVpXtqKknQzebCJjYXRqIwDBtcV8tLO/H6NPoQVZ5mM/lyz37ktZKPQEj57eQocB wWLsNZdhTVX67uERQmjnBBSQgcP4YvLsldWeG+qe/feJjBTO4w9Ber/y58mJ1tTVnG1x S4VA== X-Gm-Message-State: AMCzsaU0rSo1rZ0FcWQJ4Wwuy36Gl3RFlJHQpnI+eJdeXor4drR94Vao K975Y3WXvFqbtCvs1/p3cQdqB/99WIxXjzVUN/A= X-Google-Smtp-Source: ABhQp+RsHZMWuG0vtVVTr3qdaa5pYE2szt5hRRIQwiLjUp31w2aP5B4XuwSMjh4dhC7XQLdjx33HBoiGw1OkB9UuO3s= X-Received: by 10.55.122.135 with SMTP id v129mr546047qkc.171.1509109081055; Fri, 27 Oct 2017 05:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.103 with HTTP; Fri, 27 Oct 2017 05:58:00 -0700 (PDT) In-Reply-To: References: From: Peter Alexander Date: Fri, 27 Oct 2017 08:58:00 -0400 Message-ID: To: "Paterson, Kenny" Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c05acc0b42542055c86d652" Archived-At: Subject: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessions. 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, 27 Oct 2017 12:58:05 -0000 --94eb2c05acc0b42542055c86d652 Content-Type: text/plain; charset="UTF-8" Thanks Kenny, That does look pretty neat although much of it is a bit over my head. At a minimum that ID seems to try to solve the same issue we were trying to solve in 2010. I will have to print it out and try to get a better understanding of it though. Cheers, Peter On Fri, Oct 27, 2017 at 5:22 AM, Paterson, Kenny wrote: > Dear Peter, > > Thanks for bringing this to the list. > > You might find this ID interesting to look at in the context of your work: > > https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-08 > > > Regards > > Kenny > > On 26/10/2017 19:06, "Cfrg on behalf of Peter Alexander" > wrote: > > >Greetings everyone, > > > > > >I have tried sending this message before but it was getting blocked. So I > >am trying again :) > > > > > >Eliot Lear from the SAGG mailing list pointed me in your direction. Have > >been meaning to post but got busy. > > > > > > > > > > > >Briefly; > > > > > >I co-invented a VPN-like method for securing transmissions where > >encryption keys could be changed without having to tear-down, and rebuild > >the entire session. At the time we also tried to patent the technology > >but essentially ran > > out of funding. The organization has since dissolved. This was back in > >2010. Given that the invention always sparked interest, but never truly > >gone anywhere I would like to begin the process of opening it up to a > >wider audience. > > > > > >What follows are a few of the high-level design elements which we thought > >were unique to the art. > > > > > >- Dynamic key changes during encrypted sessions (no need to restart) > >- Initial key exchange agnostic. Ex: Possible to use IPSec/DH exchange to > >build initial tunnel > >- Packets containing keys are obfuscated using upto three methods > >- Can also utilize locally stored key arrays. Sending index of key > >instead of key itself. > > > > > >We were able to come up with working code (Linux 2.6 kernel & Android > >Gingerbread), which I can share once I remove the proprietary crypto > >libraries. I also have all of the documentation/presentation slides that > >I authored at the > > time. > > > > > >Kindly let me know if this is something worth moving forward with. I am > >open to discussion/criticism as needed. > > > > > >Cheers! > > > > --94eb2c05acc0b42542055c86d652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Kenny,=C2=A0

That does look pret= ty neat although much of it is a bit over my head.
At a minimum t= hat ID seems to try to solve the same issue we were trying to solve in 2010= .

I will have to print it out and try to get a bet= ter understanding of it though.

Cheers,=C2=A0

Peter


On Fri, Oct 27, 2017 at 5:22 AM, Paters= on, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
Dear Peter,

Thanks for bringing this to the list.

You might find this ID interesting to look at in the context of your work:<= br>
https://tools.ietf.org/html/draft-irtf-= cfrg-re-keying-08


Regards

Kenny

On 26/10/2017 19:06, "Cfrg on behalf of Peter Alexander"
<cfrg-bounces@irtf.org on behalf of pipnflinx@gmail.com> wrote:

>Greetings everyone,
>
>
>I have tried sending this message before but it was getting blocked. So= I
>am trying again :)
>
>
>Eliot Lear from the SAGG mailing list pointed me in your direction. Hav= e
>been meaning to post but got busy.
>
>
>
>
>
>Briefly;
>
>
>I co-invented a VPN-like method for securing transmissions where
>encryption keys could be changed without having to tear-down, and rebui= ld
>the entire session. At the time we also tried to patent the technology<= br> >but essentially ran
> out of funding. The organization has since dissolved. This was back in=
>2010. Given that the invention always sparked interest, but never truly=
>gone anywhere I would like to begin the process of opening it up to a >wider audience.
>
>
>What follows are a few of the high-level design elements which we thoug= ht
>were unique to the art.
>
>
>- Dynamic key changes during encrypted sessions (no need to restart) >- Initial key exchange agnostic. Ex: Possible to use IPSec/DH exchange = to
>build initial tunnel
>- Packets containing keys are obfuscated using upto three methods
>- Can also utilize locally stored key arrays. Sending index of key
>instead of key itself.
>
>
>We were able to come up with working code (Linux 2.6 kernel & Andro= id
>Gingerbread), which I can share once I remove the proprietary crypto >libraries. I also have all of the documentation/presentation slides tha= t
>I authored at the
> time.
>
>
>Kindly let me know if this is something worth moving forward with. I am=
>open to discussion/criticism as needed.
>
>
>Cheers!
>


--94eb2c05acc0b42542055c86d652-- From nobody Sun Oct 29 06:28:19 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 E225213F444 for ; Sun, 29 Oct 2017 06:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 EjmGAw4P_WAs for ; Sun, 29 Oct 2017 06:28:17 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC5813B13B for ; Sun, 29 Oct 2017 06:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509283696; d=isode.com; s=june2016; i=@isode.com; bh=JW8bRC/jv3ggW6bQl/O0r45HAqBXBf8n9ES54Ud9Rrc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uNp36VRi5ZbpiQR9iS8ltJ4PfElfba3JNnZ/OpPGnnLRBKeYeoQgzzkYHLHXoGtuF5n13i LJ6GPlgYRUgw3Ptz7lsCHQvjMJZL41WJCcQw2jcY522cutsA+7yiWRpbWKYDKCth0zXPm3 +3Vpv1TcovxKC7/JHd1BrJSvKO2T1WQ=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Oct 2017 13:28:16 +0000 To: "cfrg@irtf.org" References: <5971E235.9060703@isode.com> From: Alexey Melnikov Message-ID: <59F5D773.3040405@isode.com> Date: Sun, 29 Oct 2017 13:28:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <5971E235.9060703@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cfrg] RGLC on "Hash-Based Signatures": draft-mcgrew-hash-sigs-07 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, 29 Oct 2017 13:28:19 -0000 To close the loop on this: On 21/07/2017 12:15, Alexey Melnikov wrote: > Dear CFRG participants, > > This message is starting 4 weeks CFRG Last Call on "Hash-Based > Signatures" . > The LC is going to finish on August 18th. > > Please send your comments in a reply to this message or directly to > chairs (cfrg-chairs@ietf.org). Statement of support (or not) for this > draft being submitted to IRSG for review and publication are also welcomed. Chairs received one positive response from Russ Housley and one private set of comments which I forwarded to authors. Any other comments? Thank you, Alexey > Thank you, > Kenny and Alexey From nobody Sun Oct 29 07:28: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 76EF213B408 for ; Sun, 29 Oct 2017 07:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 PsQMU6hUoVW3 for ; Sun, 29 Oct 2017 07:28:53 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 058C613A8A1 for ; Sun, 29 Oct 2017 07:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509287332; d=isode.com; s=june2016; i=@isode.com; bh=cMbMTdA4i7a56lDonIqnLn9C9kRTXQo783+9x4Cv27M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dgjWOBSxryUbzCIqBhkLGhOQUr5gvxTW/UJA9SH++nHGsqeKV30cNlIpgK4cHsZUg9k8Gj etK/q3R+vNmeKROgCnk/gSupMaqHBy4C+2byR1MTRTVVLG4u1Tuw8dznW+ZO6/eNBMubFr kN0aSXmk0DzwRB5i7h7oa754lmuvgLo=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Oct 2017 14:28:52 +0000 From: Alexey Melnikov To: "cfrg@irtf.org" Message-ID: <59F5E5A6.3080507@isode.com> Date: Sun, 29 Oct 2017 14:28:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010308070300030205020704" Archived-At: Subject: [Cfrg] RG Last Call on draft-irtf-cfrg-argon2-03 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, 29 Oct 2017 14:28:54 -0000 --------------010308070300030205020704 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear CFRG participants, This message starts 2 week RGLC on "The memory-hard Argon2 password hash and proof-of-work function " (draft-irtf-cfrg-argon2-03, ), that will end on November 12th. Please send you comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs. Your feedback will help chairs to decide whether the document is ready for review by IRSG and subsequent publication as an RFC. Thank you, Kenny and Alexey --------------010308070300030205020704 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Dear CFRG participants,

This message starts 2 week RGLC on "The memory-hard Argon2 password hash and proof-of-work function " (draft-irtf-cfrg-argon2-03, <https://datatracker.ietf.org/doc/draft-irtf= -cfrg-argon2/>), that will end on November 12th. Please send you comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs. Your feedback will help chairs to decide whether the document is ready for review by IRSG and subsequent publication as an RFC.

Thank you,
Kenny and Alexey
--------------010308070300030205020704-- From nobody Sun Oct 29 07:44:46 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 E8AA513F556 for ; Sun, 29 Oct 2017 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 R9vYUyt-y7jx for ; Sun, 29 Oct 2017 07:44:44 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE013B278 for ; Sun, 29 Oct 2017 07:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509288283; d=isode.com; s=june2016; i=@isode.com; bh=rFgpX6DcPQ8n4Rpw+dSr9/gJ1IzvPa9AolhknHM4S4A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KJUh1mw3T/VPOm+T6xqGvUlUc2xj2PZBWLWgLZpFX+9IzDquChM+T4eH705DWK/pAD+I/i 8s5PLUhoUgubBNAX19nbya+HUtVT8khsT4aoWP6gXqZN+5xxGUSKXt3W8LuBX4jWhFPsgH rzy2qgXTuGaUhtktxjjK5H1bOc/qjVc=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Oct 2017 14:44:42 +0000 To: "cfrg@irtf.org" From: Alexey Melnikov Message-ID: <59F5E95D.90003@isode.com> Date: Sun, 29 Oct 2017 14:44:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: [Cfrg] Agenda items request for Singapore IETF meeting 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, 29 Oct 2017 14:44:45 -0000 Dear CFRG participants, CFRG has 1.5 hours slot in Singapore (UTC +8) on Wednesday, November 15th, 15:20-16:50 local time. If you would like to present, please reply to chairs for requests. Thank you, Alexey and Kenny From nobody Tue Oct 31 22:46: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 5420213FCC2 for ; Tue, 31 Oct 2017 22:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 A9iF3Ae3fPwi for ; Tue, 31 Oct 2017 22:45:56 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 F283613FCCD for ; Tue, 31 Oct 2017 22:45:55 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id z28so1437205qtz.13 for ; Tue, 31 Oct 2017 22:45:55 -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=t1qCFwfKR6ylAzls4Zrcbs/sJh1vbklt4U6Gl+Uskyw=; b=NLed7JualbdVIdgUcbAbs5BdSnNZ4m15MlEZ1HuSi+upz47xVNGMDvf5rzctfW2ybZ CZw/LCJxdu9NwDgBIxVjrYREZFHMnjwClvzJlpKfzzJg8i3KMbTV1qF9AwJHkEA6lVwA lg2JgGZLInELNPaHkXxuCyYNsBEbWQyycxNsFHmMQ8/Q+N7Kdz1EbXNMw0sF3bNrDj4K QyO3JQ2RXQpuEaatWiiCKjkoOVz31ZcULDy5XLx0L955x2elGFOa11kvOf+uc7V2h8d1 Cd04sCPsGBZ1gkb4nn+ZqCuBlwz7ZzjjSVhwQKoXc8ErrVu9VUtPVez4PdmQHORKjT78 ECcQ== 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=t1qCFwfKR6ylAzls4Zrcbs/sJh1vbklt4U6Gl+Uskyw=; b=NkUbjnCxg2Jh8MAoRApWN04ahNtPM7U7gF5WoZRX7wJ+tNrBkWNNDUda32To9E3ic3 gAyQRS+CE5nL3PpqTEffkO7e7QAYLYSpyznCqe9v2q2hz6e7cSG82hDt5nDpEL+JG7e7 b0HUX37pUhdRqrKMVvTZqshwwR0DUS1EQ5iwnCIDTlbTaJE/8+honO+jVNj32fLjTnC7 g7xJTqXWwU/Jxxn2MrrQia1YTqJ1qIL36W89fVx4B8oSiMCCDOvUzCQGN2B4sLTgeKAy YU441dXCGJRhEe8sP+xn1UkDAdluXJb+x1vgYDPEylLCKUfrze5jnZJKVhrJdY9271WX TNyA== X-Gm-Message-State: AMCzsaW3UyZW0Zcyokymf8lgeTnxcsArKMC6jDrwu7vsHVSHNbLGXjYM h1zAAjmzbqN6eq84OEA9+xh4lkczZzNcbYgKJ8rCCg== X-Google-Smtp-Source: ABhQp+SH3HYydtFBpkXjhSga4fOUV0EfvTegQ0VwY4QfLaygY5w2bNKoZmnW4LyqCUD5p10EmKg9pMEYOxXFvEg6NJM= X-Received: by 10.237.36.225 with SMTP id u30mr6437403qtc.13.1509515155101; Tue, 31 Oct 2017 22:45:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Tue, 31 Oct 2017 22:45:54 -0700 (PDT) In-Reply-To: <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org> References: <148341961917.21855.12696727221580481006.idtracker@ietfa.amsl.com> <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org> From: "Stanislav V. Smyshlyaev" Date: Wed, 1 Nov 2017 08:45:54 +0300 Message-ID: To: Dan Harkins Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a11410c9e9a5bea055ce5629e" Archived-At: Subject: Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.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: Wed, 01 Nov 2017 05:45:59 -0000 --001a11410c9e9a5bea055ce5629e Content-Type: text/plain; charset="UTF-8" Dear Dan, During the analysis of Wi-Fi DPP proposal, I've had a chance to look closer at your draft (and many thanks to Liliya Ahmetzyanova for her comments), draft-harkins-pkex-04 . The document is in a pretty good state, in my opinion. Also I don't see any critical problems in the protocol or it's description. However, there are several recommendations that you may find useful. 1. It would be better to indicate point G explicitly (as it is already done for P_I and P_R). Also it would be better to generate new G by the same method as described in your document or in [LMSS]. 2. It seems useful to add checks of X' and Y' for not being equal to the point at infinity. 3. We strongly recommend to describe explicitly possible countermeasures against online brute force attack. For example, they can consist of using counters (so it should be stated when to change it, limitations of their values and what should peers do when this limits are reached, see ([RFC8125] and [RFC8133]). 4. The PKEX protocol translates code into an elliptic curve point in the following way. The code is hashed within other parameters and the hash value is used as a scalar which an elliptic curve point is multiplied by. There exists small but still non-null probability that this hash value turns to zero modulo q, where q is the order of the used elliptic curve point group. If that happens, an ephemeral key is not masked and the overall security of the PKEX protocol is violated. It seems useful to add checks here and introduce some algorithm that changes zero hash value to a nonzero value in a deterministic way. 5. Maybe you consider reasonable to think about using an additional value "salt" to randomize the masking points Q_I and Q_R for different sessions by adding one more argument for hash function. The salt value may be chosen by the Initiator and transferred together with the point M. References: [LMSS]: Lochter, M., Merkle, J., Schmidt, J-M., Schutze, T.: Requirements for Standard Elliptic Curves. Cryptology ePrint Archive, Report 2014/832. [RFC8133]: S. Smyshlyaev (Ed.), E. Alekseev, I. Oshkin, V. Popov, The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol. RFC 8133. [RFC8125]: Schmidt, J.-M.: Requirements for Password-Authenticated Key Agreement (PAKE) Schemes. RFC 8125. Best regards, Stanislav Smyshlyaev 2017-01-03 8:07 GMT+03:00 Dan Harkins : > > New version of the PKEX protocol... changes include cleaning up of how > proof-of-possession is accomplished and some new role-specific (SPAKE2) > elements for some popular FFC groups from RFC 3256. > > This protocol allows for the establishment of trust in "raw" public keys > to be used, subsequently, in protocols like IPsec or TLS. > > Comments are solicited! > > regards, > > Dan. > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-harkins-pkex-03.txt > Date: Mon, 02 Jan 2017 21:00:19 -0800 > From: internet-drafts@ietf.org > To: Dan Harkins > > A new version of I-D, draft-harkins-pkex-03.txt > has been successfully submitted by Dan Harkins and posted to the > IETF repository. > > Name: draft-harkins-pkex > Revision: 03 > Title: Public Key Exchange > Document date: 2017-01-02 > Group: Individual Submission > Pages: 30 > URL: https://www.ietf.org/internet-drafts/draft-harkins-pkex-03.txt > Status: https://datatracker.ietf.org/doc/draft-harkins-pkex/ > Htmlized: https://tools.ietf.org/html/draft-harkins-pkex-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-harkins-pkex-03 > > Abstract: > This memo describes a password-authenticated protocol to allow two > devices to exchange "raw" (uncertified) public keys and establish > trust that the keys belong to their respective identities. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a11410c9e9a5bea055ce5629e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Dan,

<= div>During the analysis of Wi-Fi DPP proposal, I've had a chance to loo= k closer at your draft (and many thanks to Liliya=C2=A0Ahmetzyanova for her= comments), d= raft-harkins-pkex-04.

The document is in a pre= tty good state, in my opinion. Also I don't see any critical problems i= n the protocol or it's description.

However, t= here are several recommendations that you may find useful.

1. It would be better to indicate point G explicitly (as it is alr= eady done for P_I and P_R). Also it would be better to generate new G by th= e same method as described in your document or in [LMSS].
2. It s= eems useful to add checks of X' and Y' for not being equal to the p= oint at infinity.
3.=C2=A0We strongly recommend to describe e= xplicitly possible countermeasures against online brute force attack. For e= xample, they can consist of using counters (so it should be stated when to = change it, limitations of their values and what should peers do when this l= imits are reached, see ([RFC8125] and [RFC8133]).
4.=C2=A0The PKE= X protocol translates code into an elliptic curve point in the following wa= y. The code is hashed within other parameters and the hash value is used as= a scalar which an elliptic curve point is multiplied by. There exists smal= l but still non-null probability that this hash value turns to zero modulo = q, where q is the order of the used elliptic curve point group. If that hap= pens, an ephemeral key is not masked and the overall security of the PKEX p= rotocol is violated. It seems useful to add checks here and introduce some = algorithm that changes zero hash value to a nonzero value in a deterministi= c way.
5. Maybe you consider reasonable to think about using an a= dditional value "salt" to randomize the masking points Q_I and Q_= R for different sessions by adding one more argument for hash function. Th= e salt value may be chosen by the Initiator and transferred together with t= he point M.

References:
[LMSS]: Lochter,= M., Merkle, J., Schmidt, J-M., Schutze, T.: Requirements for Standard Elli= ptic Curves. Cryptology ePrint Archive, Report 2014/832.
[RFC8133= ]:=C2=A0S. Smyshlyaev (Ed.), E. Alekseev, I. Oshkin, V. Popov, The Security= Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Proto= col. RFC 8133.
[RFC8125]: Schmidt, J.-M.: Requirements for Passwo= rd-Authenticated Key Agreement (PAKE) Schemes. RFC 8125.=C2=A0


Best regards,
Stanislav Smyshlyae= v


2017-01-03 8:07 GMT+03:00 Dan Harkins <dh= arkins@lounge.org>:
=20 =20 =20

=C2=A0 = New version of the PKEX protocol... changes include cleaning up of how
proof-of-possession is accomplished and some new role-specific (SPAKE2)
elements for some popular FFC groups from RFC 3256.

=C2=A0 This protocol allows for the establishment of trust in "r= aw" public keys
to be used, subsequently, in protocols like IPsec or TLS.

=C2=A0 Comments are solicited!

=C2=A0 regards,

=C2=A0 Dan.

-------- Forwarded Message --------
Subject: New Version Notification for draft-harkins-pkex-03.txt
Date: Mon, 02 Jan 2017 21:00:19 -0800
From: internet-d= rafts@ietf.org
To: Dan Harkins <dh= arkins@lounge.org> 


A new version of I-D, draft-harkins-pkex-03.txt
has been successfully submitted by Dan Harkins and posted to the
IETF repository.

Name:		draft-harkins-pkex
Revision:	03
Title:		Public Key Exchange
Document date:	2017-01-02
Group:		Individual Submission
Pages:		30
URL:            https://www.ietf.org/internet-drafts/draft-harkins-p=
kex-03.txt
Status:         https://datatracker.ietf.org/doc/draft-harkins-pkex/
Htmlized:       https://tools.ietf.org/html/draft-harkins-pkex-03
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-harkins-pkex-03=


Abstract:
   This memo describes a password-authenticated protocol to allow two
   devices to exchange "raw" (uncertified) public keys and establ=
ish
   trust that the keys belong to their respective identities.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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


--001a11410c9e9a5bea055ce5629e--