From nobody Wed Nov 1 07:41:13 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 3E3A113FCA6 for ; Wed, 1 Nov 2017 07:41:12 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umm25_nKl1O0 for ; Wed, 1 Nov 2017 07:41:10 -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 ED64113FC88 for ; Wed, 1 Nov 2017 07:41:09 -0700 (PDT) X-AuditID: 1209190e-e3fff70000006ad1-da-59f9dd02c027 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (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 19.BB.27345.30DD9F95; Wed, 1 Nov 2017 10:41:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vA1Ef3FO007798; Wed, 1 Nov 2017 10:41:04 -0400 Received: from [18.101.8.118] (VPN-18-101-8-118.MIT.EDU [18.101.8.118]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vA1Ef1tI020947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Nov 2017 10:41:02 -0400 To: "Stanislav V. Smyshlyaev" , Dan Harkins References: <148341961917.21855.12696727221580481006.idtracker@ietfa.amsl.com> <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org> Cc: "cfrg@irtf.org" From: Greg Hudson Message-ID: Date: Wed, 1 Nov 2017 10:41:00 -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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0WW++zPS4PQSa4vuHweZLJb++8Ji cfbmZiYHZo+ds+6ye0zeeJjN49nulywBzFFcNimpOZllqUX6dglcGfv/nmIvWMVZcXHBJbYG xr3sXYycHBICJhLH/h5jAbGFBBYzSbzaqNXFyAVkb2CU+DTrGzOEc4RJov9xAytIlbBAoMTW fcvAbBGBWInzq/qhik4ySlxbsJEJJMEsoCyx7ttMNhCbDchev38r2ApeASuJGTN/ga1mEVCR +LP1BVi9qECExMPOXewQNYISJ2c+AavnBFr25fkTRoiZehI7rv9ihbDlJba/ncM8gVFgFpKW WUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMofDkl+XYwTmrw PsQowMGoxMPrcO1HpBBrYllxZe4hRkkOJiVR3p2O3yOF+JLyUyozEosz4otKc1KLDzFKcDAr ifCeO/MzUog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFqEUxWhoNDSYJX7Q5Qo2BR anpqRVpmTglCmomDE2Q4D9Dwy7dBhhcXJOYWZ6ZD5E8x6nI8m/m6gVmIJS8/L1VKnHceSJEA SFFGaR7cHHDaSeUoe8UoDvSWMK8IyDoeYMqCm/QKaAkT0BIviR8gS0oSEVJSDYxb7E2FAoyk WKOXcYQsjzCTdnr3osRY6dztmlQzCRnGgJXz3L6a2nSnbbb+Kdb87fXzvTJG4f4eb+aqH6ha eJf5smTZ5k9K20tbo62MRPKPtrwo1Fj33cNV4sxKL55YlkutHS7hm2NE/DQj3zwSPv6wMn9V 4XKrRRy/f8/cdJH730MtgYUB35RYijMSDbWYi4oTAejkx/EWAwAA 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 14:41:12 -0000 On 11/01/2017 01:45 AM, Stanislav V. Smyshlyaev wrote: > 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. An active attack against this case (attempting to subvert the DH exchange as if there is no mask) succeeds with probability 1/q, which is no more likely than attempting to subvert the DH exchange using any other specific mask value as an offset. Is that a sufficient reason to add an impossible-to-test special case? > 2. It seems useful to add checks of X' and Y' for not being equal to the > point at infinity. Similarly, what's the justification for adding this special case? From lah@cryptopro.ru Wed Nov 1 09:59:13 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 43B8413F8EA for ; Wed, 1 Nov 2017 09:59:13 -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 EwnEFjmfCIpR for ; Wed, 1 Nov 2017 09:59:11 -0700 (PDT) Received: from mx.cryptopro.ru (mx.cryptopro.ru [193.37.157.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C65E13F8DA for ; Wed, 1 Nov 2017 09:59:07 -0700 (PDT) Received: from orion.cp.ru (192.168.69.205) by pegas.cp.ru (192.168.68.231) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 1 Nov 2017 19:59:04 +0300 Received: from orion.cp.ru (192.168.69.205) by orion.cp.ru (192.168.69.205) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Nov 2017 19:59:03 +0300 Received: from orion.cp.ru ([::1]) by orion.cp.ru ([::1]) with mapi id 15.00.1210.000; Wed, 1 Nov 2017 19:59:03 +0300 From: =?utf-8?B?0JDRhdC80LXRgtC30Y/QvdC+0LLQsCDQm9C40LvQuNGPINCg0YPRgdC70LA=?= =?utf-8?B?0L3QvtCy0L3QsA==?= To: "ghudson@mit.edu" CC: =?utf-8?B?0KHQvNGL0YjQu9GP0LXQsiDQodGC0LDQvdC40YHQu9Cw0LIg0JLQuNGC0LA=?= =?utf-8?B?0LvRjNC10LLQuNGH?= , =?utf-8?B?0JDQu9C10LrRgdC10LXQsiDQldCy0LPQtdC90LjQuSDQmtC+0L3RgdGC0LA=?= =?utf-8?B?0L3RgtC40L3QvtCy0LjRhw==?= , "dharkins@lounge.org" , "cfrg@irtf.org" Thread-Topic: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt Thread-Index: AQHTUyBS+R2C6bkSxUm5nnV1FDGYA6L/ok8ggAAFcMD//86TgIAAMtAg///OHoCAAEVHwA== Date: Wed, 1 Nov 2017 16:59:02 +0000 Message-ID: <778b5914e07343beb01c811c6ba23fe4@orion.cp.ru> References: <148341961917.21855.12696727221580481006.idtracker@ietfa.amsl.com> <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org> <20171101144710.6041682.38708.7138@gmail.com> <40d078a7948c4d47ab35cc96a2d3aefa@orion.cp.ru> <0e6d5e0d9cef48c2900cd45899c0ce3a@orion.cp.ru> <0ac0efbba1c14d639cd77b30b33e17e7@orion.cp.ru> In-Reply-To: <0ac0efbba1c14d639cd77b30b33e17e7@orion.cp.ru> Accept-Language: ru-RU, en-US Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.84.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Thu, 02 Nov 2017 08:32:25 -0000 R29vZCBldmVuaW5nLCBHcmVnIQ0KDQpBbnN3ZXJpbmcgeW91ciBxdWVzdGlvbnM6DQoNCj5BbiBh Y3RpdmUgYXR0YWNrIGFnYWluc3QgdGhpcyBjYXNlIChhdHRlbXB0aW5nIHRvIHN1YnZlcnQgdGhl IERIIGV4Y2hhbmdlIGFzIGlmIHRoZXJlIGlzIG5vIG1hc2spIHN1Y2NlZWRzIHdpdGggcHJvYmFi aWxpdHkgMS9xLCB3aGljaCBpcyBubyBtb3JlIGxpa2VseSB0aGFuID5hdHRlbXB0aW5nIHRvIHN1 YnZlcnQgdGhlIERIIGV4Y2hhbmdlIHVzaW5nIGFueSBvdGhlciBzcGVjaWZpYyBtYXNrIHZhbHVl IGFzIGFuIG9mZnNldC4gSXMgdGhhdCBhIHN1ZmZpY2llbnQgcmVhc29uIHRvIGFkZCBhbiBpbXBv c3NpYmxlLXRvLXRlc3Qgc3BlY2lhbCBjYXNlPw0KDQoJV2UgYWdyZWUgdGhhdCB0aGUgYWJzZW5j ZSBvZiB0aGVzZSBjaGVja3MgaXMgbm90IGNyaXRpY2FsIGZvciB0aGUgcHJvdG9jb2wgc2VjdXJp dHkuDQoNCj5TaW1pbGFybHksIHdoYXQncyB0aGUganVzdGlmaWNhdGlvbiBmb3IgYWRkaW5nIHRo aXMgc3BlY2lhbCBjYXNlPw0KDQoJRmlyc3RseSwgaWYgd2UgZG8gbm90IGFkZCB0aGVzZSBjaGVj a3MgdGhlbiB3ZSBzaG91bGQgZGVmaW5lIHRoZSByZXN1bHQgb2YgbWFwcGluZyBmdW5jdGlvbiBG IGZvciB0aGUgcG9pbnQgYXQgaW5maW5pdHkuDQoNCglBbHNvLCBpbiB0aGUgY2FzZSBvZiB1c2lu ZyBQS0VYIGluIHRoZSBXaUZpIHByb3RvY29sLCB0aGUgYWR2ZXJzYXJ5IGhhcyB0aGUgcGh5c2lj YWwgYWNjZXNzIHRvIGRldmljZXMsIHRoYXQgY2FuIGF1dGhlbnRpY2F0ZSB0aGVpciBwdWJsaWMg a2V5cyB1c2luZyBQS0VYLiANCglTdXBwb3NlIHRoZSBhZHZlcnNhcnkgY2FuIGFmZmVjdCB0aGUg Uk5HIG9mIGRldmljZXMgKGZvciBleGFtcGxlLCBieSBjaGFuZ2luZyB0aGUgdm9sdGFnZSkuIElu IG91ciBwcmFjdGljZSB0aGVyZSB3ZXJlIGNhc2VzLCB3aGVuIFJORyBwcm9kdWNlZCBhIAlzZXF1 ZW5jZSBvZiBvbmx5IHplcm9zIGluIHRoZSBjYXNlIG9mIGhhcmR3YXJlIGZhaWx1cmVzLiBJZiBQ S0VYIGNvcnJlY3RseSBwcm9jZXNzZXMgdGhlIGNhc2Ugb2YgcG9pbnQgYXQgaW5maW5pdHkgKHdh aXRzIGZvciBub24tbnVsbCBtdWx0aXBsaWVyKSwgaXQgd2lsbCBub3QgCWJlIHZ1bG5lcmFibGUg dG8gdGhpcyBraW5kIG9mIGRpY3Rpb25hcnkgYXR0YWNrcy4NCg0KQmVzdCByZWdhcmRzLA0KTGls aXlhIEFraG1ldHp5YW5vdmENCg0KDQpPbiAxMS8wMS8yMDE3IDAxOjQ1IEFNLCBTdGFuaXNsYXYg Vi4gU215c2hseWFldiB3cm90ZToNCj4gNC4gVGhlIFBLRVggcHJvdG9jb2wgdHJhbnNsYXRlcyBj b2RlIGludG8gYW4gZWxsaXB0aWMgY3VydmUgcG9pbnQgaW4gDQo+IHRoZSBmb2xsb3dpbmcgd2F5 LiBUaGUgY29kZSBpcyBoYXNoZWQgd2l0aGluIG90aGVyIHBhcmFtZXRlcnMgYW5kIHRoZSANCj4g aGFzaCB2YWx1ZSBpcyB1c2VkIGFzIGEgc2NhbGFyIHdoaWNoIGFuIGVsbGlwdGljIGN1cnZlIHBv aW50IGlzIA0KPiBtdWx0aXBsaWVkIGJ5LiBUaGVyZSBleGlzdHMgc21hbGwgYnV0IHN0aWxsIG5v bi1udWxsIHByb2JhYmlsaXR5IHRoYXQgDQo+IHRoaXMgaGFzaCB2YWx1ZSB0dXJucyB0byB6ZXJv IG1vZHVsbyBxLCB3aGVyZSBxIGlzIHRoZSBvcmRlciBvZiB0aGUgDQo+IHVzZWQgZWxsaXB0aWMg Y3VydmUgcG9pbnQgZ3JvdXAuIElmIHRoYXQgaGFwcGVucywgYW4gZXBoZW1lcmFsIGtleSBpcyAN Cj4gbm90IG1hc2tlZCBhbmQgdGhlIG92ZXJhbGwgc2VjdXJpdHkgb2YgdGhlIFBLRVggcHJvdG9j b2wgaXMgdmlvbGF0ZWQuDQo+IEl0IHNlZW1zIHVzZWZ1bCB0byBhZGQgY2hlY2tzIGhlcmUgYW5k IGludHJvZHVjZSBzb21lIGFsZ29yaXRobSB0aGF0IA0KPiBjaGFuZ2VzIHplcm8gaGFzaCB2YWx1 ZSB0byBhIG5vbnplcm8gdmFsdWUgaW4gYSBkZXRlcm1pbmlzdGljIHdheS4NCg0KQW4gYWN0aXZl IGF0dGFjayBhZ2FpbnN0IHRoaXMgY2FzZSAoYXR0ZW1wdGluZyB0byBzdWJ2ZXJ0IHRoZSBESCBl eGNoYW5nZSBhcyBpZiB0aGVyZSBpcyBubyBtYXNrKSBzdWNjZWVkcyB3aXRoIHByb2JhYmlsaXR5 IDEvcSwgd2hpY2ggaXMgbm8gbW9yZSBsaWtlbHkgdGhhbiBhdHRlbXB0aW5nIHRvIHN1YnZlcnQg dGhlIERIIGV4Y2hhbmdlIHVzaW5nIGFueSBvdGhlciBzcGVjaWZpYyBtYXNrIHZhbHVlIGFzIGFu IG9mZnNldC4gSXMgdGhhdCBhIHN1ZmZpY2llbnQgcmVhc29uIHRvIGFkZCBhbiBpbXBvc3NpYmxl LXRvLXRlc3Qgc3BlY2lhbCBjYXNlPw0KDQo+IDIuIEl0IHNlZW1zIHVzZWZ1bCB0byBhZGQgY2hl Y2tzIG9mIFgnIGFuZCBZJyBmb3Igbm90IGJlaW5nIGVxdWFsIHRvIA0KPiB0aGUgcG9pbnQgYXQg aW5maW5pdHkuDQoNClNpbWlsYXJseSwgd2hhdCdzIHRoZSBqdXN0aWZpY2F0aW9uIGZvciBhZGRp bmcgdGhpcyBzcGVjaWFsIGNhc2U/DQo= From nobody Thu Nov 2 03:06:52 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 328BE13F5AD for ; Thu, 2 Nov 2017 03:06:51 -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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 ASv3esXjEVnq for ; Thu, 2 Nov 2017 03:06:49 -0700 (PDT) Received: from vsp02.oderland.com (vsp02-out.oderland.com [91.201.60.222]) (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 236F813F4FA for ; Thu, 2 Nov 2017 03:06:48 -0700 (PDT) X-Scanned-Cookie: b12a05d12b23ae622f7215184e090f6a8f986438 Received: from susano.oderland.com (unknown [91.201.63.143]) by vsp-out.oderland.com (Halon) with ESMTPSA id 86e2e905-bfb5-11e7-a9a1-f7b4f2d1c151; Thu, 02 Nov 2017 11:06:43 +0100 (CET) Received: from [80.252.219.35] (port=3546 helo=Knubbis.local) by susano.oderland.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eACOY-002g2g-UF for cfrg@irtf.org; Thu, 02 Nov 2017 11:06:43 +0100 Message-ID: <59FAEE31.4080300@strombergson.com> Date: Thu, 02 Nov 2017 11:06:41 +0100 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Postbox 5.0.20 (Macintosh/20171012) MIME-Version: 1.0 To: "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cfrg] Revive of draft-agl-ckdf? 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, 02 Nov 2017 10:06:51 -0000 Aloha! draft-agl-ckdf is a draft by Adam Langley specifying a block cipher based version of the hash based HKDF in RFC 5869. More specifically, CKDF use AES in CMAC mode to implement the extract and expand stages of HKDF. The 01-draft expired Feb 25, 2016. I've had a brief contact with Langley who stated that he had no further interest in it. But I think the premise in the introduction of the draft still stands. For many IoT devices with really constrained MCUs, if there is cryptographic support in HW, it is an AES-128 core. CKDF would allow these devices to use the same core for key derivation and session protection. In pure SW solutions, having just one primitive makes the code size smaller too. Performance-wise. the number of iterations and thus total cycles will be much smaller for CKDF compared to HKDF, reducing the time to establish sessions. For these reasons, I believe CKDF would provide use case advantages compared to HKDF. Would it be possible to revive the draft? BR Joachim Strömbergson From nobody Thu Nov 2 03:15: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 E919113F66A for ; Thu, 2 Nov 2017 03:15:27 -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 ZDBvsmJ2LokY for ; Thu, 2 Nov 2017 03:15:21 -0700 (PDT) Received: from vsp01.oderland.com (vsp01-out.oderland.com [91.201.60.221]) (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 0BB0013F627 for ; Thu, 2 Nov 2017 03:15:20 -0700 (PDT) X-Scanned-Cookie: b12a05d12b23ae622f7215184e090f6a8f986438 Received: from susano.oderland.com (unknown [91.201.63.143]) by vsp-out.oderland.com (Halon) with ESMTPSA id b65d04ad-bfb6-11e7-ab86-a3cd7704c73a; Thu, 02 Nov 2017 11:15:12 +0100 (CET) Received: from [80.252.219.35] (port=2428 helo=Knubbis.local) by susano.oderland.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eACWh-002hjQ-1x for cfrg@irtf.org; Thu, 02 Nov 2017 11:15:07 +0100 Message-ID: <59FAF029.1030109@strombergson.com> Date: Thu, 02 Nov 2017 11:15:05 +0100 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Postbox 5.0.20 (Macintosh/20171012) MIME-Version: 1.0 To: "cfrg@irtf.org" References: <59FAEE31.4080300@strombergson.com> In-Reply-To: <59FAEE31.4080300@strombergson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cfrg] Revive of draft-agl-ckdf? 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, 02 Nov 2017 10:15:28 -0000 Aloha! Relevant links that I (of course) forgot. https://www.ietf.org/archive/id/draft-agl-ckdf-01.txt https://tools.ietf.org/html/rfc5869 BR JoachimS Joachim Strömbergson wrote: > Aloha! > > draft-agl-ckdf is a draft by Adam Langley specifying a block cipher > based version of the hash based HKDF in RFC 5869. More specifically, > CKDF use AES in CMAC mode to implement the extract and expand stages of > HKDF. > > The 01-draft expired Feb 25, 2016. I've had a brief contact with Langley > who stated that he had no further interest in it. > > But I think the premise in the introduction of the draft still stands. > > For many IoT devices with really constrained MCUs, if there is > cryptographic support in HW, it is an AES-128 core. CKDF would allow > these devices to use the same core for key derivation and session > protection. > > In pure SW solutions, having just one primitive makes the code size > smaller too. Performance-wise. the number of iterations and thus total > cycles will be much smaller for CKDF compared to HKDF, reducing the time > to establish sessions. > > For these reasons, I believe CKDF would provide use case advantages > compared to HKDF. > > Would it be possible to revive the draft? > > BR > Joachim Strömbergson > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu Nov 2 03:18: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 D81DF13F627 for ; Thu, 2 Nov 2017 03:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ryGTqzcpG6SO for ; Thu, 2 Nov 2017 03:18:00 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3BC13F567 for ; Thu, 2 Nov 2017 03:18:00 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id z50so5727381qtj.4 for ; Thu, 02 Nov 2017 03:18:00 -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=czYwa28xTUqDK9LCaGFAWc/FINQ7rvA6LRVLMYM4RnE=; b=JQ5CIgK2mcVMsA9tfsjCKEWrPuJDGeg4VwoWz9XheC+vegVo0LUPz63uklMGqj0nzv G9ju+fTFa3E9KTij0APeXyp/Lmg/WjV8qVDQZ9bvdkKYhpbfitB/kAWhfUaR5RnR78t3 V9kjtgBSCdKvywZrqTH54NUblrvw1XW90bFXQGwsRYG5NN0CnlqhY8vizVW9Wr34VqjK yyyYPWpFmcP61QUfNOBP2N8zn6TeT/HS70SXfZSri2+QtbiYQggQyVs2HeUBubC6cG+o V5/5qEH+WGqkTrpLov0xPghnMam8IbF9RYX86w1kwCkob4+m1XSgbqCgihtjodtwKr8T kkfg== 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=czYwa28xTUqDK9LCaGFAWc/FINQ7rvA6LRVLMYM4RnE=; b=JM4BSzSN/veFxTtCWB7QhxKu65sXjQWuZJ3BO8C+pwU1Y23NB3bGhX0/gJDJbsy8hT 5uDZHHLEJCD5gePnhGnrd0lQ40lFhjJhazLyQwVeIrWWnlK4RMEeBbIjEFWsigekyQFJ /x0JhlOWpYoRKRyinC443i7eXMPFIlP2MuTldAZd2HvVGbG8UQOMLFqUvdJXcLB8EbTN ajmYK5Np43D6YES+4hFvk8vJ7wLgT8IhMlRx4HazekJDGqSw/K5PQYTnFXx33UfSU2ac oRbJlS3jOHalNDr/tizVROm8/quyr5gEXDP49uo5IFy3tFrR31MFQhhtube5USAYZrgx QVvA== X-Gm-Message-State: AMCzsaVYO0kz54fFP0JppOy2rz5IgvY2jJ+M8cAwX0ZmCKYxv09i7dbk 2t5SxcG6f9OVV+QVHlBUx2oJ24JHImeo4Qp3bOAZhg== X-Google-Smtp-Source: ABhQp+TzklmG1YxLBT7q9Rl92hrB3XW7f+KzWfZWELUqHyl2DetUJ+ceuJjrrqo5j67hmelhdH3TfhGIhfBvS2+hAn0= X-Received: by 10.200.26.15 with SMTP id v15mr4117513qtj.62.1509617879372; Thu, 02 Nov 2017 03:17:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Thu, 2 Nov 2017 03:17:58 -0700 (PDT) In-Reply-To: <59FAF029.1030109@strombergson.com> References: <59FAEE31.4080300@strombergson.com> <59FAF029.1030109@strombergson.com> From: "Stanislav V. Smyshlyaev" Date: Thu, 2 Nov 2017 13:17:58 +0300 Message-ID: To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="f403045d61f87259f3055cfd4d10" Archived-At: Subject: Re: [Cfrg] Revive of draft-agl-ckdf? 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, 02 Nov 2017 10:18:04 -0000 --f403045d61f87259f3055cfd4d10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Joachim, Maybe it would be useful to draw your attention to the https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ I-D, which employs HKDF for external re-keying based on hash and a construction based on Mihir Bellare's paper for external re-keying based on block cipher. Do you think it will be reasonable to use CKDF instead of that construction? Best regards, Stanislav Smyshlyaev, Ph.D. Head of Information Security Department, CryptoPro LLC 2017-11-02 13:15 GMT+03:00 Joachim Str=C3=B6mbergson : > Aloha! > > Relevant links that I (of course) forgot. > > https://www.ietf.org/archive/id/draft-agl-ckdf-01.txt > https://tools.ietf.org/html/rfc5869 > > BR > JoachimS > > Joachim Str=C3=B6mbergson wrote: > > Aloha! > > > > draft-agl-ckdf is a draft by Adam Langley specifying a block cipher > > based version of the hash based HKDF in RFC 5869. More specifically, > > CKDF use AES in CMAC mode to implement the extract and expand stages of > > HKDF. > > > > The 01-draft expired Feb 25, 2016. I've had a brief contact with Langle= y > > who stated that he had no further interest in it. > > > > But I think the premise in the introduction of the draft still stands. > > > > For many IoT devices with really constrained MCUs, if there is > > cryptographic support in HW, it is an AES-128 core. CKDF would allow > > these devices to use the same core for key derivation and session > > protection. > > > > In pure SW solutions, having just one primitive makes the code size > > smaller too. Performance-wise. the number of iterations and thus total > > cycles will be much smaller for CKDF compared to HKDF, reducing the tim= e > > to establish sessions. > > > > For these reasons, I believe CKDF would provide use case advantages > > compared to HKDF. > > > > Would it be possible to revive the draft? > > > > BR > > Joachim Str=C3=B6mbergson > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --f403045d61f87259f3055cfd4d10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Joachim,

<= /div>
Maybe it would be useful to draw your attention to the=C2=A0https://= datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/=C2=A0 I-D, which em= ploys HKDF for external re-keying based on hash and a construction based on= Mihir Bellare's paper for external re-keying based on block cipher. Do= you think it will be reasonable to use CKDF instead of that construction?<= /div>

=C2= =A0

Best regards,

Stanislav Smyshlyaev, Ph.D.

Head of Information Security Department,
CryptoPro LLC


2017-11-02 13:15 GMT+03:00 Joachim Str=C3=B6= mbergson <joachim@strombergson.com>:
Aloha!

Relevant links that I (of course) forgot.

https://www.ietf.org/archive/id/draft-agl-= ckdf-01.txt
https://tools.ietf.org/html/rfc5869

BR
JoachimS

Joachim Str=C3=B6mbergson wrote:
> Aloha!
>
> draft-agl-ckdf is a draft by Adam Langley specifying a block cipher > based version of the hash based HKDF in RFC 5869. More specifically, > CKDF use AES in CMAC mode to implement the extract and expand stages o= f
> HKDF.
>
> The 01-draft expired Feb 25, 2016. I've had a brief contact with L= angley
> who stated that he had no further interest in it.
>
> But I think the premise in the introduction of the draft still stands.=
>
> For many IoT devices with really constrained MCUs, if there is
> cryptographic support in HW, it is an AES-128 core. CKDF would allow > these devices to use the same core for key derivation and session
> protection.
>
> In pure SW solutions, having just one primitive makes the code size > smaller too. Performance-wise. the number of iterations and thus total=
> cycles will be much smaller for CKDF compared to HKDF, reducing the ti= me
> to establish sessions.
>
> For these reasons, I believe CKDF would provide use case advantages > compared to HKDF.
>
> Would it be possible to revive the draft?
>
> BR
> Joachim Str=C3=B6mbergson
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--f403045d61f87259f3055cfd4d10-- From nobody Thu Nov 2 05:47:00 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8D13F4CB for ; Thu, 2 Nov 2017 05:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 eAO6552hrh-t for ; Thu, 2 Nov 2017 05:46:57 -0700 (PDT) Received: from smtp1.science.ru.nl (smtp1.science.ru.nl [131.174.16.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042A113F45D for ; Thu, 2 Nov 2017 05:46:56 -0700 (PDT) Received: from localhost.localdomain (ip-145-116-135-218.wlan-int.ru.nl [145.116.135.218]) (authen=benoit) by smtp1.science.ru.nl (8.14.4/5.32) with ESMTP id vA2CkrIe011776 for ; Thu, 2 Nov 2017 13:46:53 +0100 From: =?UTF-8?Q?Beno=c3=aet_Viguier?= To: cfrg@irtf.org Message-ID: <9525ba1b-42be-05f5-bf3c-44bd76011686@science.ru.nl> Date: Thu, 2 Nov 2017 12:46:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Cfrg] Status of KangarooTwelve draft 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, 02 Nov 2017 12:46:59 -0000 Dear CFRG participants, Due to time and expense constraints, I will not be presenting the KangarooTwelve draft (https://tools.ietf.org/html/draft-viguier-kangarootwelve-00) at the CFRG meeting in Singapore. I heard David Wong's remarks and the feedback provided to Quynh Dang in Prague and will address these points into the next version of the draft (to be expected in early December). I will participate and request a time slot at the next CFRG meeting on London. -- Kind regards, Benoît Viguier Software Engineer - PhD Student | Cryptography & Formal Methods Radboud University | Mercator 1, room 03.17, Toernooiveld 212 6525 EC Nijmegen, the Netherlands | www.viguier.nl -------------------------------------------------------------------------- This message (and any attachments) is intended solely for the addressee(s) and may contain confidential information. If you are not the addressee, do not copy this message (and any attachments), forward or share this message with third parties. You are requested to notify the sender immediately and delete this message. From nobody Thu Nov 2 11:17:20 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3113F7C6 for ; Thu, 2 Nov 2017 11:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 05IZyUTTLGqc for ; Thu, 2 Nov 2017 11:17:18 -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 CB8CF13F7B7 for ; Thu, 2 Nov 2017 11:17:14 -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 vA2IH791005874 for ; Thu, 2 Nov 2017 18:17:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Ns7m7n3cIi3xVB/uxbcr5Y3Ns7o4F9YUtSgZ47DmyfA=; b=dt7vENLpo8Pus1+CJSkiWf3j4WzEyxiOSGLY1xWxn7SIvxFnyi/AvGbnx1m4cwjjyT7J +eCN8ncCWO42HDJUEb3PE4hcxT4DC6W77jJreEi7Ke8GSLZFEAFXSrjbbtTdSfu3D6VM 7/z8Zq/xVZ96jFL16c2wUghoya25gwhfmTYkW0Kww+3uGFyNW3dG1Us5kGqsCDMAz94z HUFKylM1gRO70PtMfC9L+ZsFaJQ5N9r+VuPfhhF57BQJ/CWxGPw5hnRiOK/2dF/5uUxL 02Bbavg5geMhoTbndxPy0vIt1p/+MGrfFHmVdVVVb7auVjBWucltOEYLohjVhbWvJ6X6 mQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dyu0aak1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 02 Nov 2017 18:17:14 +0000 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 vA2IFsQA032004 for ; Thu, 2 Nov 2017 14:17:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7u7h6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 02 Nov 2017 14:17:13 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Nov 2017 14:17:12 -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; Thu, 2 Nov 2017 14:17:12 -0400 From: "Salz, Rich" To: "cfrg@irtf.org" Thread-Topic: NIST to include 25519 and 448 in their approved curves Thread-Index: AQHTVAbNNY8uCBfFtUObjU8kO0VTZg== Date: Thu, 2 Nov 2017 18:17:12 +0000 Message-ID: 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.32.108] Content-Type: multipart/alternative; boundary="_000_F3FEB041DA344365B9FA74C9510FF394akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 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-1711020222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=2 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=2 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020222 Archived-At: Subject: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 02 Nov 2017 18:17:20 -0000 --_000_F3FEB041DA344365B9FA74C9510FF394akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZ3JhdHMgdG8gYWxsIGludm9sdmVkLg0KDQpodHRwczovL2NzcmMubmlzdC5nb3YvTmV3cy8y MDE3L1RyYW5zaXRpb24tUGxhbnMtZm9yLUtleS1Fc3RhYmxpc2htZW50LVNjaGVtZXMNCg0KSW4g YWRkaXRpb24sIE5JU1QgZ3VpZGVsaW5lcyBvbiBFbGxpcHRpYyBDdXJ2ZSBDcnlwdG9ncmFwaHkg YXJlIGFsc28gYmVpbmcgcmV2aXNlZCB0byBwcm9wb3NlIHRoZSBhZG9wdGlvbiBvZiBuZXcgZWxs aXB0aWMgY3VydmVzIHNwZWNpZmllZCBpbiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBG b3JjZSAoSUVURikgUkZDIDc3NDguIFRoZSB1cGNvbWluZyBkcmFmdCBvZiBTUCA4MDAtMTg2LCB3 aGljaCB3aWxsIHNwZWNpZnkgYXBwcm92ZWQgZWxsaXB0aWMgY3VydmVzLCB3aWxsIGluY2x1ZGUg dGhlIGN1cnZlcyBjdXJyZW50bHkgc3BlY2lmaWVkIGluIEZJUFMgMTg2LTQgYW5kIHR3byBhZGRp dGlvbmFsIGN1cnZlczogQ3VydmUyNTUxOSBhbmQgQ3VydmU0NDguICBUaGVpciBhc3NvY2lhdGVk IGtleSBhZ3JlZW1lbnQgc2NoZW1lcywgWDI1NTE5IGFuZCBYNDQ4LCB3aWxsIGJlIGNvbnNpZGVy ZWQgZm9yIGluY2x1c2lvbiBpbiBhIHN1YnNlcXVlbnQgcmV2aXNpb24gdG8gU1AgODAwLTU2QS4g IFRoZSBDTVZQIGRvZXMgbm90IGludGVuZCB0byBlbmZvcmNlIGNvbXBsaWFuY2Ugd2l0aCBTUCA4 MDAtNTZBIHVudGlsIHRoZXNlIHJldmlzaW9ucyBhcmUgY29tcGxldGUuDQoNCg== --_000_F3FEB041DA344365B9FA74C9510FF394akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <35AE6AB8CE96514AB1DEDAD6795F961C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25ncmF0cyB0byBhbGwgaW52b2x2ZWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRw czovL2NzcmMubmlzdC5nb3YvTmV3cy8yMDE3L1RyYW5zaXRpb24tUGxhbnMtZm9yLUtleS1Fc3Rh Ymxpc2htZW50LVNjaGVtZXMiPmh0dHBzOi8vY3NyYy5uaXN0Lmdvdi9OZXdzLzIwMTcvVHJhbnNp dGlvbi1QbGFucy1mb3ItS2V5LUVzdGFibGlzaG1lbnQtU2NoZW1lczwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIGFkZGl0aW9uLCBOSVNUIGd1aWRlbGlu ZXMgb24gRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IGFyZSBhbHNvIGJlaW5nIHJldmlzZWQg dG8gcHJvcG9zZSB0aGUgYWRvcHRpb24gb2YgbmV3IGVsbGlwdGljIGN1cnZlcyBzcGVjaWZpZWQg aW4gdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpIFJGQyA3NzQ4LiBU aGUgdXBjb21pbmcNCiBkcmFmdCBvZiBTUCA4MDAtMTg2LCB3aGljaCB3aWxsIHNwZWNpZnkgYXBw cm92ZWQgZWxsaXB0aWMgY3VydmVzLCB3aWxsIGluY2x1ZGUgdGhlIGN1cnZlcyBjdXJyZW50bHkg c3BlY2lmaWVkIGluIEZJUFMgMTg2LTQgYW5kIHR3byBhZGRpdGlvbmFsIGN1cnZlczogQ3VydmUy NTUxOSBhbmQgQ3VydmU0NDguJm5ic3A7IFRoZWlyIGFzc29jaWF0ZWQga2V5IGFncmVlbWVudCBz Y2hlbWVzLCBYMjU1MTkgYW5kIFg0NDgsIHdpbGwgYmUgY29uc2lkZXJlZCBmb3INCiBpbmNsdXNp b24gaW4gYSBzdWJzZXF1ZW50IHJldmlzaW9uIHRvIFNQIDgwMC01NkEuJm5ic3A7IFRoZSBDTVZQ IGRvZXMgbm90IGludGVuZCB0byBlbmZvcmNlIGNvbXBsaWFuY2Ugd2l0aCBTUCA4MDAtNTZBIHVu dGlsIHRoZXNlIHJldmlzaW9ucyBhcmUgY29tcGxldGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F3FEB041DA344365B9FA74C9510FF394akamaicom_-- From nobody Thu Nov 2 12:13:39 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 F35AD13F77C for ; Thu, 2 Nov 2017 12:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 yMMu0phFKqMI for ; Thu, 2 Nov 2017 12:13:36 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 2859013F5CF for ; Thu, 2 Nov 2017 12:13:36 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id q83so650719qke.6 for ; Thu, 02 Nov 2017 12:13:36 -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=+BmG1KHyEj0vXkNZvti4tR6KFy9LbyAHm9gpX/7JQ/Q=; b=IXXeXwFLr7Ihmb6yuLN+dhvQ8gAzxwyzG8QjEcSzyLtauxAzLkCWY1nAm/Egc0xqF4 mYaGiMa42HuJ6DsC2EUwzJ9wuyecMi2wK8Ua6yvzTB3sCuIz2kha5uBE9hCaqHTnnZd+ Ut9X2/YJTqxoOh66xD1h3SnKTZJMoWwkfeo5PskSB0shU9GEBEHkSUYGU3fasMOcaMKU 5EqknlT/f6Acwcj7ffR/BPnQUmxJn7+B/GY02iHzes0HGZAx4VC6IDSL4EiL40bKK58m Cj8/ZGCRARyoZkCmJfQ6UzQgWEynwkyYcS3XnDwAMpI9XZPBoSg5355ZiWROD/VAZ42q SLKw== 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=+BmG1KHyEj0vXkNZvti4tR6KFy9LbyAHm9gpX/7JQ/Q=; b=AGEJbeDvr2wbFxmL/wTuTlNyflC5sbk/hFmgx1lqUjtEthVMMFmcc6NNWYwG4xAVxL C2X7Lkp20aGwrP4CCYddhhjmhqlGRjo7/N3yycleSkGEl51VJAaOWUPGC2Syf5RNm5mP ZeVeBTYCHjfEVtvB7/IMszplkFT+PCQ+lDfjMw/neghtdkCI2XLWBse2Wtx8wO5Klbpo mM5WwLwZvGxjDf6Qc10phqHqx8CfPw/Gxoo/Yj43HOKLiE/P3ZunZoPiRuGaR1EsikJF +G8dNfwdvylGg4lGxnXrlse6xcwznlWOcGrSJgksx1e8lh31lBo5ygHLog43XrCAl0fY bGdg== X-Gm-Message-State: AJaThX6vMdoblG8BCa6SgkVdfMdO/OLxO5nRRMRHIZQKB1EMdLACeajw +4Z4lbT8JaQk/H+nkHSvSaxJPSHkiRhXwUqhS7Q= X-Google-Smtp-Source: ABhQp+TQyGIDkXfsRIzHsw81zZBzqTbFrbpJzXkgmD2cnuHjMFPF9lkQ6H/792mGQTENRNCuewR+wQy9+cchZXS8+Kk= X-Received: by 10.55.93.135 with SMTP id r129mr6226982qkb.36.1509650013937; Thu, 02 Nov 2017 12:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.11 with HTTP; Thu, 2 Nov 2017 12:13:13 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Thu, 2 Nov 2017 12:13:13 -0700 Message-ID: To: "Salz, Rich" Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114c91d2d0e55f055d04c8c0" Archived-At: Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 02 Nov 2017 19:13:38 -0000 --001a114c91d2d0e55f055d04c8c0 Content-Type: text/plain; charset="UTF-8" Great news! --001a114c91d2d0e55f055d04c8c0 Content-Type: text/html; charset="UTF-8"
Great news!
--001a114c91d2d0e55f055d04c8c0-- From nobody Fri Nov 3 03:04:58 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 45DC913FD3F for ; Fri, 3 Nov 2017 03:04:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 L7VlI2rtnFE3 for ; Fri, 3 Nov 2017 03:04:54 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0129.outbound.protection.outlook.com [23.103.200.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC2413FD39 for ; Fri, 3 Nov 2017 03:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xGqA6RmlyM+131sxEjTjs2FOjfI4sHkte2u+pS0G97E=; b=k12Ig+fLbYPNNFNN8ieTi8OSi7P14BoxYFwa9Sghpwfna9dwXEdVhAyRRfD0Nd+5thKd/nOVTj28x0tEdiWt26LgUUDmUcdLryOeL6IO1YCwtVQ/ivQeOvZkBuHwFYWYxt40WViVxlY2piTV9RverJSbjW46T3vtpZrP6vHGNLs= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1463.namprd09.prod.outlook.com (10.173.191.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 3 Nov 2017 10:04:51 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.20.0178.016; Fri, 3 Nov 2017 10:04:51 +0000 From: "Dang, Quynh (Fed)" To: Tony Arcieri , "rsalz@akamai.com" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] NIST to include 25519 and 448 in their approved curves Thread-Index: AQHTVAbNNY8uCBfFtUObjU8kO0VTZqMBdTSAgAD4rj0= Date: Fri, 3 Nov 2017 10:04:51 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.220.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1463; 6:ODxPji4W2m0O/zdLJbI2/RLilKJprB54Go8lv11QkpCcKo1q+xPxl5ZYYIUE3XnIK035gOsvcOp3BCBRLjqjtAnCgzz8lUi3rAabdvbEXMbu5AbkXRIjHFgFpGxgUjZcEtV9AFhlwTwBjADop/0Pp7+MsgLw2YA/DCq8k8qn5Rc99hZaYC8fKvTao90lbTQOcvjJim3HGXif3m+o9qfHtkSULSfzuNQvlCBGGR89QKEGMml20uqKxY1/1h8qmA55h4XAnlLaMn5dSYXMZSt2CWmSPmztnQwDJSIBF8Z09PZXayFh/p918GAzjei8Vg8kPiaVUCAZrZOgw20ZZEVPkGO2XEmhMsHX6qL4DtGgxWA=; 5:9o1QGKFMzqGKdcDCtq7MH6018z1UP6Ku4Ho4Lc6AZ9/JWLOKFnK02CdsfgDGtLIpQsX6u4ErhiLMjGmJzeXjqF+2DkVXMR/uloWhugnmpqLySXhvDpNWy8wHOa8q9gavLnJj2oqX8Q2Aq1sejJ48OSZtERWb2X3DuLH6KLeYuMY=; 24:EwC8e2DbVktVtTdiBwg7bZ7O2csYQuEN5oowVoKVQEW5J8rfdsncrl/xo4GmrQtaeL45kL31+51T9BOUMCv//BQYQlnrM1qdbHjpfJtK2qM=; 7:eGApi3y4S0uyUwdQDym1kQmVCX+lIJE57y31g5+MkIIUQWT9OjOOqSWHMWBPO+Vl5ZAiIkEzVyfXEGhrzJu2O1cGUwqeYzoteailgwDqb0EN2Udo8gW9Z8BaXGmHnOPAic8Lun7l14BbqRzF8xR/0E+ykDEgeHNg+8i/CjUUGi2hg+yvhakXr3+/UqyeaPI/kQkt0jiOePuXiF/hFNa+qBFdfrzkiZ6H+v5MjxFycsmyPuFo3vo2tbZKkBhWqN21 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 47bc40bf-0508-47c0-432b-08d522a252ed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1463; x-ms-traffictypediagnostic: CY4PR09MB1463: x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231021)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1463; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1463; x-forefront-prvs: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(9686003)(110136005)(8936002)(81166006)(81156014)(8676002)(55016002)(86362001)(2501003)(77096006)(66066001)(54896002)(478600001)(14454004)(106356001)(54356999)(6606003)(53546010)(229853002)(25786009)(6506006)(50986999)(316002)(76176999)(6436002)(19627405001)(105586002)(101416001)(68736007)(6246003)(39060400002)(2950100002)(53936002)(4326008)(74316002)(33656002)(3846002)(7696004)(3660700001)(6116002)(102836003)(189998001)(5660300001)(99286004)(7736002)(2900100001)(97736004)(3280700002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1463; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146499128F32DBE60809D9B2F35D0CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 47bc40bf-0508-47c0-432b-08d522a252ed X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 10:04:51.3183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1463 Archived-At: Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 03 Nov 2017 10:04:56 -0000 --_000_CY4PR09MB146499128F32DBE60809D9B2F35D0CY4PR09MB1464namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NIST appreciates the great work by the CFRG. Regards, Quynh. ________________________________ From: Cfrg on behalf of Tony Arcieri Sent: Thursday, November 2, 2017 3:13:13 PM To: rsalz@akamai.com Cc: cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves Great news! --_000_CY4PR09MB146499128F32DBE60809D9B2F35D0CY4PR09MB1464namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NIST appreciates the great work by the CFRG.


Regards,

Quynh. 

From: Cfrg <cfrg-bounces= @irtf.org> on behalf of Tony Arcieri <bascule@gmail.com>
Sent: Thursday, November 2, 2017 3:13:13 PM
To: rsalz@akamai.com
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved = curves
 
Great news!
--_000_CY4PR09MB146499128F32DBE60809D9B2F35D0CY4PR09MB1464namp_-- From nobody Fri Nov 3 03:34:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9513FD5F for ; Fri, 3 Nov 2017 03:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jB5Oux7CAHSr for ; Fri, 3 Nov 2017 03:34: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 186A813FD57 for ; Fri, 3 Nov 2017 03:34:33 -0700 (PDT) X-Spoof: Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2017 06:34:32 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0319.002; Fri, 3 Nov 2017 06:34:32 -0400 From: Dan Brown To: "Dang, Quynh (Fed)" , Tony Arcieri , "rsalz@akamai.com" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] NIST to include 25519 and 448 in their approved curves Thread-Index: AQHTVAbNNY8uCBfFtUObjU8kO0VTZqMBuEKAgAD5HoD//8U9Gg== Date: Fri, 3 Nov 2017 10:34:31 +0000 Message-ID: <20171103103429.8577110.71203.19019@blackberry.com> References: , , In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2017110310342985771107120319019blackberrycom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 03 Nov 2017 10:34:36 -0000 --_000_2017110310342985771107120319019blackberrycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Credit is most due to djb. From: Dang, Quynh (Fed) Sent: Friday, November 3, 2017 6:05 AM To: Tony Arcieri; rsalz@akamai.com Cc: cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves NIST appreciates the great work by the CFRG. Regards, Quynh. ________________________________ From: Cfrg on behalf of Tony Arcieri Sent: Thursday, November 2, 2017 3:13:13 PM To: rsalz@akamai.com Cc: cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves Great news! --_000_2017110310342985771107120319019blackberrycom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Dang, Quynh (Fed)
Sent: Friday, November 3, 2017 6:05 AM
To: Tony Arcieri; rsalz@akamai.com
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their appr= oved curves

NIST appreciates the great work by the CFRG.


Regards,

Quynh. 

From: Cfrg <cfrg-bounces= @irtf.org> on behalf of Tony Arcieri <bascule@gmail.com>
Sent: Thursday, November 2, 2017 3:13:13 PM
To: rsalz@akamai.com
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved = curves
 
Great news!
--_000_2017110310342985771107120319019blackberrycom_-- From nobody Fri Nov 3 04:03:26 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BE613FD82 for ; Fri, 3 Nov 2017 04:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=onboardsecurity.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 warLtRaVm-1G for ; Fri, 3 Nov 2017 04:03:22 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB97813FD7E for ; Fri, 3 Nov 2017 04:03:21 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id j15so2156649wre.8 for ; Fri, 03 Nov 2017 04:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UviE24wR73l69NpJYRlYzbG7Ob+9Hmpp0l4bhiGJtAs=; b=fGVowK9kAKn57h8o8b2S8rVx/4zXOmTZYwGalc8jLhyxWFsohh9VxCzD7Wuf48tWrm UB0yL7IQwO+JBl1QTMglYcamEyfGbc/PF2V8/cAqgZcvVE7Ag6BxQg699D0YsdSncSxx Lkd7GI/IJJx+qOqFnVV6oqPqzpNANP7S9X7UQ= 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=UviE24wR73l69NpJYRlYzbG7Ob+9Hmpp0l4bhiGJtAs=; b=GZxGxNaQSTrysR5GPZsxDiqaiXAtnHvRdBci/3Kf4vmboCHZt16BlsbbIrlyZrOPku wBhOWWMMifhVn4rc88Dk9P68XqyvObuoWVvPUcTMoxvvQHbASDlOvx4LRG0yMBx9IL2n u5yvFjAw5YYItmSLypFLG+xQDla01spGee6P7hsCYkv9kNimrmVPjBxvquAWjYMO6F3o RKR6/NFSph0KSno2bZlDcwaVhORAcQ+KjdhwMh1LmYkCnSqoiyNsSyb25OeJK3w/TQjh Lkpad+3NBYeXkIm99G6DiHkAApXtsgWPBaHj70D0+2I+sMaxK+DrVpDQAEAjX+DbR9TQ m4bQ== X-Gm-Message-State: AMCzsaWF1DES6l648jnFq5gAUp45rTeULF+/ej+mrMkoJhowvUTkgL0Y PxFkx5e86VfRvzqOamDvolDzE5SSo0wHph0GQouuEw== X-Google-Smtp-Source: ABhQp+TkJ7k4ojy0K9Fz+c5Hr6khlCwCA/LP2d+sAbJ5B+UEjdCQrjOJEF1TFGCWEzEMcs7XqZFjKns1pLDl7xzELHg= X-Received: by 10.223.174.142 with SMTP id y14mr4947129wrc.222.1509707000251; Fri, 03 Nov 2017 04:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.173.201 with HTTP; Fri, 3 Nov 2017 04:02:59 -0700 (PDT) In-Reply-To: <20171103103429.8577110.71203.19019@blackberry.com> References: <20171103103429.8577110.71203.19019@blackberry.com> From: William Whyte Date: Fri, 3 Nov 2017 07:02:59 -0400 Message-ID: To: Dan Brown Cc: "Dang, Quynh (Fed)" , Tony Arcieri , "rsalz@akamai.com" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a113c3c60774110055d120d97" Archived-At: Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 03 Nov 2017 11:03:24 -0000 --001a113c3c60774110055d120d97 Content-Type: text/plain; charset="UTF-8" Is there any chance that NIST will permit eddsa? Cheers, William On Fri, Nov 3, 2017 at 6:34 AM, Dan Brown wrote: > Credit is most due to djb. > > *From: *Dang, Quynh (Fed) > *Sent: *Friday, November 3, 2017 6:05 AM > *To: *Tony Arcieri; rsalz@akamai.com > *Cc: *cfrg@irtf.org > *Subject: *Re: [Cfrg] NIST to include 25519 and 448 in their approved > curves > > NIST appreciates the great work by the CFRG. > > > Regards, > > Quynh. > ------------------------------ > *From:* Cfrg on behalf of Tony Arcieri < > bascule@gmail.com> > *Sent:* Thursday, November 2, 2017 3:13:13 PM > *To:* rsalz@akamai.com > *Cc:* cfrg@irtf.org > *Subject:* Re: [Cfrg] NIST to include 25519 and 448 in their approved > curves > > Great news! > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --001a113c3c60774110055d120d97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there any chance that NIST will permit eddsa?=C2=A0
Cheers,

William

On Fri, Nov 3, 2017 at 6= :34 AM, Dan Brown <danibrown@blackberry.com> wrote:
Credit is most due to djb.

From: Dang, Quynh (Fed)
Sent: Friday, November 3, 2017 6:05 AM
To: Tony Arcieri; rsalz@akamai.com
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their appr= oved curves

NIST appreciates the great work by the CFRG.


Regards,

Quynh.=C2=A0

From:= Cfrg <cfrg-b= ounces@irtf.org> on behalf of Tony Arcieri <bascule@gmail.com>
Sent: Thursday, November 2, 2017 3:13:13 PM
To: rsalz@akam= ai.com
Cc: cfrg@irtf.org=
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved = curves
=C2=A0
Great news!

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




--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW = ADDRESS: ww= hyte@onboardsecurity.com
--001a113c3c60774110055d120d97-- From nobody Fri Nov 3 04:08: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 D188D13FD87 for ; Fri, 3 Nov 2017 04:08:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 GNpxuuNlgf90 for ; Fri, 3 Nov 2017 04:08:38 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0097.outbound.protection.outlook.com [23.103.201.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5E913FD84 for ; Fri, 3 Nov 2017 04:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SjVtWWFM2v9fIznIvsyAlzeWVa/SS1+i5OgFv+zqPRY=; b=vU83k3BO5z0GsXJWFsd7NfosrOmBEuLXSYTVHjVqQSNaKam2Bd1M1GjVV3vJfSepB4T02zG/12W5lKaW+fsJoRKXZArub1WzxpUCPNiKRNOrVD/Qk5GabU6DtoYS9pltNVEOpiyfPQ6PrVI0o4PI7+jdLkHruMCvA6rzz4vbiYo= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 3 Nov 2017 11:08:35 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.20.0178.016; Fri, 3 Nov 2017 11:08:35 +0000 From: "Dang, Quynh (Fed)" To: William Whyte , Dan Brown CC: Tony Arcieri , "rsalz@akamai.com" , "cfrg@irtf.org" Thread-Topic: [Cfrg] NIST to include 25519 and 448 in their approved curves Thread-Index: AQHTVAbNNY8uCBfFtUObjU8kO0VTZqMBdTSAgAD4rj2AAAi6gIAAB/SAgAABQLw= Date: Fri, 3 Nov 2017 11:08:35 +0000 Message-ID: References: <20171103103429.8577110.71203.19019@blackberry.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.220.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 6:faDJU/ZPgjjmraIo2LcjzEk0rzmFWQbKBJ4dtkTzxTz2UUet5wvO8SCbmFQGKg4fik65oGBRI/RTEzHrCzp09lt8hhFQqH7UhtSoEJE+W0eiot0MJ7avutTsVqxUCZYikyjuUIjr1NAjODkBdn9OqHWX9PO0+wdoPWXIVk1N19HexUVNv0D5OhOY/HEcxSvAA785iexh83stvIO0pdPPjOMu9WNolleyzd6SeR4UCuhJ4q+K896psi7GqvLPGyMCm2BqDeOO9Ez2lZvZ0QU5eksgMo9eAeYHrooqZbb4rOIdggp9r1Da2pJfdw3GlsSyejYVMFZnTK/GGMF6Z8dJNWtxD+wrDrUtNa+wgG1lnuU=; 5:1qwd3ZrvVCAz7XGnNILNYNTWgJkEuPHn0FNVfCBcMKJ4PwtTe+1v7GR8JiWRf2T+Lig7d2EBxWWQyBak2N7VXv7pb1Xg05Dj/lbW1l25i6Ek/EBUQ8syOtr8IGK3fgs0QA2s+6SVTzgUfAyaDGi9O9CQfC21LZKM0FbSMFCe+TQ=; 24:Y8ngae6Sg4bhMSfvaS4eMFP/j7sZr9WB9ErfuoYTx8ZmcrLtX/QLEmuLzYXXqXK58pXrnI0Vh9jx3cLBnzQPxLChNlA5yiHFTQ62dYmwY0k=; 7:i33JDMEkQtOv1KIML5UaDpklYaFLZIZEBoTFUnzhcB0xksnPOyb8xPzqULdRqFZQ3To28R/OH8iyrjqQOgDG2sPSsqtGz8mxhMrbbxa6DFIFaWVYwOg6ms1NemN1/fXz7a8jEaugcYBbcI7Rn6RqkobxstJ6nBfXhaD24XO/raQXcz5yg70HgiQGjDWRTKwltCZxoMngGQxBmTAkkxzZDnr7jxSapmhC4uT1JDTioVQtxS4V9qK9yYo7syOnQlou x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8d5f98cc-d741-4c56-4466-08d522ab3a6d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:CY4PR09MB1462; x-ms-traffictypediagnostic: CY4PR09MB1462: x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); 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)(100000703101)(100105400095)(10201501046)(3231021)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1462; x-forefront-prvs: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(189002)(199003)(24454002)(6506006)(77096006)(7736002)(53546010)(4326008)(5660300001)(97736004)(68736007)(606006)(6606003)(6436002)(25786009)(101416001)(2950100002)(105586002)(106356001)(33656002)(74316002)(7696004)(316002)(39060400002)(189998001)(93886005)(102836003)(6116002)(3846002)(86362001)(110136005)(54906003)(2900100001)(229853002)(2906002)(81156014)(50986999)(8676002)(81166006)(54356999)(76176999)(14454004)(478600001)(53936002)(66066001)(966005)(55016002)(99286004)(3660700001)(3280700002)(236005)(19627405001)(6246003)(6306002)(9686003)(54896002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146455DAA6ACDE809CBC8019F35D0CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5f98cc-d741-4c56-4466-08d522ab3a6d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 11:08:35.6378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves 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, 03 Nov 2017 11:08:41 -0000 --_000_CY4PR09MB146455DAA6ACDE809CBC8019F35D0CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes. Quynh. ________________________________ From: William Whyte Sent: Friday, November 3, 2017 7:02 AM To: Dan Brown Cc: Dang, Quynh (Fed); Tony Arcieri; rsalz@akamai.com; cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves Is there any chance that NIST will permit eddsa? Cheers, William On Fri, Nov 3, 2017 at 6:34 AM, Dan Brown > wrote: Credit is most due to djb. From: Dang, Quynh (Fed) Sent: Friday, November 3, 2017 6:05 AM To: Tony Arcieri; rsalz@akamai.com Cc: cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves NIST appreciates the great work by the CFRG. Regards, Quynh. ________________________________ From: Cfrg > on behalf = of Tony Arcieri > Sent: Thursday, November 2, 2017 3:13:13 PM To: rsalz@akamai.com Cc: cfrg@irtf.org Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved curves Great news! _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurit= y.com --_000_CY4PR09MB146455DAA6ACDE809CBC8019F35D0CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes.


Quynh. 



From: William Whyte <wwh= yte@onboardsecurity.com>
Sent: Friday, November 3, 2017 7:02 AM
To: Dan Brown
Cc: Dang, Quynh (Fed); Tony Arcieri; rsalz@akamai.com; cfrg@irtf.org=
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved = curves
 
Is there any chance that NIST will permit eddsa? 

Cheers,

William

On Fri, Nov 3, 2017 at 6:34 AM, Dan Brown <danibrown= @blackberry.com> wrote:

From: Dang, Quynh (Fed)
Sent: Friday, November 3, 2017 6:05 AM
To: Tony Arcieri; rsalz@akamai.com
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their appr= oved curves

NIST appreciates the great work by the CFRG.


Regards,

Quynh. 

From: Cfrg <cfrg= -bounces@irtf.org> on behalf of Tony Arcieri <bascule@gmail.c= om>
Sent: Thursday, November 2, 2017 3:13:13 PM
To: rsalz@akam= ai.com
Cc: cfrg@irtf.org=
Subject: Re: [Cfrg] NIST to include 25519 and 448 in their approved = curves
 
Great news!

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




--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com
--_000_CY4PR09MB146455DAA6ACDE809CBC8019F35D0CY4PR09MB1464namp_-- From nobody Sat Nov 4 07:36:17 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03913F6BC for ; Sat, 4 Nov 2017 07:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxm8GoylBi_m for ; Sat, 4 Nov 2017 07:36:14 -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 3B99213FB12 for ; Sat, 4 Nov 2017 07:36:14 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id r64so6396527qkc.1 for ; Sat, 04 Nov 2017 07:36:14 -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=PKw2n9tViejyKf0bmK1YlG9MUIGjItUb8yBvladrrLQ=; b=LlD8zyOY1C7NLqBytyQQwuYPyWbzqlRh0K/L3gJPvEIzBigN3NflNtUHI/JhzGCLW9 mfdajzKOZw/20JCrZ7Ke2Z8R2psLKzKkc6h9PSZtPI91UMPXXgT/iYiD7l3+bIay5dn9 le4wQ/TfsAtP7K9hBPzl4ZDnHIHv0r3cyLABZ/7mliW566hO1u9F6sLTEs8534p1qFtt gKkuO4r3ruqSaXa7sO9eNx5U5YSwD63rBdZtyH+Gmfn2XX9D/VWCWgYhGWIHZHxo5bys RiGP8mKCjCvF825E40xapqwTm/KbEO39OcDOPgsBeBDN+kBAMxELYqUNzt7Sb6Zx+Jn+ Lz0w== 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=PKw2n9tViejyKf0bmK1YlG9MUIGjItUb8yBvladrrLQ=; b=PDAxwsRxpavdoigW6BxDMnFfnpxo7CXcZIrnFrVk3ttjv3pxoWE/4oOTfCL1nr74s1 1a1Q8OhSlX58Cat0JaNNYdzDhjYatbJe92v72FEq1YndhwVQ26l2K8Xpa8+Tff+bDvCd 07jrlIRzofPqlgRldwLqA023HokRXtf4UBhcI9vYPDSAvC+5Z/tkRp2I1yim3QeuS5mt uZHy1ejWUNvjOKzLgZPxathyyuesIt83uA/p+zHoS4jU04bzT9SvzaoKOru5r/L5JTAp zjpmD3SuC2SLlYdGxngp/52CIBpQWxmMgfaqyLeaLqg0841aIc1YUgD6nSXtTLuWMamp R8Sw== X-Gm-Message-State: AMCzsaWCKa7tBD09+sDDndzNNQxvhm0CFbvu38HFa1H24dvqCWrDGvZb 5phcX5GjC/2qEHzpp68M5pgKHV12IGNXS/0OIw5+FQ== X-Google-Smtp-Source: ABhQp+SgsyR1NiO0xjmRAkk/1E0SFwLGFY5As7c/3HewTtG7YjtiZRdTxwAo/TYLKzPQbgp+h3sz1kgEmzaoW68Lr6s= X-Received: by 10.55.184.71 with SMTP id i68mr13608393qkf.150.1509806173025; Sat, 04 Nov 2017 07:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.103 with HTTP; Sat, 4 Nov 2017 07:36:12 -0700 (PDT) From: Peter Alexander Date: Sat, 4 Nov 2017 10:36:12 -0400 Message-ID: To: Cfrg@irtf.org Content-Type: multipart/mixed; boundary="94eb2c076f669ff7d9055d2924ae" Archived-At: Subject: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessions. - Draft I-D Attached 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, 04 Nov 2017 14:36:16 -0000 --94eb2c076f669ff7d9055d2924ae Content-Type: multipart/alternative; boundary="94eb2c076f669ff7d6055d2924ac" --94eb2c076f669ff7d6055d2924ac Content-Type: text/plain; charset="UTF-8" Good morning everyone, I am attaching my first go at a proper I-D for submission. This is the same invention that I had mentioned previously, and is quite similar in scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08). Right now I am still working through the Doxygen documentation to translate the control messages into a cleaner I-D format. Kindly review this when you are able to do so, and share your comments. Peter Alexander --94eb2c076f669ff7d6055d2924ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good morning everyone,=C2=A0

I am attac= hing my first go at a proper I-D for submission. This is the same invention= that I had mentioned previously, and is quite similar in scope to what Sta= nislav is working on (draft-irtf-cfrg-re-keying-08).
Right now I am still working through the Doxygen documentation= to translate the control messages into a cleaner I-D format.
Kindly review this when you are able to do so, and share your c= omments.

Peter Alexander
--94eb2c076f669ff7d6055d2924ac-- --94eb2c076f669ff7d9055d2924ae Content-Type: text/plain; charset="US-ASCII"; name="draft-method-for-rekeying-network-sessions-cfrg-topic-00.txt" Content-Disposition: attachment; filename="draft-method-for-rekeying-network-sessions-cfrg-topic-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j9lffvvr0 DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQLiBBbGV4YW5kZXINCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBObyBBZmZpbGlhdGlvbg0KSW50ZW5kZWQgc3RhdHVz OiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDA0LCAyMDE3 DQpFeHBpcmVzOiBNYXkgOCwgMjAxOA0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBp cyBhbiBJbnRlcm5ldC1kcmFmdA0KICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LW5hbWUt d2ctdG9waWMtMDANCg0KQWJzdHJhY3QNCg0KICAgWyBJbnNlcnQgYWJzdHJhY3QgaGVyZSBdDQoN ClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0 ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzgg YW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50 cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAg RHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8u DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1h eGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDgsIDIwMTguDQoNCkNvcHly aWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDE3IElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmli ZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZp ZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQoNCg0KDQoNCkFsZXhhbmRlciAgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDgsIDIwMTggICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBJLUQgICAgICAgICAgICAgICAgICAgICBOb3Zl bWJlciAyMDE3DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBNYWludGFpbmluZyBzZWN1cml0 eSBvdmVyIGxvbmcgbGFzdGluZyBuZXR3b3JrIGNvbm5lY3Rpb25zIGJldHdlZW4NCiAgIGVuZHBv aW50cyBvZnRlbiByZXF1aXJlcyB0aGUgZW5jcnlwdGlvbiBrZXlzIHRvIGJlIHJlcGxhY2VkDQog ICBwZXJpb2RpY2FsbHkgaW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGxpbmsgcmVtYWlucyBz ZWN1cmUuDQogICBUcmFkaXRpb25hbCBtZXRob2RzIGZvciByZXBsYWNpbmcga2V5cyByZXF1aXJl ZCB0aGUgc2Vzc2lvbiB0byBiZQ0KICAgdG9ybiBkb3duLCBhbmQgcmVidWlsdCBpbiBvcmRlciBm b3IgYSBuZXcga2V5IGV4Y2hhbmdlIHRvIG9jY3VyLiAgSW4NCiAgIG1hbnkgY2FzZXMgdGhpcyBs b3NzIG9mIGNvbm5lY3Rpdml0eSBtZWFudCBsb3NzIG9mIHByb2R1Y3Rpdml0eSwgYXMNCiAgIHdl bGwgYXMgbG9zdCByZXZlbnVlLiAgQW5vdGhlciBpc3N1ZSBpcyB0aGF0IGFueW9uZSBvYnNlcnZp bmcgdGhlDQogICBuZXR3b3JrIGlzIGFibGUgdG8gc2VlIHRoYXQgdGhlIGNvbm5lY3Rpb24gaGFz IGJlZW4gcmVzdGFydGVkLCBhbmQNCiAgIHRoZXJlZm9yZSBrbm93cyB3aGF0IGEga2V5IHJlbmVn b3RpYXRpb24gaGFzIHRha2VuIHBsYWNlLg0KDQogICBUaGUgUHJvdGVjdGVkIFBvaW50IHRvIFBv aW50IChQMykgc29sdXRpb24gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQNCiAgIGFpbXMgdG8g cmVzb2x2ZSB0aG9zZSBpc3N1ZXMuICBJdCBkb2VzIHNvIGJ5IGJ1aWxkaW5nIGEgdHVubmVsDQog ICBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgaW4gd2hpY2gga2V5cyBvciBrZXkgaW5mb3JtYXRpb24g Y2FuIGJlIHNhZmVseQ0KICAgcGFzc2VkIGFjcm9zcy4gIEEgc2Vjb25kIHR1bm5lbCBpcyBidWls dCBvbiB0byBlbmNvbXBhc3MgdGhlIGZpcnN0LA0KICAgYW5kIGlzIHByaW1hcmlseSB1c2VkIGZv ciBuZXR3b3JrIHRyYW5zcG9ydC4gIEhhdmluZyB0d28gbGF5ZXJzIGluDQogICB0aGlzIG1hbm5l ciBhbGxvd3MgZm9yIHJlLW5lZ290aWF0aW9ucyB0byBvY2N1ciB3aXRoaW4gdGhlIGRvdWJseS0N CiAgIHNlY3VyZSB0dW5uZWwsIHdoaWxlIHN0aWxsIGFsbG93aW5nIG5vcm1hbCB0cmFmZmljIHRv IGZsb3cNCiAgIHVuaGluZGVyZWQuDQoNCjEuMS4gIFRlcm1pbm9sb2d5DQoNCiAgIEluIHRoaXMg ZG9jdW1lbnQsIHRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLA0K ICAgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1F TkRFRCIsICJNQVkiLA0KICAgYW5kICJPUFRJT05BTCIgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBCQ1AgMTQsIFJGQyAyMTE5DQogICBbUkZDMjExOV0uDQoNCjIuICBEaWFn cmFtIFNob3dpbmcgVHVubmVsIExheWVycw0KDQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgICAgIHwgICAgICBOZXR3b3JrICAgICAgIHwNCiAgICAgICB8ICAgICAgVHJhZmZpYyAg ICAgICB8DQogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgIDwtLS0rICAgIENvbnRy b2wgRGF0YSAgICArLS0tPg0KICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICB8 ICAgICAgTmV0d29yayAgICAgICB8DQogICAgICAgfCAgICAgIFRyYWZmaWMgICAgICAgfA0KICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoNCg0KDQoNCkFsZXhhbmRlciAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDgsIDIwMTggICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICBJLUQgICAgICAgICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDE3DQoNCg0KMy4gIEluaXRpYWxpemF0aW9uDQoNCiAgIFRoZSBQMyBz b2x1dGlvbiBpbml0aWFsaXphdGlvbiBjb25mb3JtcyB0byB0aGUgSVBzZWMgc3RhbmRhcmQgZGVm aW5lZA0KICAgaW4gUkZDIDQzMDEgYXMgd2VsbCBhcyBhbGwgb2YgaXRzIHN1cHBvcnRpbmcgc3Rh bmRhcmRzLiAgVGhlIHByb3RvY29sDQogICBpcyBtb2RpZmllZCB0byBlbmFibGUgdGhlIGVuY3J5 cHRpb24ga2V5cyB0byBiZSByZXBsYWNlZCBkeW5hbWljYWxseS4NCiAgIFdoZW4gdGhlIGluaXRp YWwgaGFuZHNoYWtlcyBoYXZlIGNvbXBsZXRlZCwgYW5kIHRoZSBEYXRhIENoYW5uZWwgaGFzDQog ICBiZWVuIGVzdGFibGlzaGVkLCB0aGUgUDMgc3lzdGVtIHRoZW4gaW5pdGlhbGl6ZXMgdGhlIENv bnRyb2wgQ2hhbm5lbC4NCiAgIFRoZSBpbml0aWFsaXphdGlvbiBtZXNzYWdlcyBhcmUgc3BlaWNp YyB0byBQMywgYW5kIGFyZSBkZXNpZ25lZCB0bw0KICAgbG9vayBsaWtlIG5vcm1hbCBkYXRhIHdo aWNoIGhhcyBiZWVuIGVuY3J5cHRlZCB3aXRoIGEgZGlmZmVyZW50IGtleQ0KICAgdGhhbiB0aGUg b25lIHVzZWQgYnkgdGhlIERhdGEgQ2hhbm5lbC4gIEluIG9yZGVyIHRvIGZ1cnRoZXIgcHJvdGVj dA0KICAgdGhlIGtleXMgdXNlZCBkdXJpbmcgaW5pdGlhbGl6YXRpb24sIHRoZSBzZXNzaW9uIHJl LWtleXMgaXRzZWxmIG9uY2UNCiAgIHRoZSBlbmRwb2ludHMgaGF2ZSBhY2tub3dsZWRnZWQgdGhl IGNvbm5lY3Rpb24uDQoNCjQuICBTZXNzaW9uIFByb2Nlc3NpbmcNCg0KICAgVGhlIGZ1bGwgSVAg cGFja2V0cyByZWNlaXZlZCBmcm9tIHRoZSBsb2NhbCBuZXR3b3JrIGFyZSBlbmNyeXB0ZWQgYW5k DQogICB1c2VkIGFzIHRoZSBwYXlsb2FkIGRhdGEgb2YgdGhlIGVuY3J5cHRlZCBwYWNrZXQuICBU aGVzZSBwYWNrZXRzIGFyZQ0KICAgc3RydWN0dXJlZCB1c2luZyB0aGUgRW5jYXBzdWxhdGluZyBT ZWN1cml0eSBIZWFkZXIgKEVTSCksIGFuZA0KICAgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXls b2FkIChFU1ApLCBhcyBkZWZpbmVkIGluIFJGQyA0MzAzLiAgVGhlIFAzDQogICBzb2x1dGlvbiBy ZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgYSAzMi1iaXQgZmllbGQgYXQgdGhlIGVuZCBvZiB0aGUN CiAgIEVTSCBhbmQgaW1tZWRpYXRlbHkgYmVmb3JlIHRoZSBFU1AuICBUaGUgZm9ybWF0IG9mIGVu Y3J5cHRlZCBwYWNrZXRzDQogICBpczoNCg0KICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSst LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICB8IEVTSCBzaXpl IHwgNCBvY3RldHMgfCBWYXJpYWJsZSBsZW5ndGggfA0KICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICB8IEVT SCAgICAgIHwgUDMgSUQgICAgfCBFU1AgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBXaGVyZSB0aGUg ZmllbGRzIGFyZToNCg0KICAgbyAgRVNIOiBUaGUgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBIZWFk ZXIgb2YgdGhlIElQc2VjIHByb3RvY29sLg0KDQogICBvICBQMyBJRDogVGhlIElkZW50aWZpY2F0 aW9uIG51bWJlciBvZiB0aGUgcGFja2V0Lg0KDQogICBvICBFU1A6IFRoZSBFbmNhcHN1bGF0aW5n IFNlY3VyaXR5IFBheWxvYWQgb2YgdGhlIElQc2VjIHByb3RvY29sLg0KDQogICBXaGVuIENvbnRy b2wgQ2hhbm5lbCBkYXRhIGlzIHRvIGJlIHNlbnQgdG8gYW5vdGhlciBQMyBTeXN0ZW0sDQogICBw cmVkZWZpbmVkIFRDUCBhbmQgSVAgaGVhZGVycyBhcmUgcHJlcGVuZGVkLiAgT25seSB0aGUgYWRk cmVzcyBmaWVsZHMNCiAgIGFyZSBwcm9jZXNzZWQgYnkgdGhlIHJlY2VpdmluZyBQMyBTeXN0ZW0s IHNvIHRoZSBoZWFkZXJzIG1heSBiZQ0KICAgc3RhdGljYWxseSBkZWZpbmVkLiAgVGhlIGVudGly ZSBwYWNrZXQgaXMgZW5jcnlwdGVkIHVzaW5nIHRoZSBjb250cm9sDQogICBlbmNyeXB0aW9uIGtl eSwgYW5kIGl0IGlzIHRoZW4gdHJlYXRlZCBhcyBpZiBpdCB3ZXJlIGEgc3RhbmRhcmQgYQ0KICAg ZGF0YSBwYWNrZXQuICBJZiwgYWZ0ZXIgZGVjcnlwdGluZyBhIHBhY2tldCwgdGhlIGRlc3RpbmF0 aW9uIGlzIHNlZW4NCiAgIHRvIGJlIHRoZSBQMyBTeXN0ZW0gaXRzZWxmLCB0aGUgcGFja2V0IGlz IGRlY3J5cHRlZCB1c2luZyB0aGUgY29udHJvbA0KICAgZW5jcnlwdGlvbiBrZXkuICBUaGVuIHRo ZSBJUCBhbmQgVENQIGhlYWRlcnMgYXJlIHJlbW92ZWQgYW5kIHRoZSBkYXRhDQogICBpcyBmb3J3 YXJkZWQgdG8gdGhlIENvbnRyb2wgQ2hhbm5lbCBhcHBsaWNhdGlvbi4NCg0KDQoNCg0KDQpBbGV4 YW5kZXIgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE4ICAgICAgICAgICAgICAg ICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgSS1EICAg ICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxNw0KDQoNCjUuICBDb250cm9sIE1lc3NhZ2Ug U3BlY2lmaWNhdGlvbg0KDQogICBBdXRob3JzIE5vdGU6IEkgc3RpbGwgbmVlZCB0byBmaW5kIHRo ZSBleGFjdCBub3RlcyByZWdhcmRpbmcgY29udHJvbA0KICAgY2hhbm5lbCBtZXNzYWdlcy4gIFRo aXMgaXMgYSB0ZW1wb3JhcnkgcGxhY2Vob2xkZXIuDQoNCjYuICBFbmNyeXB0aW9uIFJlLWtleWlu Zw0KDQogICBUaGUgc3lzdGVtIGhhcyBiZWVuIGRlc2lnbmVkIHRvIGFsbG93IHRoZSByZS1rZXlp bmcgcHJvY2VzcyB0byBiZQ0KICAgY29uZmlndXJhYmxlLiAgVHJpZ2dlcnMgZm9yIHJlLWtleWlu ZyBtYXkgaW5jbHVkZTsgcGFja2V0IGNvdW50LA0KICAgdGltZSwgb3IgYSBjb21iaW5hdGlvbiBv ZiBib3RoLiAgT3RoZXIgdHJpZ2dlcnMgbWF5IGFsc28gYmUgZGVmaW5lZA0KICAgb24gYW4gYXMt bmVlZGVkIGJhc2lzLg0KDQogICBXaGVuIGEgcmUta2V5IGlzIHRyaWdnZXJlZCB0aGUgcHJpbWFy eSBQMyBTeXN0ZW0gbm90aWZpZXMgdGhlDQogICBzZWNvbmRhcnksIHN1cHBsaWVzIHRoZSBuZXcg a2V5cywgYW5kIGluZGljYXRlcyB3aGVuIGl0IHdpbGwgYmVnaW4gdG8NCiAgIHVzZSB0aGUgbmV3 IHNldCBvZiBrZXlzLiAgVGhlIHByaW1hcnkgUDMgU3lzdGVtIGdlbmVyYXRlcyBuZXcga2V5cw0K ICAgZm9yIGJvdGggdGhlIG1haW4gc2Vzc2lvbiBhbmQgdGhlIENvbnRyb2wgQ2hhbm5lbC4gIFRo ZSBrZXlzIGFyZQ0KICAgcmVwbGFjZWQgdXNpbmcgdGhlIFAzIGNvbnRyb2wgbWVzc2FnZXMgYWNj b3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcNCiAgIHByb2Nlc3MuICBUaGUgcHJpbWFyeSBQMyBTeXN0 ZW0gc2VuZHMgYSBjb250cm9sIG1lc3NhZ2Ugd2l0aCB0aGUgZGF0YQ0KICAgYW5kIGNvbnRyb2wg a2V5IHZhbHVlcy4gIFRoaXMgbGV0cyB0aGUgc2Vjb25kYXJ5IGtub3cgdGhhdCBhIHJlLWtleQ0K ICAgZXZlbnQgaXMgYWJvdXQgdG8gdGFrZSBwbGFjZS4gIFdoZW4gdGhlIHNlY29uZGFyeSByZWNl aXZlcyB0aGUNCiAgIG1lc3NhZ2UsIGl0IHVwZGF0ZXMgdGhlIGtleXMgaXQgaXMgdXNpbmcgYW5k IHJldHVybnMgYSBzdGF0dXMNCiAgIG1lc3NhZ2UuICBJZiB0aGUgc3RhdHVzIGlzIGdvb2QsIHRo ZSBwcmltYXJ5IGFja25vd2xlZGdlcywgYW5kIHNlbmRzDQogICBhIG1lc3NhZ2UgdG8gaW5kaWNh dGUgdGhlIGZpcnN0IHBhY2tldCBpdCB3aWxsIGVuY3J5cHQgdXNpbmcgdGhlIG5ldw0KICAga2V5 cy4gIFRoZSBzZWNvbmRhcnkgdGhlbiByZXR1cm5zIGEgc3VjY2VzcyBtZXNzYWdlIGluZGljYXRp bmcgdGhlDQogICBmaXJzdCBwYWNrZXQgdXNpbmcgdGhlIG5ldyBrZXlzIGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBkZWNyeXB0ZWQuICBJZg0KICAgdGhlIHN0YXR1cyBpcyBub3Qgc3VjY2VzcywgdGhl IHByaW1hcnkgYXR0ZW1wdHMgYWdhaW4gZm9yIHVwIHRvIGZvdXINCiAgIHRpbWVzLiAgSWYgdGhp cyBkb2VzIG5vdCByZXN1bHQgaW4gc3VjY2Vzcywgc2Vzc2lvbiByZWNvdmVyeSBpcw0KICAgcGVy Zm9ybWVkLg0KDQo3LiAgU2Vzc2lvbiBSZWNvdmVyeQ0KDQogICBUaGUgc2Vzc2lvbiByZWNvdmVy eSBwcm9jZXNzIGJlZ2lucyBieSBkaXNjYXJkaW5nIGFsbCBrZXlzIHVzZWQNCiAgIGR1cmluZyB0 aGUgcHJldmlvdXMgc2Vzc2lvbiwgYW5kIGlzIGZvbGxvd2VkIGJ5IGEgY29tcGxldGUgc2Vzc2lv bg0KICAgdGVhci1kb3duIHNvIHRoYXQgYSBuZXcgc2Vzc2lvbiBtYXkgYmUgZXN0YWJsaXNoZWQu ICBJZiBhIG5ldyBzZXNzaW9uDQogICBjYW5ub3QgYmUgZXN0YWJsaXNoZWQgaXQgaXMgdGhlbiBs ZWZ0IHRvIHRoZSB1c2VyIHRvIGRldGVybWluZQ0KICAgd2hldGhlciBvciBub3QgdGhlIHN5c3Rl bSBpcyBkb3duIG9yIGNvbXByb21pc2VkLg0KDQo4LiAgU3RhbmRhcmRzIENvbXBsaWFuY2UNCg0K ICAgVGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBQMyBTeXN0ZW0gY29uZm9ybXMgdG8gdGhlIGZv bGxvd2luZw0KICAgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURikgc3RhbmRh cmRzOg0KDQo4LjEuICBJUCBTZWN1cml0eQ0KDQogICAxLiAgUkZDIDQzMDE6IFNlY3VyaXR5IEFy Y2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0IFByb3RvY29sDQoNCiAgIDIuICBSRkMgMzcyMzog U2VjdXJpbmcgQmxvY2sgU3RvcmFnZSBQcm90b2NvbHMgb3ZlciBJUA0KDQoNCg0KDQpBbGV4YW5k ZXIgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA4LCAyMDE4ICAgICAgICAgICAgICAgICAg W1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgSS1EICAgICAg ICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxNw0KDQoNCjguMS4xLiAgRVNQIGFuZCBBSCBIZWFk ZXJzDQoNCiAgIDEuICBSRkMgNDMwMjogSVAgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkNCg0K ICAgMi4gIFJGQyA0MzAzOiBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBheWxvYWQgKEVTUCkNCg0K ICAgMy4gIFJGQyA0ODM1OiBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBJbXBsZW1lbnRhdGlvbiBS ZXF1aXJlbWVudHMgRm9yDQogICAgICAgRVNQIEFuZCBBSA0KDQo4LjEuMi4gIEtleSBFeGNoYW5n ZQ0KDQogICAxLiAgUkZDIDM1NDc6IEdyb3VwIERvbWFpbiBvZiBJbnRlcnByZXRhdGlvbg0KDQog ICAyLiAgUkZDIDQxMDk6IEFsZ29yaXRobXMgZm9yIElLRXYxDQoNCiAgIDMuICBSRkMgNDMwNjog SW50ZXJuZXQgS2V5IEV4Y2hhbmdlIChJS0V2MikgUHJvdG9jb2wNCg0KICAgNC4gIFJGQyA0MzA3 OiBDcnlwdG9ncmFwaGljIEFsZ29yaXRobXMgZm9yIFVzZSBpbiB0aGUgSW50ZXJuZXQgS2V5DQog ICAgICAgRXhjaGFuZ2UgVmVyc2lvbjIgKElLRXYyKQ0KDQogICA1LiAgUkZDIDQzMDg6IENyeXB0 b2dyYXBoaWMgU3VpdGVzIGZvciBJUHNlYw0KDQogICA2LiAgUkZDIDQ3MTg6IElLRXYyIENsYXJp ZmljYXRpb25zIGFuZCBJbXBsZW1lbnRhdGlvbiBHdWlkZWxpbmVzDQoNCiAgIDcuICBSRkMgNDk0 NTogSVBzZWMgUEtJIFByb2ZpbGUgb2YgSUtFdjEvSVNBS01QLCBJS0V2MiwgYW5kIFBLSVgNCg0K OC4xLjMuICBDcnlwdG9ncmFwaGljIEFsZ29yaXRobXMNCg0KICAgMS4gIFJGQyAyNDEwOiBOVUxM IEVuY3J5cHRpb24gQWxnb3JpdGhtIGFuZCBJdHMgVXNlIFdpdGggSVBzZWMNCg0KICAgMi4gIFJG QyAzMTczOiBJUCBQYXlsb2FkIENvbXByZXNzaW9uIFByb3RvY29sIChJUENvbXApDQoNCiAgIDMu ICBSRkMgMzUyNjogTW9yZSBNb2R1bGFyIEV4cG9uZW50aWFsIChNT0RQKSBEaWZmaWUtSGVsbG1h biBncm91cHMNCiAgICAgICBmb3IgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIChJS0UpDQoNCiAgIDQu ICBSRkMgMzY4NjogVXNpbmcgQUVTIENvdW50ZXIgTW9kZSBXaXRoIElQc2VjIEVTUA0KDQogICA1 LiAgUkZDIDQzMDk6IFVzaW5nIEFFUyBDQ00gTW9kZSBXaXRoIElQc2VjIEVTUA0KDQogICA2LiAg UkZDIDQ0MzQ6IEFFUy1YQ0JDLVBSRi0xMjggYWxnb3JpdGhtIGZvciBJS0UNCg0KICAgNy4gIFJG QyA0NjE1OiBBRVMtQ01BQy1QUkYtMTI4IEFsZ29yaXRobSBmb3IgSUtFDQoNCiAgIDguICBSRkMg NDc1NDogSUtFIGFuZCBJS0V2MiBBdXRoZW50aWNhdGlvbiBVc2luZyBFQ0RTQQ0KDQogICA5LiAg UkZDIDUyODI6IFVzaW5nIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiBBbGdvcml0aG1zIHdpdGgg dGhlDQogICAgICAgRW5jcnlwdGVkIFBheWxvYWQgb2YgSUtFdjINCg0KDQoNCg0KQWxleGFuZGVy ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOCwgMjAxOCAgICAgICAgICAgICAgICAgIFtQ YWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgIEktRCAgICAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTcNCg0KDQo5LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMN Cg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3Mg dG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KQXV0aG9yJ3MgQWRkcmVzcw0KDQogICBQZXRlciBBbGV4 YW5kZXINCiAgIE5vIEFmZmlsaWF0aW9uDQoNCiAgIEVtYWlsOiBkcmJhbmpvZm94QHByb3Rvbm1h aWwuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFsZXhhbmRlciAgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDgsIDIwMTggICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0K --94eb2c076f669ff7d9055d2924ae-- From nobody Sat Nov 4 08:29:13 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 09F0713FB36 for ; Sat, 4 Nov 2017 08:29:12 -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 FcULr-oERu4Y for ; Sat, 4 Nov 2017 08:29:10 -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 13A4813F6BC for ; Sat, 4 Nov 2017 08:29:10 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id x195so851540qkb.12 for ; Sat, 04 Nov 2017 08:29:10 -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=c+JNCUUHyRz6cJ60bwbjUjFZUBkHgeOgEgFHGX/N2E8=; b=Nlt0Co+ayBjqThrk4NzVPRPhAGQlRPr6Htv7nDzHFU8hrJzRoWT17VEuP530J4lKaq FJuKtjZDq7RGg4Q2f7md5p3APgq4JJuB2UPAma/xfykxCSJPz9uVVQ2+8pQleUr45AXt 16wOpfvqNfeAlPq1bn0vB+zWcEpat5zbhVIPYgoVZa9AQKXldxXq75O5TnbK+niQUXVv Uyp4xxBJwevY7kx5Iy02c6Ja3z0oRekHFeDKZY0JWu166fy2dUJE6pMZpSsknenOHJJ/ iUBw4LJeQdOk3AmxBuZwATAn8drSNrEm18oYa3a+4Hl/lg/5TV7BMdPtjv7GUquYt5K5 /CZw== 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=c+JNCUUHyRz6cJ60bwbjUjFZUBkHgeOgEgFHGX/N2E8=; b=ANwvk1cpXNTJ1LTpD1w8OBugb/CkpCgkizHI952sZmQGShvzInmGcGhQ+MGnK3etx9 GC+VB1UDNIVBvsWhrXWRn+XwYV3nA2Cy/VqejtGe7eUuGvybg91Hq9dMCMICgxDfHf0Z wW6dA4VMxdJV98xNjJdC5pWgTAaEPY2WVtMYu0WvAvRDdnZJMJQdIBHjX4hPNQXc+ZKP HYH1bDtibi5dKwToZ9WDpH+Ki/Ll2wLHBPz5PeUFtaNedvV0uxsjUiDe1tUe2O8IR5e+ u41G9Ysjid90hswEoJdIjECRrTCQ4RP2Qk/8FIt13CHc1QatBkibu+fnGId4dQE0G4F7 l1Xg== X-Gm-Message-State: AMCzsaWeyDWfPBuNFL2rA1UPc2VWL5uxrt52mLa6194kw9xubP6Jb046 kajTG47xRAO6gQjQMSng5bAkDm4rjD7DWUPSFig= X-Google-Smtp-Source: ABhQp+SoU+6foo996MPDnNmCM7SSmbu4290rSSoFchRgzdF19ygKKBcV9JkvOVv5oYr9q/pqzV4ofTmpmDgHYJen4Zg= X-Received: by 10.55.108.135 with SMTP id h129mr14866837qkc.111.1509809349213; Sat, 04 Nov 2017 08:29:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Sat, 4 Nov 2017 08:29:08 -0700 (PDT) In-Reply-To: References: From: "Stanislav V. Smyshlyaev" Date: Sat, 4 Nov 2017 18:29:08 +0300 Message-ID: To: Peter Alexander Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a1148809af04692055d29e120" Archived-At: Subject: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessions. - Draft I-D Attached 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, 04 Nov 2017 15:29:12 -0000 --001a1148809af04692055d29e120 Content-Type: text/plain; charset="UTF-8" Dear colleagues, The overall scope is close, but draft-irtf-cfrg-re-keying is about "why and how to re-key", and the proposed draft is about "when to re-key and how to control the process". As a possible way, we could discuss in CFRG, which general principles of Peter's document (overall principles of how to control the re-keying process) would be reasonble to add to draft-irtf-cfrg-re-keying. And questions related to the particular protocols (e.g., IPsec, as in the provided Peter Alexander's draft) seem to be more convenient to be discussed within corresponding working groups - such as ipsecme WG. Best regards, Stanislav 2017-11-04 17:36 GMT+03:00 Peter Alexander : > Good morning everyone, > > I am attaching my first go at a proper I-D for submission. This is the > same invention that I had mentioned previously, and is quite similar in > scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08). > > Right now I am still working through the Doxygen documentation to > translate the control messages into a cleaner I-D format. > > Kindly review this when you are able to do so, and share your comments. > > Peter Alexander > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a1148809af04692055d29e120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

The overall scope is c= lose, but=C2=A0draft-irtf-cfrg-re-keying=C2=A0i= s about=C2=A0"why and how to re-key", and the proposed dra= ft is about "when to re-key and how to control the process".

As a possible way, we could discuss in CFRG, which gen= eral principles of Peter's document (overall principles of how to contr= ol the re-keying process) would be reasonble to add to=C2=A0draft-irt= f-cfrg-re-keying.=C2=A0

And questions relat= ed to the particular protocols (e.g., IPsec, as in the provided Peter Alexa= nder's draft) seem to be more convenient to be discussed within corresp= onding working groups - such as ipsecme WG.

Best regards,

Stanislav



2017-11-04 17:36 GMT+03:00 Peter Alexander <= span dir=3D"ltr"><pipnflinx@gmail.com>:
Good morning everyone,=C2=A0

I am attaching my first go at a proper I-D for submission. This is t= he same invention that I had mentioned previously, and is quite similar in = scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08).

Right now I am still working through the= Doxygen documentation to translate the control messages into a cleaner I-D= format.

Kindly review this when you are able to d= o so, and share your comments.

Peter Alexander

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


--001a1148809af04692055d29e120-- From nobody Mon Nov 6 02:53: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 29A3D13FB0C for ; Mon, 6 Nov 2017 02:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 wpphftcD45FE for ; Mon, 6 Nov 2017 02:53:33 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0040.outbound.protection.outlook.com [104.47.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6180C13FAE1 for ; Mon, 6 Nov 2017 02:53:33 -0800 (PST) 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=BtsQC5HJQordHuuI1Ae+8VVaJwD77BLVSX9oE32wDzo=; b=qRDyXSMTk3nO+uYJqjxca7dF4BYEVzGR8SVymwzwX0csGEQpcEnDPRWT/iTleyUDYK/LlP/nWMSxGdQSJL8yoGWPOS860P6PtEWgnFavYUUp3wnll50/v40HNk+Ygp+bPhJOUI9KQm2K0sTrkKr6eXiSP1+E+pREB9PvyUBt4fY= 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.197.13; Mon, 6 Nov 2017 10:53:30 +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.0197.017; Mon, 6 Nov 2017 10:53:29 +0000 From: "Paterson, Kenny" To: "Stanislav V. Smyshlyaev" , Peter Alexander CC: "Cfrg@irtf.org" Thread-Topic: [Cfrg] Dynamic Key Changes on Encrypted Sessions. - Draft I-D Attached Thread-Index: AQHTVXpQaXYE7nr0W0yPtWIPS0q5BqMEWFsAgALYN4A= Date: Mon, 6 Nov 2017 10:53:29 +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.215.134] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1905; 6:shva1SStjtVTkUaQjIcnnjFGUYK7RIDbUVvb2u9cjb10nIM74rSF9FdoSyXC2JQVNtClQsEbD3NSa2N0SCd/P+TRdCtVbG9LQT1RAvM+bPj2i3RKrgTttkASHZtxwAMyKLaY58UyqDNuMMZtF4CKd0IuiIJhVFKyhUqUCpBynjNgREtRnRtyaRb4b9DIn3fH+/ff09X3KskTMpGy2dHn9ALAN5J4f6mZEbbbSxnUMCnv04BIMRlaIqLftiLl7dyx+KTynhU78qPH4zDGA4DQLh/q0TLYfBexcNPAsSpmRFSvff2ilvr3vfDCbWipxPJl2gud0JN2l26XRKDUfSaN6TTN2ajAZ2Ce/cGikfN3gS4=; 5:vpOzj/pQLDBbHREjOWXnPkrkbM8uVuVj6Fb8zmTQqOH2KHajdWEvJSVdCOVDcFdFWkbxBQV8MJVd6eLq14W2X6hu8j4L9nCuZaQ+HKowEcT4R4dTWPfx44vyhCJcNX1x+LhF85IEl7sUerS6PMptHFkU1UQGu/d4nCOeJeOQic4=; 24:8xnGd2z4UtSJc6ilUejX5se6/dwCxBckPd7mZa/Coln1oPCG2QJa+KcCUo7+9gdp12sb5tEamraVHIvMsVtz80+ebN3lw0Z5WF9ygM4ApZc=; 7:IYuM4s9P1N6qkUOSLq70/neocxWTWqAUii3CRDAoZXrLqvcEDTTNKT2JGM2NK+gzKgT9ZXD1/Ce2vJwbqmwRYbZ3+rusA/dl8+tj7j6y324B9Bl82vSAF3UJzNaLvx1UEYG1oQVkEG+JumzsQX7XXie4j+Xg0kTY0ynLhd0wPr1uOkhYP0Mfvdop0tRI/ynpnOHymk3K4ivapbhWJco7cGJx19fS4uW7DBecUkNcUOJVZhmEirkaIIY6/4uJWQRA x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(377424004)(189002)(199003)(24454002)(3660700001)(5890100001)(2900100001)(58126008)(316002)(786003)(76176999)(54356999)(478600001)(110136005)(42882006)(2950100002)(6116002)(3846002)(102836003)(413944005)(36756003)(5660300001)(53546010)(5250100002)(101416001)(72206003)(50986999)(97736004)(53936002)(105586002)(2906002)(66066001)(6246003)(8936002)(81156014)(8676002)(305945005)(39060400002)(83506002)(6506006)(3280700002)(7736002)(99286004)(4326008)(6436002)(6306002)(81166006)(106356001)(74482002)(86362001)(14454004)(189998001)(68736007)(6512007)(25786009)(6486002)(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: 48373bf9-3a99-4dd1-330b-08d525049dc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR0301MB1905; x-ms-traffictypediagnostic: AM4PR0301MB1905: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231021)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(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: 048396AFA0 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: <82CE872088198D4A8DCDD0564BA61946@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 48373bf9-3a99-4dd1-330b-08d525049dc1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 10:53:29.9103 (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. - Draft I-D Attached 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, 06 Nov 2017 10:53:36 -0000 RGVhciBTdGFuaXNsYXYsDQoNClRoaXMgc291bmRzIGxpa2UgYSByZWFzb25hYmxlIHdheSBvZiBw cm9jZWVkaW5nLg0KDQpQbGVhc2Ugd291bGQgeW91IGluaXRpYXRlIGEgZGlzY3Vzc2lvbiBoZXJl IG9uIHRoZSBsaXN0IG9mIHRoZSByZWxldmFudA0KcHJpbmNpcGxlcyBmcm9tIFBldGVyJ3MgZG9j dW1lbnQ/DQoNClJlZ2FyZHMsDQoNCktlbm55IA0KDQpPbiAwNC8xMS8yMDE3IDE1OjI5LCAiQ2Zy ZyBvbiBiZWhhbGYgb2YgU3RhbmlzbGF2IFYuIFNteXNobHlhZXYiDQo8Y2ZyZy1ib3VuY2VzQGly dGYub3JnIG9uIGJlaGFsZiBvZiBzbXlzaHN2QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5EZWFyIGNv bGxlYWd1ZXMsDQo+DQo+DQo+VGhlIG92ZXJhbGwgc2NvcGUgaXMgY2xvc2UsIGJ1dCBkcmFmdC1p cnRmLWNmcmctcmUta2V5aW5nIGlzIGFib3V0ICJ3aHkNCj5hbmQNCj4gaG93IHRvIHJlLWtleSIs IGFuZCB0aGUgcHJvcG9zZWQgZHJhZnQgaXMgYWJvdXQgIndoZW4gdG8gcmUta2V5IGFuZCBob3cN Cj50byBjb250cm9sIHRoZSBwcm9jZXNzIi4NCj4NCj4NCj5BcyBhIHBvc3NpYmxlIHdheSwgd2Ug Y291bGQgZGlzY3VzcyBpbiBDRlJHLCB3aGljaCBnZW5lcmFsIHByaW5jaXBsZXMgb2YNCj5QZXRl cidzIGRvY3VtZW50IChvdmVyYWxsIHByaW5jaXBsZXMgb2YgaG93IHRvIGNvbnRyb2wgdGhlIHJl LWtleWluZw0KPnByb2Nlc3MpIHdvdWxkIGJlIHJlYXNvbmJsZSB0byBhZGQgdG8gZHJhZnQtaXJ0 Zi1jZnJnLXJlLWtleWluZy4NCj4NCj4NCj5BbmQgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gdGhlIHBh cnRpY3VsYXIgcHJvdG9jb2xzIChlLmcuLCBJUHNlYywgYXMgaW4gdGhlDQo+cHJvdmlkZWQgUGV0 ZXIgQWxleGFuZGVyJ3MgZHJhZnQpIHNlZW0gdG8gYmUgbW9yZSBjb252ZW5pZW50IHRvIGJlDQo+ ZGlzY3Vzc2VkIHdpdGhpbiBjb3JyZXNwb25kaW5nIHdvcmtpbmcgZ3JvdXBzIC0gc3VjaCBhcyBp cHNlY21lIFdHLg0KPg0KPkJlc3QgcmVnYXJkcywNCj5TdGFuaXNsYXYNCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCj4yMDE3LTExLTA0IDE3OjM2IEdNVCswMzowMCBQZXRlciBBbGV4YW5kZXINCj48cGlw bmZsaW54QGdtYWlsLmNvbT46DQo+DQo+R29vZCBtb3JuaW5nIGV2ZXJ5b25lLA0KPg0KPg0KPkkg YW0gYXR0YWNoaW5nIG15IGZpcnN0IGdvIGF0IGEgcHJvcGVyIEktRCBmb3Igc3VibWlzc2lvbi4g VGhpcyBpcyB0aGUNCj5zYW1lIGludmVudGlvbiB0aGF0IEkgaGFkIG1lbnRpb25lZCBwcmV2aW91 c2x5LCBhbmQgaXMgcXVpdGUgc2ltaWxhciBpbg0KPnNjb3BlIHRvIHdoYXQgU3RhbmlzbGF2IGlz IHdvcmtpbmcgb24gKGRyYWZ0LWlydGYtY2ZyZy1yZS1rZXlpbmctMDgpLg0KPg0KPg0KPlJpZ2h0 IG5vdyBJIGFtIHN0aWxsIHdvcmtpbmcgdGhyb3VnaCB0aGUgRG94eWdlbiBkb2N1bWVudGF0aW9u IHRvDQo+dHJhbnNsYXRlIHRoZSBjb250cm9sIG1lc3NhZ2VzIGludG8gYSBjbGVhbmVyIEktRCBm b3JtYXQuDQo+DQo+DQo+S2luZGx5IHJldmlldyB0aGlzIHdoZW4geW91IGFyZSBhYmxlIHRvIGRv IHNvLCBhbmQgc2hhcmUgeW91ciBjb21tZW50cy4NCj4NCj4NCj5QZXRlciBBbGV4YW5kZXINCj4N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNm cmcgbWFpbGluZyBsaXN0DQo+Q2ZyZ0BpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2ZyZw0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KDQo= From nobody Mon Nov 6 03:17:40 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 50DE513FB31 for ; Mon, 6 Nov 2017 03:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 jzf1T8O3StqZ for ; Mon, 6 Nov 2017 03:17:37 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598FF13FB56 for ; Mon, 6 Nov 2017 03:17:37 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id a2so10035859lfh.11 for ; Mon, 06 Nov 2017 03:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=llUBdbDW14HW7XL9/PW5t61nf/sCHlw8KDYtRU/yCJU=; b=clH5v1N00lTNOn+ivzKZUzr5FUv7alBDe7blVl4Ly+xhOP9rdSx4tp8yPIpRlH4tiy MlfMxzPQKKjk9EVYE4LhIfK1iWS8jlA+aEsixL6TusD8GPUMC0HlRV8sO8UbqqIN1To0 LHqwpRzWR9IMD8I8hDdwE2hM0aEgfgQIOoUyc+jfzs94wA3lGdndOd/Fq33pb8t2OS9+ 7e2JaIt1BBoggLHwR3ZPU8up3o8FAsJ9fnoom4Nfic2+koRPgPglawVe4XdWxR+1sz9R t+cx6oSvgSgZP72c7DyV5cp27pTnSHZ8UrzyQKxhC/Wu4DOIz5prtHzlRZccbFfYtZtf GANg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=llUBdbDW14HW7XL9/PW5t61nf/sCHlw8KDYtRU/yCJU=; b=ejUWZahXM4Wyb+JBr/3jlEif5qabS6vzCRcvaEdl7qpWAgCti/In/zbcD4vK8I83yW 2jnKkWfu9pTOz9s3xOwGYqxpTTis9egv7Ha4ppRQz9V11jJ4AZ399PwJdVywXugCEUWJ 9/24wliT28rIEOdvsrCuFhf/c+gJ6VevAJMZ94pZFXYwBUY29RahjmDnJ2Qn7csABtqF tNTib4OTM6DqjcTrF57pTmU+7Y/UjwLDtc6J7boQ5bi18BzSWncmiecO3+d2LrKv/bQn rZak+DLpAcbegzx4YseJkkSY/cab4mompR3s0OJQB5J3aA8SUXHG5hj1tKovOE2O4POI BZdw== X-Gm-Message-State: AMCzsaVKllmNGw5u5w2vElGdTkyzCw9e+0PedZib+deyJmUdiz7OuG68 r5alIQ2kMeGMYRSW1HWSmPk= X-Google-Smtp-Source: ABhQp+T1PhwmCTx2WM4ASvKgZdyWBBkiIJ5HSi4CtDWFysRW4XAEtnVlwgUjAD32gFzg9tnBSEbAyQ== X-Received: by 10.46.19.2 with SMTP id 2mr6579938ljt.188.1509967055275; Mon, 06 Nov 2017 03:17:35 -0800 (PST) Received: from [127.0.0.1] ([213.87.138.42]) by smtp.gmail.com with ESMTPSA id k37sm2352371lfi.27.2017.11.06.03.17.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Nov 2017 03:17:34 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20171106111734.5910610.72726.7307@gmail.com> Date: Mon, 06 Nov 2017 14:17:34 +0300 From: =?utf-8?b?0KHRgtCw0L3QuNGB0LvQsNCyINCh0LzRi9GI0LvRj9C10LI=?= In-Reply-To: References: To: "Paterson, Kenny" , Peter Alexander Cc: Cfrg@irtf.org Archived-At: Subject: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessions. - Draft I-D Attached 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, 06 Nov 2017 11:17:39 -0000 Dear Kenny, dear colleagues, Definitely, I'll do this. But, if you don't mind, I'd prefer to wait a few = days for the Crypto Review Panel reviews to =E2=80=8Ebe posted, because the= issues related to the scope of the Peter's document ("when to re-key and h= ow to control the process")=E2=80=8E could be also mentioned in the reviews= - so it would be better to take those considerations into account before f= urther discussions.=C2=A0 Best regards, Stanislav =E2=80=8E =C2=A0 =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE= =D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 =C2=A0 =D0=9E=D1=82: Paterson, Kenny =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: =D0=BF=D0=BE= =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BD=D0=BE=D1= =8F=D0=B1=D1=80=D1=8F 2017=C2=A0=D0=B3., 13:53 =D0=9A=D0=BE=D0=BC=D1=83: Stanislav V. Smyshlyaev; Peter Alexander =D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: Cfrg@irtf.org =D0=A2=D0=B5=D0=BC=D0=B0: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessi= ons. - Draft I-D Attached Dear Stanislav, This sounds like a reasonable way of proceeding. Please would you initiate a discussion here on the list of the relevant principles from Peter's document? Regards, Kenny=20 On 04/11/2017 15:29, "Cfrg on behalf of Stanislav V. Smyshlyaev" wrote: >Dear colleagues, > > >The overall scope is close, but draft-irtf-cfrg-re-keying is about "why >and > how to re-key", and the proposed draft is about "when to re-key and how >to control the process". > > >As a possible way, we could discuss in CFRG, which general principles of >Peter's document (overall principles of how to control the re-keying >process) would be reasonble to add to draft-irtf-cfrg-re-keying. > > >And questions related to the particular protocols (e.g., IPsec, as in the >provided Peter Alexander's draft) seem to be more convenient to be >discussed within corresponding working groups - such as ipsecme WG. > >Best regards, >Stanislav > > > > > > > >2017-11-04 17:36 GMT+03:00 Peter Alexander >: > >Good morning everyone, > > >I am attaching my first go at a proper I-D for submission. This is the >same invention that I had mentioned previously, and is quite similar in >scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08). > > >Right now I am still working through the Doxygen documentation to >translate the control messages into a cleaner I-D format. > > >Kindly review this when you are able to do so, and share your comments. > > >Peter Alexander > > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg > > > > > > > > From nobody Mon Nov 6 05:24:22 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFAC13FC11 for ; Mon, 6 Nov 2017 05:24:21 -0800 (PST) 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 Rc-4VRtnSX9L for ; Mon, 6 Nov 2017 05:24:19 -0800 (PST) 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 2CC8E13FAFB for ; Mon, 6 Nov 2017 05:24:19 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a142so2056269qkb.5 for ; Mon, 06 Nov 2017 05:24:19 -0800 (PST) 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=0sol60LN2LfGaD0ZPfJNqw3lspzBgD7mfKASPy5qRAs=; b=GtcbLYWd/Mq3PHhB6r6kMd0fVlv13dlqjvrOdYoof9dQXh8DvYYfk1G//u2/3o6TrJ MmTsyT+ls4lTesjWV4YOcEtdNIMYExPiAq1ijKLXLP1Y85LSqpulOaEHu96AtCyF4hAE /Zkv8PAn7CnWJFArEQaLaUzx0sHQypust13mCH3NwDbUQZiK5Jsd7KFbEJT1MBTIP2rB dJms4L6LP/MOMHfKEsLJdrgqRJl7TD/LwcBwhUqBTHdv5c59S8ctFPtjHLTfu9yVT1lY 1xIKhxszSbb3gHiYng8pXunGN6/ipTA95e3pG1Kvf+axfZSc+Jct8hz1IqjCSXIGgJO1 IoQw== 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=0sol60LN2LfGaD0ZPfJNqw3lspzBgD7mfKASPy5qRAs=; b=P51ZjG1U2ywKVSNESUukCApsfWqMpYBFlxwhO6wP14sPwpr41qyMGUt8JWCdCCNWfF 8NV5sLsMtboI1gkj/s8zVGhzFigyXt/ZIzbbf2+0H6LwgMYinN33pa+9uDmI39Uw5dfg ikUOesulFMXsgblKsCxxOZ9VMyLoKZWO6eVmO99l+o0CTyfyjtJ3DYbdbDfJFxeaSnFo 8p6/hjobhjX8TLtumgHSvnSJ4pnFWk3wTa4Od03N3B3uVPQIzYMkqTmY0uVx5w8PMHQ4 bj0QRqop/IdhvVfQ4f0EgEzfldvKjuletB24IO7vgWO2LRl+QzBqIZBWWz8i7VYyJhZd nazw== X-Gm-Message-State: AJaThX6jf/1exjoQHbd2sfVHKLpV93BV08AsxVMrmuUbvOuZAjnidFe6 7HXcQt+mGBSCQjhgIIRdBazv4nMruAe0ICG8N5w= X-Google-Smtp-Source: ABhQp+QuLTCqc0z77oVuO/0JK+AleN6Krg8rJSeyuBQJAIouNcvYwyoKHmvx4ezojmmgcg+YxB5B1PEIpt0k3QYW4w4= X-Received: by 10.55.55.203 with SMTP id e194mr5822251qka.179.1509974658186; Mon, 06 Nov 2017 05:24:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.58.103 with HTTP; Mon, 6 Nov 2017 05:24:17 -0800 (PST) In-Reply-To: <20171106111734.5910610.72726.7307@gmail.com> References: <20171106111734.5910610.72726.7307@gmail.com> From: Peter Alexander Date: Mon, 6 Nov 2017 08:24:17 -0500 Message-ID: To: =?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCyINCh0LzRi9GI0LvRj9C10LI=?= Cc: "Paterson, Kenny" , Cfrg@irtf.org Content-Type: multipart/alternative; boundary="001a11472f5e1f02f3055d505f2a" Archived-At: Subject: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessions. - Draft I-D Attached 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, 06 Nov 2017 13:24:21 -0000 --001a11472f5e1f02f3055d505f2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Colleagues, Thank you for taking my work into consideration. I was worried that nothing would ever come of it, however the warm reception is most welcome. Furthermore, I am very happy to see progress on this, and would be more than willing to review, and adopt changes as necessary. Peter Alexander Email: pipnflinx@gmail.com On Mon, Nov 6, 2017 at 6:17 AM, =D0=A1=D1=82=D0=B0=D0=BD=D0=B8=D1=81=D0=BB= =D0=B0=D0=B2 =D0=A1=D0=BC=D1=8B=D1=88=D0=BB=D1=8F=D0=B5=D0=B2 wrote: > Dear Kenny, dear colleagues, > > Definitely, I'll do this. But, if you don't mind, I'd prefer to wait a fe= w > days for the Crypto Review Panel reviews to =E2=80=8Ebe posted, because t= he issues > related to the scope of the Peter's document ("when to re-key and how to > control the process")=E2=80=8E could be also mentioned in the reviews - s= o it would > be better to take those considerations into account before further > discussions. > > Best regards, > Stanislav > =E2=80=8E > =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0= =B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 > =D0=9E=D1=82: Paterson, Kenny > =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: =D0=BF=D0= =BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BD=D0=BE= =D1=8F=D0=B1=D1=80=D1=8F 2017 =D0=B3., 13:53 > =D0=9A=D0=BE=D0=BC=D1=83: Stanislav V. Smyshlyaev; Peter Alexander > =D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: Cfrg@irtf.org > =D0=A2=D0=B5=D0=BC=D0=B0: Re: [Cfrg] Dynamic Key Changes on Encrypted Ses= sions. - Draft I-D > Attached > > Dear Stanislav, > > This sounds like a reasonable way of proceeding. > > Please would you initiate a discussion here on the list of the relevant > principles from Peter's document? > > Regards, > > Kenny > > On 04/11/2017 15:29, "Cfrg on behalf of Stanislav V. Smyshlyaev" > wrote: > > >Dear colleagues, > > > > > >The overall scope is close, but draft-irtf-cfrg-re-keying is about "why > >and > > how to re-key", and the proposed draft is about "when to re-key and how > >to control the process". > > > > > >As a possible way, we could discuss in CFRG, which general principles of > >Peter's document (overall principles of how to control the re-keying > >process) would be reasonble to add to draft-irtf-cfrg-re-keying. > > > > > >And questions related to the particular protocols (e.g., IPsec, as in th= e > >provided Peter Alexander's draft) seem to be more convenient to be > >discussed within corresponding working groups - such as ipsecme WG. > > > >Best regards, > >Stanislav > > > > > > > > > > > > > > > >2017-11-04 17:36 GMT+03:00 Peter Alexander > >: > > > >Good morning everyone, > > > > > >I am attaching my first go at a proper I-D for submission. This is the > >same invention that I had mentioned previously, and is quite similar in > >scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08). > > > > > >Right now I am still working through the Doxygen documentation to > >translate the control messages into a cleaner I-D format. > > > > > >Kindly review this when you are able to do so, and share your comments. > > > > > >Peter Alexander > > > > > >_______________________________________________ > >Cfrg mailing list > >Cfrg@irtf.org > >https://www.irtf.org/mailman/listinfo/cfrg > > > > > > > > > > > > > > > > > > --001a11472f5e1f02f3055d505f2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,=C2=A0

Thank you for ta= king my work into consideration. I was worried that nothing would ever come= of it, however the warm reception is most welcome.
Furthermore, = I am very happy to see progress on this, and would be more than willing to = review, and adopt changes as necessary.


=
Peter Alexander


On Mon, Nov 6, 2017 at 6:17 AM, =D0=A1= =D1=82=D0=B0=D0=BD=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=A1=D0=BC=D1=8B=D1=88= =D0=BB=D1=8F=D0=B5=D0=B2 <smyshsv@gmail.com> wrote:
Dear Kenny, dear colleagues,

Definitely, I'll do this. But, if you don't mind, I'd prefer to= wait a few days for the Crypto Review Panel reviews to =E2=80=8Ebe posted,= because the issues related to the scope of the Peter's document ("= ;when to re-key and how to control the process")=E2=80=8E could be als= o mentioned in the reviews - so it would be better to take those considerat= ions into account before further discussions.=C2=A0

Best regards,
Stanislav
=E2=80=8E
=C2=A0 =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE= =D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 =C2=A0
=D0=9E=D1=82: Paterson, Kenny
=D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: =D0=BF=D0=BE= =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BD=D0=BE=D1= =8F=D0=B1=D1=80=D1=8F 2017=C2=A0=D0=B3., 13:53
=D0=9A=D0=BE=D0=BC=D1=83: Stanislav V. Smyshlyaev; Peter Alexander
=D0=9A=D0=BE=D0=BF=D0=B8=D1=8F: Cfrg@irtf.= org
=D0=A2=D0=B5=D0=BC=D0=B0: Re: [Cfrg] Dynamic Key Changes on Encrypted Sessi= ons. - Draft I-D Attached

Dear Stanislav,

This sounds like a reasonable way of proceeding.

Please would you initiate a discussion here on the list of the relevant
principles from Peter's document?

Regards,

Kenny

On 04/11/2017 15:29, "Cfrg on behalf of Stanislav V. Smyshlyaev"<= br> <cfrg-bounces@irtf.org on b= ehalf of smyshsv@gmail.com> wro= te:

>Dear colleagues,
>
>
>The overall scope is close, but draft-irtf-cfrg-re-keying is about &quo= t;why
>and
> how to re-key", and the proposed draft is about "when to re-= key and how
>to control the process".
>
>
>As a possible way, we could discuss in CFRG, which general principles o= f
>Peter's document (overall principles of how to control the re-keyin= g
>process) would be reasonble to add to draft-irtf-cfrg-re-keying.
>
>
>And questions related to the particular protocols (e.g., IPsec, as in t= he
>provided Peter Alexander's draft) seem to be more convenient to be<= br> >discussed within corresponding working groups - such as ipsecme WG.
>
>Best regards,
>Stanislav
>
>
>
>
>
>
>
>2017-11-04 17:36 GMT+03:00 Peter Alexander
><pipnflinx@gmail.com>:=
>
>Good morning everyone,
>
>
>I am attaching my first go at a proper I-D for submission. This is the<= br> >same invention that I had mentioned previously, and is quite similar in=
>scope to what Stanislav is working on (draft-irtf-cfrg-re-keying-08).
>
>
>Right now I am still working through the Doxygen documentation to
>translate the control messages into a cleaner I-D format.
>
>
>Kindly review this when you are able to do so, and share your comments.=
>
>
>Peter Alexander
>
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg >
>
>
>
>
>
>
>


--001a11472f5e1f02f3055d505f2a-- From nobody Wed Nov 8 07:45:23 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 24359127A91 for ; Wed, 8 Nov 2017 07:45:18 -0800 (PST) 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, FREEMAIL_FROM=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 L7owSuKUbabn for ; Wed, 8 Nov 2017 07:45:16 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 EF5D9127869 for ; Wed, 8 Nov 2017 07:45:15 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id b6so1740783pff.10 for ; Wed, 08 Nov 2017 07:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=dqRA4M05TuJCev/x6v1NUI9Q7MhMQhbyOfC1LPJDpT4=; b=FqYxJB65V85KPXV8tcnf2g1dSa/gp8PpOkBUCUAkzIMXz+WEd+C/yKJ+j0dl9PbWIs S8jU8lgtyK1Hh96i+sF2mZlfxx13WErIhvxzPV7ivKVBe5NR4kLrmIbABKzc+sZQp8L5 L+ViV+6dfDPecAP3Ueq6B2y+OfXwFP+0sabWOaZwoZ+fOJ4UkYD0wfoYAk2uM8OArSu2 7cpVGFSp4t7WEFr5vhfG36nH4+kAjlvirBBnT4PcEbjeuVPDavvTLCA060rSqUI/vyjK R+w7eLxxF8ToGDtN/M6WZSeqQWynvYLtZpYBawKx9m2vsBvMNcp7tyAdjn1YorhrDYkz i6qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=dqRA4M05TuJCev/x6v1NUI9Q7MhMQhbyOfC1LPJDpT4=; b=V3XCs2t8MxrvVT1paL2QSDR1uttcQ5RBPEef7lGS917V2por3iSskytwa+ixgzC4jo sz0fFp76pNvlQV1Q/Kn2jND9EC/waNcS1gc8ii5fqsTa+UrzyClsoAWOkVzv4nj0dMA6 g47COIdd0VV7/ghZkTTSdvBo7PIxDxw248r6/sMww0ZpE0v+U164CplCTVksm3iWpFM3 eGj3VTIYpF0iqyhCflbTdtvasF9ojg5gx62+P1Kub1WLuCDLfglGno5BsZq5Si+eE/M8 HPMVueV/gnNMiJiLUnvF6Ap0oZ28XWEE+3IRVEfbMeL2aYiVPZ3pekj08b80lsVLT2gw vJiw== X-Gm-Message-State: AJaThX6XXXn53004B0u8u02WrT7kR+6QiAp0mZYvwyghkaw8JpP4eUG8 u/iNL4eMILQ/9Mz7pYmZcPrK1VOp X-Google-Smtp-Source: ABhQp+RhxYaWYJKIEZGL0GaBtD0WDZJR+W/zi43hyGB3NOOI8PQoJJXWRnft57ea0buWmCV5y0G7+Q== X-Received: by 10.101.88.203 with SMTP id e11mr862485pgu.173.1510155915035; Wed, 08 Nov 2017 07:45:15 -0800 (PST) Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id g16sm8125687pgn.43.2017.11.08.07.45.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 07:45:14 -0800 (PST) From: Yaron Sheffer To: cfrg@irtf.org Message-ID: <6a0c609b-2986-2498-1ad6-38689dcdaa5f@gmail.com> Date: Wed, 8 Nov 2017 17:45:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Cfrg] Review of draft-irtf-cfrg-re-keying-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 15:45:18 -0000 Summary I think the document is not ready to be published yet, for the following reasons: First, it is very heavy reading, with important details buried between mountains of pseudo-code and analysis. I would recommend to add a 2-page summary at the top of the document, describing the proposed solutions and their applicability. Maybe Sec. 4 could be tweaked into this form if you added forward references to the specific proposed mechanisms, but then the section would still be very long. Second, this document is a problematic hybrid of common techniques for "external" re-keying, and original cryptography for "internal" re-keying (where a reference to the work/proof is definitely needed). Readers who approach the document expecting a survey because of the very generic title will be surprised. Assuming this is intended to be a survey of related techniques, references to the literature are needed, and I would expect additional techniques to be mentioned, even if briefly. Lastly, I would expect more clarity on the interaction of the re-keying mechanisms with security protocols and operating systems. Security protocols and operating systems both allow to refresh keys with new entropy. In addition, HSMs (and related technologies, such as security enclaves) can help to achieve better forward secrecy using asymmetric cryptography than the techniques described here. I would also suggest to mention another important use case for symmetric key re-keying: encryption of data at rest. Please note that this document includes original cryptography, and, not being a cryptographer, I am unable to comment on its security. This review was written at the request of the CFRG Crypto Panel. I have benefited from a lengthy discussion with the draft's author, Stanislav Smyshlyaev, and I would like to thank him for that. Details * Abstract: you use the terms "internal" and "external" which are neither defined here nor very common, so I don't think they belong in the abstract. * "Key lifetime" often means something else, the actual time (e.g. months) after which the user is procedurally obliged to replace a key. So let's say that this is/our/definition of the term. * 2^(n/2) where n is? * "the total size of the processed plaintext" - often the limitation is on the number of encryptions (e.g. number of packets encrypted) rather than total size, e.g. because of nonce reuse. And this is the exact opposite of the rectangle analogy, which implies that the fixed value is the total number. * Introduction: please mention if these solutions also apply to encryption of data at rest, in addition to network protocols. * Also, your threat model does not include what is possibly the most important threat for many Internet-connected systems: a time-limited but complete breach of the system. If these approaches are useless under this threat and only external renegotiation with forward secrecy is effective, fine, but we should say so. * Introduction: I suggest that you mention who is the target audience: protocol developers? Implementers? Are there cases where these mechanisms can be used with no protocol-level changes and therefore can be used directly by implementers? * Basic Terms: for some of these definitions, an informal explanation would help. E.g. Int_s is the interpretation of the string as a binary integer. * Terms: "section" is a strange name, but I don't have a better alternative. * "For protocols which allow out-of-order delivery and lost records" - these protocols typically include a sequence number which can be used for internal rekeying. * The "summing up" section includes several assertions that have not been explained yet at this point, e.g. about tree-based, hash-based re-keying. * Serial (external) constructions: it is unclear to me what are the use cases where the serial mechanisms may be preferred. * While a proof does not belong in an RFC, the document should referencehttps://eprint.iacr.org/2017/697.pdf which contains security proofs, at least for some variants of ACPKM. * 6.2.1: you lost me in the arithmetic. Are we assuming a certain block size for the cipher here? * "It allows to prevent collisions of block cipher permutation inputs in cases of key transformation and message processing" - this text is extremely opaque. * 6.2.3: as far as I remember, GCM is defined even when the last block is not a multiple of 16 bytes. So I think this mode should also handle this case. At least GHASH appears not to do that. And I think the same applies to the CTR mode above. * I'm not sure I understand the notion of a "master key" in this context, and maybe it is not explained well. ISTM that the difference between ACPKM and ACPKM-Master is that one is serial (K is used for the first section, and then repeatedly processed to produce a sequence of keys) whereas the other one is "parallel", and does not use K directly. But K is obtained the same way from the network protocol, so it doesn't make sense to me to call it "master key" only in the parallel case. From nobody Wed Nov 8 08:26: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 9E24A12871F for ; Wed, 8 Nov 2017 08:26:43 -0800 (PST) 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 Yt33T1d4pZoa for ; Wed, 8 Nov 2017 08:26:41 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0959C1286D6 for ; Wed, 8 Nov 2017 08:26:41 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id v137so4042550qkb.1 for ; Wed, 08 Nov 2017 08:26:40 -0800 (PST) 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=6HZnFcTXht2UdyJQmry+GJNxmZ5gLGP4O9bxIiLT64c=; b=P4fELJTClasreqBfX66nIl/QgYf35lHAs8aLtc1ta9v6gsePkWgAOZXeDtOULMmfcT JKhytevDWSFmMGYzV/osO1tvJlC0vi0cDLY9qvE07U7Pk43S0LVQKkoIXq9clluctmIi ltWuf3gj/5ZIGMrAUVr3os4d0tOQURfTbAz5DL/pSFyAKV3mQDvhO18G0L/IqXNHflAE 7PJROIhp4XspAPS96fmnaye+I7JuIyFj1Gf/33ZVtBzUVeirQk72Nu5tmmv4eQ7j3/9L 92PVIw1OCnlb6zvMZtQLcfOxRkl+XEwNeePtOCaKZUIUEYjQbOY5CVuiMIZCTzgBnMys cFkw== 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=6HZnFcTXht2UdyJQmry+GJNxmZ5gLGP4O9bxIiLT64c=; b=lVWzzB4OfDHCEZCtjV4deDq0reYG5/2dNZx3PnaOXwQYCITcg1f4QRcEdmOHvRURvZ gGTo+hN3le7T5bJGZ/L6EDywb47Gmh7Gk5A8zaOysL42j7MC1l/oReIW0YxpjOwp/dHQ FCUX0wpteid1W/kFRBW69QoaMP6FrENjmaCtihxtzndUXeQDj2t3LvUg7Q80oaz6LE+0 1dbDsIk6212TuRCpBNCn/ZtkFCQUTN+asWAq/QqzLqsVwxcR+CN19pD20CszQ/pacxQY 9fGTr6RvyK79AmMXlxb+9/XRt+yy/7fvNJEGvM1U/SODRgmVxHyYfkKmSt5KT1K1fcCj nGuA== X-Gm-Message-State: AJaThX4X0ensLp83oT9ySGVp+TaKI6sjzbTBC32d1GFCNH5Ci60Gg7+2 WeqsT7YLBJd+hq4a6d5UUgg3gtLp7oSTOGODg+k= X-Google-Smtp-Source: ABhQp+SpK0NNtO3HPRKAZEb74UFPUupOXQIMCLDc804Ybi6hvBpJ9NMMeExTEsnMUenFb/GppWEFsrHmSZzIEEkUHOs= X-Received: by 10.55.80.193 with SMTP id e184mr1633635qkb.126.1510158400156; Wed, 08 Nov 2017 08:26:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Wed, 8 Nov 2017 08:26:39 -0800 (PST) In-Reply-To: <6a0c609b-2986-2498-1ad6-38689dcdaa5f@gmail.com> References: <6a0c609b-2986-2498-1ad6-38689dcdaa5f@gmail.com> From: "Stanislav V. Smyshlyaev" Date: Wed, 8 Nov 2017 19:26:39 +0300 Message-ID: To: Yaron Sheffer Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a114a7036fefb5c055d7b260b" Archived-At: Subject: Re: [Cfrg] Review of draft-irtf-cfrg-re-keying-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 16:26:43 -0000 --001a114a7036fefb5c055d7b260b Content-Type: text/plain; charset="UTF-8" Dear Yaron, Thank you very much for your efforts - most of your comments are very reasonable and I believe that addressing them will make the resulting document better. Some of the issues (e.g. the mix-in entropy for the cases of long-term keys stored inside HSMs) seem to be complex enough for creating separate documents to address them, but, of course, it will be good for the current I-D if we add considerations related to them. After receiving concerns and recommendations of the second Crypto Panel review and keeping in mind additional questions that have been raised recently (related to Peter Alexander's I-D), I'll prepare a summary of the things to be done before finishing the document. I hope that I'll also manage to give such a summary in my talk at CFRG meeting during IETF 100. Best regards, Stanislav 2017-11-08 18:45 GMT+03:00 Yaron Sheffer : > Summary > > I think the document is not ready to be published yet, for the following > reasons: > > First, it is very heavy reading, with important details buried between > mountains of pseudo-code and analysis. I would recommend to add a 2-page > summary at the top of the document, describing the proposed solutions and > their applicability. Maybe Sec. 4 could be tweaked into this form if you > added forward references to the specific proposed mechanisms, but then the > section would still be very long. > > Second, this document is a problematic hybrid of common techniques for > "external" re-keying, and original cryptography for "internal" re-keying > (where a reference to the work/proof is definitely needed). Readers who > approach the document expecting a survey because of the very generic title > will be surprised. Assuming this is intended to be a survey of related > techniques, references to the literature are needed, and I would expect > additional techniques to be mentioned, even if briefly. > > Lastly, I would expect more clarity on the interaction of the re-keying > mechanisms with security protocols and operating systems. Security > protocols and operating systems both allow to refresh keys with new > entropy. In addition, HSMs (and related technologies, such as security > enclaves) can help to achieve better forward secrecy using asymmetric > cryptography than the techniques described here. I would also suggest to > mention another important use case for symmetric key re-keying: encryption > of data at rest. > > Please note that this document includes original cryptography, and, not > being a cryptographer, I am unable to comment on its security. > > This review was written at the request of the CFRG Crypto Panel. I have > benefited from a lengthy discussion with the draft's author, Stanislav > Smyshlyaev, and I would like to thank him for that. > > Details > > * Abstract: you use the terms "internal" and "external" which are neither > defined here nor very common, so I don't think they belong in the abstract. > * "Key lifetime" often means something else, the actual time (e.g. months) > after which the user is procedurally obliged to replace a key. So let's say > that this is/our/definition of the term. > * 2^(n/2) where n is? > * "the total size of the processed plaintext" - often the limitation is on > the number of encryptions (e.g. number of packets encrypted) rather than > total size, e.g. because of nonce reuse. And this is the exact opposite of > the rectangle analogy, which implies that the fixed value is the total > number. > * Introduction: please mention if these solutions also apply to encryption > of data at rest, in addition to network protocols. > * Also, your threat model does not include what is possibly the most > important threat for many Internet-connected systems: a time-limited but > complete breach of the system. If these approaches are useless under this > threat and only external renegotiation with forward secrecy is effective, > fine, but we should say so. > * Introduction: I suggest that you mention who is the target audience: > protocol developers? Implementers? Are there cases where these mechanisms > can be used with no protocol-level changes and therefore can be used > directly by implementers? > * Basic Terms: for some of these definitions, an informal explanation > would help. E.g. Int_s is the interpretation of the string as a binary > integer. > * Terms: "section" is a strange name, but I don't have a better > alternative. > * "For protocols which allow out-of-order delivery and lost records" - > these protocols typically include a sequence number which can be used for > internal rekeying. > * The "summing up" section includes several assertions that have not been > explained yet at this point, e.g. about tree-based, hash-based re-keying. > * Serial (external) constructions: it is unclear to me what are the use > cases where the serial mechanisms may be preferred. > * While a proof does not belong in an RFC, the document should > referencehttps://eprint.iacr.org/2017/697.pdf which contains security > proofs, at least for some variants of ACPKM. > * 6.2.1: you lost me in the arithmetic. Are we assuming a certain block > size for the cipher here? > * "It allows to prevent collisions of block cipher permutation inputs in > cases of key transformation and message processing" - this text is > extremely opaque. > * 6.2.3: as far as I remember, GCM is defined even when the last block is > not a multiple of 16 bytes. So I think this mode should also handle this > case. At least GHASH appears not to do that. And I think the same applies > to the CTR mode above. > * I'm not sure I understand the notion of a "master key" in this context, > and maybe it is not explained well. ISTM that the difference between ACPKM > and ACPKM-Master is that one is serial (K is used for the first section, > and then repeatedly processed to produce a sequence of keys) whereas the > other one is "parallel", and does not use K directly. But K is obtained the > same way from the network protocol, so it doesn't make sense to me to call > it "master key" only in the parallel case. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a114a7036fefb5c055d7b260b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Yaro= n,

Thank you very much for your effort= s - most of your comments are very reasonable and I believe that addressing= them will make the resulting document better.=C2=A0

Some of the issues (e.g. the mix-in entropy for the cases of= long-term keys stored inside HSMs) seem to be complex enough for creating = separate documents to address them, but, of course, it will be good for the= current I-D if we add considerations related to them.=C2=A0

<= span style=3D"color:rgb(31,73,125)">After receiving concerns and recommenda= tions of the second Crypto Panel review and keeping in mind additional ques= tions that have been raised recently (related to Peter Alexander's I-D)= , I'll prepare a summary of the things to be done before finishing the = document. I hope that I'll also manage to give such a summary in my tal= k at CFRG meeting during IETF 100.=C2=A0


Best= regards,

Stanislav



2017-11-08 18:45 GMT+03:00 Yaron Sheffer <yaronf.ietf@gmail.com>:
Summary

I think the document is not ready to be published yet, for the following re= asons:

First, it is very heavy reading, with important details buried between moun= tains of pseudo-code and analysis. I would recommend to add a 2-page summar= y at the top of the document, describing the proposed solutions and their a= pplicability. Maybe Sec. 4 could be tweaked into this form if you added for= ward references to the specific proposed mechanisms, but then the section w= ould still be very long.

Second, this document is a problematic hybrid of common techniques for &quo= t;external" re-keying, and original cryptography for "internal&qu= ot; re-keying (where a reference to the work/proof is definitely needed). R= eaders who approach the document expecting a survey because of the very gen= eric title will be surprised. Assuming this is intended to be a survey of r= elated techniques, references to the literature are needed, and I would exp= ect additional techniques to be mentioned, even if briefly.

Lastly, I would expect more clarity on the interaction of the re-keying mec= hanisms with security protocols and operating systems. Security protocols a= nd operating systems both allow to refresh keys with new entropy. In additi= on, HSMs (and related technologies, such as security enclaves) can help to = achieve better forward secrecy using asymmetric cryptography than the techn= iques described here. I would also suggest to mention another important use= case for symmetric key re-keying: encryption of data at rest.

Please note that this document includes original cryptography, and, not bei= ng a cryptographer, I am unable to comment on its security.

This review was written at the request of the CFRG Crypto Panel. I have ben= efited from a lengthy discussion with the draft's author, Stanislav Smy= shlyaev, and I would like to thank him for that.

Details

* Abstract: you use the terms "internal" and "external"= which are neither defined here nor very common, so I don't think they = belong in the abstract.
* "Key lifetime" often means something else, the actual time (e.g= . months) after which the user is procedurally obliged to replace a key. So= let's say that this is/our/definition of the term.
* 2^(n/2) where n is?
* "the total size of the processed plaintext" - often the limitat= ion is on the number of encryptions (e.g. number of packets encrypted) rath= er than total size, e.g. because of nonce reuse. And this is the exact oppo= site of the rectangle analogy, which implies that the fixed value is the to= tal number.
* Introduction: please mention if these solutions also apply to encryption = of data at rest, in addition to network protocols.
* Also, your threat model does not include what is possibly the most import= ant threat for many Internet-connected systems: a time-limited but complete= breach of the system. If these approaches are useless under this threat an= d only external renegotiation with forward secrecy is effective, fine, but = we should say so.
* Introduction: I suggest that you mention who is the target audience: prot= ocol developers? Implementers? Are there cases where these mechanisms can b= e used with no protocol-level changes and therefore can be used directly by= implementers?
* Basic Terms: for some of these definitions, an informal explanation would= help. E.g. Int_s is the interpretation of the string as a binary integer.<= br> * Terms: "section" is a strange name, but I don't have a bett= er alternative.
* "For protocols which allow out-of-order delivery and lost records&qu= ot; - these protocols typically include a sequence number which can be used= for internal rekeying.
* The "summing up" section includes several assertions that have = not been explained yet at this point, e.g. about tree-based, hash-based re-= keying.
* Serial (external) constructions: it is unclear to me what are the use cas= es where the serial mechanisms may be preferred.
* While a proof does not belong in an RFC, the document should referencehtt= ps://eprint.iacr.org/2017/697.pdf=C2=A0 which contains s= ecurity proofs, at least for some variants of ACPKM.
* 6.2.1: you lost me in the arithmetic. Are we assuming a certain block siz= e for the cipher here?
* "It allows to prevent collisions of block cipher permutation inputs = in cases of key transformation and message processing" - this text is = extremely opaque.
* 6.2.3: as far as I remember, GCM is defined even when the last block is n= ot a multiple of 16 bytes. So I think this mode should also handle this cas= e. At least GHASH appears not to do that. And I think the same applies to t= he CTR mode above.
* I'm not sure I understand the notion of a "master key" in t= his context, and maybe it is not explained well. ISTM that the difference b= etween ACPKM and ACPKM-Master is that one is serial (K is used for the firs= t section, and then repeatedly processed to produce a sequence of keys) whe= reas the other one is "parallel", and does not use K directly. Bu= t K is obtained the same way from the network protocol, so it doesn't m= ake sense to me to call it "master key" only in the parallel case= .

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

--001a114a7036fefb5c055d7b260b-- From nobody Wed Nov 8 08:30:02 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 1BD46128796 for ; Wed, 8 Nov 2017 08:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 TJtlh4DMh3tc for ; Wed, 8 Nov 2017 08:29:57 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 32BE31286B1 for ; Wed, 8 Nov 2017 08:29:57 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id f46so2334320uae.1 for ; Wed, 08 Nov 2017 08:29:57 -0800 (PST) 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=MB4otp9j7RxTHrN8FoV1ina0g04Bl0PhxH3OI6cHXCQ=; b=lm8pBcDizoGDVWtAo3aj6/v+VNGpRx9WaaHS39HAbMHbe9UsCcwNnc0iGWf1PkAdAP YTNNBwugVcxjrguqI0XHD5ofHb5mcf61lQWQAddEKtcj/tqzK9C/QDFBAUhHw2r0vJTE 1UmueKKlxshy1m6ZoE8YGs1Vv4/cnVUJ0dZdhsEUQqJDQm/yX50aNdc9/EAfmp/zgaw1 6I2pyvqa2bMuurgMloONw28o26TZH8PBipBLUd/UPEq10ZJ1v/96w9+2DrNEhnO4J4YY bdIswMu1rwVprOUn+p/BKidtCt5oqyM88KvizsttfkWB8muGBULVM0ZjsGYWmXKcSd7k uHdQ== 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=MB4otp9j7RxTHrN8FoV1ina0g04Bl0PhxH3OI6cHXCQ=; b=BNejBEaLn+mOj2uDVqDzsh1PLMvRlnU0Y5gHiSfbsmsd+7ZZMNy+phrM1RD+VRzoD1 HnwtkJgHtSEm844XcPrc9D8fWnFv+CprNZGoUSBeBBzrZdOQ1Bz2e8P1vwrYLpfseXo8 +dgCLD7eBxEQmkTzPy+kU8QcyZaZtSPsJhxlS6YIuq1Ps4+z1Nj1pYwJPwA2UbFwBoU4 5+kMk/nM2gMKyjFcqZH5JkHk6VG/gteXtlJYnwKbIwvAdiB89JVDhrW32bJrFtDGSzq7 SDaYwEW210VRMN+JB6PMEsuSGIFgKl+hKiS7VAgWMMbTroqwIoVtIOO9TUPeI8XTBHkN CaqQ== X-Gm-Message-State: AJaThX6vr4XfcCb3O45pOz9GLjUXM9duNsRh2rLLoeboIkt4ROCKRN/v np7zD16LWOG8/kWmupciBWOTuueW6RP9D5iEAbuAmO/w X-Google-Smtp-Source: ABhQp+SWPr4L3b6ED2DboDF5KqR3xDiDhC+BAqd9mEKLuPeT3gHQUXfkFoueFLaCdJurxc6QmRd27GRAp2oX2aRZaSg= X-Received: by 10.176.69.4 with SMTP id r4mr911813uar.125.1510158595858; Wed, 08 Nov 2017 08:29:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.14.199 with HTTP; Wed, 8 Nov 2017 08:29:35 -0800 (PST) From: Tony Arcieri Date: Wed, 8 Nov 2017 08:29:35 -0800 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c0cfe06a926bf055d7b3209" Archived-At: Subject: [Cfrg] AES-PMAC-SIV 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, 08 Nov 2017 16:30:00 -0000 --94eb2c0cfe06a926bf055d7b3209 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am considering writing an I-D for AES-PMAC-SIV: a fully parallelizable misuse resistant AES mode based on generic composition, combining AES-CTR in SIV mode (ala RFC 5297) but substituting AES-PMAC[1] for AES-CMAC. All constructions I just named, aside from "AES-PMAC-SIV" itself, were originally designed by Phil Rogaway, who also suggested substituting PMAC for CMAC to me in the first place. I wrote a blog post about a set of 5 libraries I have written implementing the construction here: https://tonyarcieri.com/introducing-miscreant-a-multi-langua ge-misuse-resistant-encryption-library # Why? There are a number of other misuse resistant schemes available, including the (hopefully) nearly finalized work on AES-GCM-SIV being done through this group, and a misuse resistant scheme is almost certainly going to be part of the CAESAR portfolio. So why AES-PMAC-SIV? What makes it unique? AES-PMAC-SIV is, to my knowledge, the simplest fully parallelizable misuse resistant scheme, particularly applicable to environments that require small code size, have hardware accelerated AES, but do not have the analogue of a CLMUL instruction. Embedded and "Internet of Things" devices often fall into this category, with AES acceleration exceedingly common but CLMUL-style instructions generally only available on smartphone-class devices or x86 desktops/laptops/servers. For this reason we see a similar split in AES-GCM versus AES-CCM adoption. The latter is generally preferred in the sort of embedded environments I am referencing due to these restrictions. I think it would be nice to have an "IoT friendly" misuse resistant scheme. "IoT" seems like an area which could greatly benefit from misuse resistance, as these devices often have limited/poor random number generation capability, so a nonce-based misuse resistant scheme would provide an additional layer of defense in the event of catastrophic RNG failures. # Properties AES-PMAC-SIV is a two-pass offline mode of AES which provides misuse resistant authenticated encryption (MRAE) and supports fully parallel implementations. Traditionally using a 2-pass mode might be considered a blocker for IoT use cases, as devices in this class may generally be rather starved of RAM and unable to hold large messages for a two-pass encryption process. This is a valid concern, and one I think can be addressed in a provably secure manner by employing the CHAIN and/or STREAM constructions[2] to transform AES-PMAC-SIV (or other authenticated modes) into an online mode. STREAM in particular is very simple and easy to implement. Specifying these schemes is arguably out-of-scope for an AES-PMAC-SIV RFC, however. # Performance A naive Rust implementation of AES-PMAC-SIV performs* at ~2.4 cycles/byte for 16kB messages on a 3.1GHz i7. According to Rogaway, an ideal assembly implementation should perform at ~1.25 cycles/byte. I believe this is approximately half the speed of AES-GCM-SIV (AES-PMAC-SIV needs to run the AES function twice as often), although I have been having trouble finding implementations of the AES-GCM-SIV draft to benchmark against. *NOTE: Rough measurements, turbo boost not disabled, more due diligence required for a more accurate figure # Security The security proofs for AES-SIV rely on AES-CMAC being a secure PRF. As AES-PMAC is also a secure PRF, the proofs also hold for it as well. I asked Rogaway for some more specifics on this and whether the proofs of AES-SIV's security and security bounds hold for PMAC as well as they do with CMAC. Here's what he had to say: "The proof in the SIV paper uses generic properties of the SIV construction: you can stick in any provably-sound PRF. Quantitative results will depend on the quality of the PRF, but in the case of CMAC and PMAC, the =E2=80=98basic=E2=80=99 bounds are the same (within a small constant). = I remember there being somewhat improved bounds for PMAC, like [Nandi, Mandal 2007], but by the time you throw in CTR, it probably doesn=E2=80=99t help. So, yes, effec= tively equivalent, as far as I know." I think this area could warrant some further study. If you're an academic cryptographer who is interested in studying (and potentially writing a paper about) AES-PMAC-SIV, please let me know. # IPR The IPR status of the underlying AES-SIV construction is covered in RFC 5297: there are no IPR concerns. Regarding PMAC specifically, it was originally patented by Phil Rogaway, but he has since abandoned his patents. A statement to this effect from Rogaway can be found in the PMAC FAQ[3]: "I abandoned all patent filings pertaining to PMAC many years ago. As far as I know, there is no IP relevant to using PMAC =E2=80=94 nothing owned by= me or by anyone else." # Other MRAE Constructions There are a number of newer constructions which are a variation in the same ideas as AES-PMAC-SIV and its component parts, such as SIVx / PMAC2x[4], ZMAC / ZAE[5], and 1k-PMAC_Plus[6], which try to attain higher security bounds i.e. Beyond Birthday Bound (BBB) security. In discussing these schemes with the chairs we agreed that the perhaps the main reason AES-PMAC-SIV is so attractive is because it's so simple and boring, with well-understood security properties and well-scrutinized component parts that have been around for over a decade and the basis of much cryptography research. Newer schemes may seem alluring but may not actually achieve their stated goals[7]. Several of the round 3 CAESAR candidates are MRAE, including some of Rogaway's latest work: AEZ. However these candidates are generally optimizing for performance and interesting security properties as opposed to simplicity of implementation and minimal code size. If you feel there's a candidate I've overlooked with similar properties please let me know. AES-GCM-SIV is quite interesting but has a more complex implementation requiring CLMUL-style acceleration and lower security bounds (2^32 due to GCM, as opposed to 2^64 AES birthday bound for AES-PMAC-SIV). As I mentioned earlier, GCM has previously been a no-go in the embedded space for lack of CLMUL-like instructions. # Status I have announced a set of libraries implementing this construction in several languages (see link at the top), however there is not yet widespread usage of this construction in the "running code" sense of "rough consensus and running code". In addition to writing a draft I'd like to encourage some organic usage, particularly in the IoT space, and get feedback as to how well this scheme works in the real world. [1] http://web.cs.ucdavis.edu/~rogaway/ocb/pmac.pdf [2] http://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf [3] http://web.cs.ucdavis.edu/~rogaway/ocb/pmac-bak.htm [4] https://eprint.iacr.org/2016/1174 [5] https://eprint.iacr.org/2017/535 [6] https://eprint.iacr.org/2017/848 [7] https://eprint.iacr.org/2017/220 I appreciate any feedback from the group, including any clarifications on anything I have said above but most especially whether or not you think this is a good item for the group to work on. --=20 Tony Arcieri --94eb2c0cfe06a926bf055d7b3209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am considering writing = an I-D for AES-PMAC-SIV: a fully parallelizable misuse resistant AES mode b= ased on generic composition, combining AES-CTR in SIV mode (ala RFC 5297) b= ut substituting AES-PMAC[1] for AES-CMAC. All constructions I just named, a= side from "AES-PMAC-SIV" itself, were originally designed by Phil= Rogaway, who also suggested substituting PMAC for CMAC to me in the first = place. I wrote a blog post about a set of 5 libraries I have written implem= enting the construction here:

https://tonyarcieri.com/introducing-miscr= eant-a-multi-language-misuse-resistant-encryption-library

# Why?

There are a number of othe= r misuse resistant schemes available, including the (hopefully) nearly fina= lized work on AES-GCM-SIV being done through this group, and a misuse resis= tant scheme is almost certainly going to be part of the CAESAR portfolio. S= o why AES-PMAC-SIV? What makes it unique?

AES-PMA= C-SIV is, to my knowledge, the simplest fully parallelizable misuse resista= nt scheme, particularly applicable to environments that require small code = size, have hardware accelerated AES, but do not have the analogue of a CLMU= L instruction. Embedded and "Internet of Things" devices often fa= ll into this category, with AES acceleration exceedingly common but CLMUL-s= tyle instructions generally only available on smartphone-class devices or x= 86 desktops/laptops/servers.

For this reason we s= ee a similar split in AES-GCM versus AES-CCM adoption. The latter is genera= lly preferred in the sort of embedded environments I am referencing due to = these restrictions. I think it would be nice to have an "IoT friendly&= quot; misuse resistant scheme.

"IoT" se= ems like an area which could greatly benefit from misuse resistance, as the= se devices often have limited/poor random number generation capability, so = a nonce-based misuse resistant scheme would provide an additional layer of = defense in the event of catastrophic RNG failures.

# Properties

AES-PMAC-SIV is a two-pass offline= mode of AES which provides misuse resistant authenticated encryption (MRAE= ) and supports fully parallel implementations.

Traditionally using a 2= -pass mode might be considered a blocker for IoT use cases, as devices in t= his class may generally be rather starved of RAM and unable to hold large m= essages for a two-pass encryption process. This is a valid concern, and one= I think can be addressed in a provably secure manner by employing the CHAI= N and/or STREAM constructions[2] to transform AES-PMAC-SIV (or other authen= ticated modes) into an online mode. STREAM in particular is very simple and= easy to implement. Specifying these schemes is arguably out-of-scope for a= n AES-PMAC-SIV RFC, however.

# Performance

A naiv= e Rust implementation of AES-PMAC-SIV performs* at ~2.4 cycles/byte for 16k= B messages on a 3.1GHz i7.

According to Rogaway, an ide= al assembly implementation should perform at ~1.25 cycles/byte. I believe t= his is approximately half the speed of AES-GCM-SIV (AES-PMAC-SIV needs to r= un the AES function twice as often), although I have been having trouble fi= nding implementations of the AES-GCM-SIV draft to benchmark against.

*NOTE: Rough measurements, turbo boost not disabled, more = due diligence required for a more accurate figure

= # Security

The security proofs for AES-SIV rely on= AES-CMAC being a secure PRF. As AES-PMAC is also a secure PRF, the proofs = also hold for it as well.

I asked Rogaway for some= more specifics on this and whether the proofs of AES-SIV's security an= d security bounds hold for PMAC as well as they do with CMAC. Here's wh= at he had to say:

"The proof in the SIV paper= uses generic properties of the SIV construction: you can stick in any prov= ably-sound PRF. Quantitative results will depend on the quality of the PRF,= but in the case of CMAC and PMAC, the =E2=80=98basic=E2=80=99 bounds are t= he same (within a small constant). I remember there being somewhat improved= bounds for PMAC, like [Nandi, Mandal 2007], but by the time you throw in C= TR, it probably doesn=E2=80=99t help. So, yes, effectively equivalent, as f= ar as I know."

I think this area could wa= rrant some further study. If you're an academic cryptographer who is in= terested in studying (and potentially writing a paper about) AES-PMAC-SIV, = please let me know.

# IPR

The IPR status of the underl= ying AES-SIV construction is covered in RFC 5297: there are no IPR concerns= .

Regarding PMAC specifically, it was originally patented by Phil Ro= gaway, but he has since abandoned his patents. A statement to this effect f= rom Rogaway can be found in the PMAC FAQ[3]:

"I abandoned all p= atent filings pertaining to PMAC many years ago. As far as I know, there is= no IP relevant to using PMAC =E2=80=94 nothing owned by me or by anyone el= se."

# Other MRAE Constructions

There = are a number of newer constructions which are a variation in the same ideas= as AES-PMAC-SIV and its component parts, such as SIVx / PMAC2x[4], ZMAC / = ZAE[5], and 1k-PMAC_Plus[6], which try to attain higher security bounds i.e= . Beyond Birthday Bound (BBB) security. In discussing these schemes with th= e chairs we agreed that the perhaps the main reason AES-PMAC-SIV is so attr= active is because it's so simple and boring, with well-understood secur= ity properties and well-scrutinized component parts that have been around f= or over a decade and the basis of much cryptography research.
Newer schemes may seem alluring but may not actually achieve th= eir stated goals[7].

Several of the round 3 CAESAR= candidates are MRAE, including some of Rogaway's latest work: AEZ. How= ever these candidates are generally optimizing for performance and interest= ing security properties as opposed to simplicity of implementation and mini= mal code size. If you feel there's a candidate I've overlooked with= similar properties please let me know.

AES-GCM-SI= V is quite interesting but has a more complex implementation requiring CLMU= L-style acceleration and lower security bounds (2^32 due to GCM, as opposed= to 2^64 AES birthday bound for AES-PMAC-SIV). As I mentioned earlier, GCM = has previously been a no-go in the embedded space for lack of CLMUL-like in= structions.

# Status

I have announce= d a set of libraries implementing this construction in several languages (s= ee link at the top), however there is not yet widespread usage of this cons= truction in the "running code" sense of "rough consensus and= running code". In addition to writing a draft I'd like to encoura= ge some organic usage, particularly in the IoT space, and get feedback as t= o how well this scheme works in the real world.

[1]=C2=A0http://w= eb.cs.ucdavis.edu/~rogaway/ocb/pmac.pdf
[2]=C2=A0http://we= b.cs.ucdavis.edu/~rogaway/papers/oae.pdf
[3]=C2=A0http:/= /web.cs.ucdavis.edu/~rogaway/ocb/pmac-bak.htm
[4]=C2=A0<= a href=3D"https://eprint.iacr.org/2016/1174" target=3D"_blank">https://epri= nt.iacr.org/2016/1174
[7]=C2= =A0https://e= print.iacr.org/2017/220

I appreciate any feedback from the = group, including any clarifications on anything I have said above but most = especially whether or not you think this is a good item for the group to wo= rk on.

--
Tony= Arcieri
--94eb2c0cfe06a926bf055d7b3209-- From nobody Wed Nov 8 08:58:36 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 B6527128C9C for ; Wed, 8 Nov 2017 08:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mAIRZQnfqkwM for ; Wed, 8 Nov 2017 08:58:33 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 923E0128C81 for ; Wed, 8 Nov 2017 08:58:33 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id 1so4175248qtn.3 for ; Wed, 08 Nov 2017 08:58:33 -0800 (PST) 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=lebrGZP0JaSUoR8/GhCgqB4gGGYlq3iDXDbVJzyIGUY=; b=WNGUO+Y3jD9Re6cDTT/c9llxPDWr6AzXixgsCqz3yamIeTgDgOjM9CiWkjkIiOSQkk f6D6RkTdfHKWkMNJF3HiNeplwBfdBEfwPPP36mczINN77M6/5iuMnF/VEdjnLS9mnpyc vpustO0TgNPTGes4FoJuUf+c8nwiErFPt0QpI8KkcZCKebwg0AoxryHzVDd8R5DZd59S b8vTAqOUIwKsH+LpYItETLBku9AG9dn6WlWZsX22X4P4vnTB1fWXbfOJdZAFxxzeBtJN USytcvdgXiqIN/RuPX6+smvyW4rPH6RYoGqXwWmLJt709unuRbikRbCrD6LJpCMtbRZ/ DJNw== 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=lebrGZP0JaSUoR8/GhCgqB4gGGYlq3iDXDbVJzyIGUY=; b=QN0qOrjCbim6BZ3Odv+ib920QttWbuJU509Js6ZFTXAyPQFhxNoQfZYRLVwEtTb/rB E8NH+3IXA+jEAaQ9HRcn3otxcnx/233wn7gnW50NQQexdsCoSyBlN+KyGr86ydArI2F1 duxsCT1ekHVfYW9hQ/IJkYicPWxiFlhT0mujXNBkGdS3i+rB0LzJ2TyBx1QXygI2uU1g DrfrF0ZK7+GnOO8sNUZC+Sc87zb6q9K6igmq4+u58dwhquaYxw2R4rPHCMDk9s1THgRQ qAjSlSCXCIMCTaVPSTT4AIRneXSoKrcfHRGcrnVe/jwWS72wWYOUcANuNz/DjAd/f5st SBKA== X-Gm-Message-State: AJaThX6Jw3FAa+WlxjAWancboBYkmcYvwT5uUoOpQePBNrUxFYZDfaor Sn3E5ZYUhJPqauPNUULztz7g8RpLX4eDKLZsyiA= X-Google-Smtp-Source: ABhQp+RvDfViRGpY62jzOZpCHvaP3fW6Ya5ezzP90VW6tw0hCv1r9adwdSXm7lzch/t7ii/uZ5Mcp8zVpbraSKi0MlQ= X-Received: by 10.200.41.90 with SMTP id z26mr1786203qtz.47.1510160312417; Wed, 08 Nov 2017 08:58:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.58.103 with HTTP; Wed, 8 Nov 2017 08:58:32 -0800 (PST) From: Peter Alexander Date: Wed, 8 Nov 2017 11:58:32 -0500 Message-ID: To: cfrg@irtf.org Content-Type: multipart/alternative; boundary="001a1146e7b2f9c636055d7b982d" Archived-At: Subject: Re: [Cfrg] Review of draft-irtf-cfrg-re-keying-08 (Peter Alexander) 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, 08 Nov 2017 16:58:35 -0000 --001a1146e7b2f9c636055d7b982d Content-Type: text/plain; charset="UTF-8" Stanislav, Thank you for compiling the summary. I look forward to working with you, and the rest of the team on improvements that can be made. Cheers, Peter --001a1146e7b2f9c636055d7b982d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stanislav,=C2=A0

Thank you for compilin= g the summary. I look forward to working with you, and the rest of the team= on improvements that can be made.

Cheers,=C2=A0

Peter
--001a1146e7b2f9c636055d7b982d-- From nobody Wed Nov 8 10:29:50 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 F3C631295A0 for ; Wed, 8 Nov 2017 10:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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=google.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 LD0kBuOAWjaJ for ; Wed, 8 Nov 2017 10:29:45 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 BDBA41294F0 for ; Wed, 8 Nov 2017 10:29:45 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id h70so6973564ioi.4 for ; Wed, 08 Nov 2017 10:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/xXbxwzZmYZVab0sxqNFjziF0MAmaMquP+tbu4z3O58=; b=DJr1pSpqtywxQwKS8y1rLM1wsNSFwO5zisAIDdgSb3xrr8vvchYzzL17ACnC7B5UlJ 9zfuQEly2Lr1hDAAQ10HrumMxJuXwiOC55ImvBl0J++qtNOjISx/D0p4Ye/94viRzrVC yNwQQkCfJgbWsoO+KYDD1/2K3f8wkDL/5fgtFWEkSKEx96OYMMW4Pi+7xT7q0CJPlLa8 bqbFd6Wd2B+FVAA9tm3nr1lW6ger72JG65755Xmdn6BpkRSPSsnlcFBIN3/8We2YFENa ZZZMdwkVzR7wurOQE85kLB88lN1fk0FVtjSPj4Kr8J++n8/glwC0hn7nKljUpnANCbhm E5ww== 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=/xXbxwzZmYZVab0sxqNFjziF0MAmaMquP+tbu4z3O58=; b=ElUQ3kFS5MeyN6nK0CvXfTarsgeGItLbUC8aLlikhzAAjfaMks0Uza7emhflqxaT+Y KQdQwur43J5WsmDIAPGvJ0aipuGvs+TezFSTBLw8gdq3iXbO12x6PwsSdpOMWjxGo6Kw N+wv5LHBBsvoUR5a2QpZtc4JtGMuoH1EvuUjXiNcOq4/WL7FHuhRXqn2f2PyG8HPsyeU TfN8ngUrZg3XvvZQ8eRpAbanaN+XFNgg62csladjnHkEO8gpLPjl8GV9d2IhwmJttwOZ UzpqrDzPl9/XNifutOih8NxV5VOBaD0NMoHUAodXzn6hj6y6dcqw44rlCTiXHq7GMI/o mYGw== X-Gm-Message-State: AJaThX5gRSf+Wq8z4Hwpn8k/88zZ0JnKwAypvU9paKcbwMeQWAUHcHGj grhO1s3Y7qlEqfrAYXllP4TUE5KVvW/XfjDKkVVnQg== X-Google-Smtp-Source: ABhQp+QpFj1Gmm6/eioyJ4av6ug4E+oW0n9pr4eKnecQPpYCQJ5v4cIXiZpoK8ZyqbZAwADqAgkWLK2JgtzQFHlq/Nk= X-Received: by 10.107.88.19 with SMTP id m19mr2002322iob.166.1510165784383; Wed, 08 Nov 2017 10:29:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.155.131 with HTTP; Wed, 8 Nov 2017 10:29:43 -0800 (PST) In-Reply-To: References: From: Daniel Bleichenbacher Date: Wed, 8 Nov 2017 19:29:43 +0100 Message-ID: To: Tony Arcieri Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="f403043cd170224d5d055d7cdfb0" Archived-At: Subject: Re: [Cfrg] AES-PMAC-SIV 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, 08 Nov 2017 18:29:49 -0000 --f403043cd170224d5d055d7cdfb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Security in a multi user setting might be worth some thoughts. The paper "Another Look at Tightness" by Chatterjee, Menezes and Sarkar, SAC 2011 https://www.math.uwaterloo.ca/~ajmeneze/publications/tightness.pdf has an attack against SIV in a multi-user setting in section 5.1. In particular, if one wants to achieve 128 bit security in such a setting then it seems necessary to use a larger PMAC key. On Wed, Nov 8, 2017 at 5:29 PM, Tony Arcieri wrote: > I am considering writing an I-D for AES-PMAC-SIV: a fully parallelizable > misuse resistant AES mode based on generic composition, combining AES-CTR > in SIV mode (ala RFC 5297) but substituting AES-PMAC[1] for AES-CMAC. All > constructions I just named, aside from "AES-PMAC-SIV" itself, were > originally designed by Phil Rogaway, who also suggested substituting PMAC > for CMAC to me in the first place. I wrote a blog post about a set of 5 > libraries I have written implementing the construction here: > > https://tonyarcieri.com/introducing-miscreant-a-multi-langua > ge-misuse-resistant-encryption-library > > # Why? > > There are a number of other misuse resistant schemes available, including > the (hopefully) nearly finalized work on AES-GCM-SIV being done through > this group, and a misuse resistant scheme is almost certainly going to be > part of the CAESAR portfolio. So why AES-PMAC-SIV? What makes it unique? > > AES-PMAC-SIV is, to my knowledge, the simplest fully parallelizable misus= e > resistant scheme, particularly applicable to environments that require > small code size, have hardware accelerated AES, but do not have the > analogue of a CLMUL instruction. Embedded and "Internet of Things" device= s > often fall into this category, with AES acceleration exceedingly common b= ut > CLMUL-style instructions generally only available on smartphone-class > devices or x86 desktops/laptops/servers. > > For this reason we see a similar split in AES-GCM versus AES-CCM adoption= . > The latter is generally preferred in the sort of embedded environments I = am > referencing due to these restrictions. I think it would be nice to have a= n > "IoT friendly" misuse resistant scheme. > > "IoT" seems like an area which could greatly benefit from misuse > resistance, as these devices often have limited/poor random number > generation capability, so a nonce-based misuse resistant scheme would > provide an additional layer of defense in the event of catastrophic RNG > failures. > > # Properties > > AES-PMAC-SIV is a two-pass offline mode of AES which provides misuse > resistant authenticated encryption (MRAE) and supports fully parallel > implementations. > > Traditionally using a 2-pass mode might be considered a blocker for IoT > use cases, as devices in this class may generally be rather starved of RA= M > and unable to hold large messages for a two-pass encryption process. This > is a valid concern, and one I think can be addressed in a provably secure > manner by employing the CHAIN and/or STREAM constructions[2] to transform > AES-PMAC-SIV (or other authenticated modes) into an online mode. STREAM i= n > particular is very simple and easy to implement. Specifying these schemes > is arguably out-of-scope for an AES-PMAC-SIV RFC, however. > > # Performance > > A naive Rust implementation of AES-PMAC-SIV performs* at ~2.4 cycles/byte > for 16kB messages on a 3.1GHz i7. > > According to Rogaway, an ideal assembly implementation should perform at > ~1.25 cycles/byte. I believe this is approximately half the speed of > AES-GCM-SIV (AES-PMAC-SIV needs to run the AES function twice as often), > although I have been having trouble finding implementations of the > AES-GCM-SIV draft to benchmark against. > > *NOTE: Rough measurements, turbo boost not disabled, more due diligence > required for a more accurate figure > > # Security > > The security proofs for AES-SIV rely on AES-CMAC being a secure PRF. As > AES-PMAC is also a secure PRF, the proofs also hold for it as well. > > I asked Rogaway for some more specifics on this and whether the proofs of > AES-SIV's security and security bounds hold for PMAC as well as they do > with CMAC. Here's what he had to say: > > "The proof in the SIV paper uses generic properties of the SIV > construction: you can stick in any provably-sound PRF. Quantitative resul= ts > will depend on the quality of the PRF, but in the case of CMAC and PMAC, > the =E2=80=98basic=E2=80=99 bounds are the same (within a small constant)= . I remember there > being somewhat improved bounds for PMAC, like [Nandi, Mandal 2007], but b= y > the time you throw in CTR, it probably doesn=E2=80=99t help. So, yes, eff= ectively > equivalent, as far as I know." > > I think this area could warrant some further study. If you're an academic > cryptographer who is interested in studying (and potentially writing a > paper about) AES-PMAC-SIV, please let me know. > > # IPR > > The IPR status of the underlying AES-SIV construction is covered in RFC > 5297: there are no IPR concerns. > > Regarding PMAC specifically, it was originally patented by Phil Rogaway, > but he has since abandoned his patents. A statement to this effect from > Rogaway can be found in the PMAC FAQ[3]: > > "I abandoned all patent filings pertaining to PMAC many years ago. As far > as I know, there is no IP relevant to using PMAC =E2=80=94 nothing owned = by me or > by anyone else." > > # Other MRAE Constructions > > There are a number of newer constructions which are a variation in the > same ideas as AES-PMAC-SIV and its component parts, such as SIVx / > PMAC2x[4], ZMAC / ZAE[5], and 1k-PMAC_Plus[6], which try to attain higher > security bounds i.e. Beyond Birthday Bound (BBB) security. In discussing > these schemes with the chairs we agreed that the perhaps the main reason > AES-PMAC-SIV is so attractive is because it's so simple and boring, with > well-understood security properties and well-scrutinized component parts > that have been around for over a decade and the basis of much cryptograph= y > research. > > Newer schemes may seem alluring but may not actually achieve their stated > goals[7]. > > Several of the round 3 CAESAR candidates are MRAE, including some of > Rogaway's latest work: AEZ. However these candidates are generally > optimizing for performance and interesting security properties as opposed > to simplicity of implementation and minimal code size. If you feel there'= s > a candidate I've overlooked with similar properties please let me know. > > AES-GCM-SIV is quite interesting but has a more complex implementation > requiring CLMUL-style acceleration and lower security bounds (2^32 due to > GCM, as opposed to 2^64 AES birthday bound for AES-PMAC-SIV). As I > mentioned earlier, GCM has previously been a no-go in the embedded space > for lack of CLMUL-like instructions. > > # Status > > I have announced a set of libraries implementing this construction in > several languages (see link at the top), however there is not yet > widespread usage of this construction in the "running code" sense of "rou= gh > consensus and running code". In addition to writing a draft I'd like to > encourage some organic usage, particularly in the IoT space, and get > feedback as to how well this scheme works in the real world. > > [1] http://web.cs.ucdavis.edu/~rogaway/ocb/pmac.pdf > [2] http://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf > [3] http://web.cs.ucdavis.edu/~rogaway/ocb/pmac-bak.htm > [4] https://eprint.iacr.org/2016/1174 > [5] https://eprint.iacr.org/2017/535 > [6] https://eprint.iacr.org/2017/848 > [7] https://eprint.iacr.org/2017/220 > > I appreciate any feedback from the group, including any clarifications on > anything I have said above but most especially whether or not you think > this is a good item for the group to work on. > > -- > Tony Arcieri > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --f403043cd170224d5d055d7cdfb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Security in a multi user setting might be worth some = thoughts.
The paper "Another Look at Tightness" by Chat= terjee, Menezes and Sarkar, SAC 2011
has an attack agai= nst SIV in a multi-user setting in section 5.1.
In particular, if= one wants to achieve 128 bit security in such a setting then
it = seems necessary to use a larger PMAC key.



On Wed, Nov 8, 2017 = at 5:29 PM, Tony Arcieri <bascule@gmail.com> wrote:
I am considering writing an I-D for AES-PMAC-SIV: a fully parallelizable m= isuse resistant AES mode based on generic composition, combining AES-CTR in= SIV mode (ala RFC 5297) but substituting AES-PMAC[1] for AES-CMAC. All con= structions I just named, aside from "AES-PMAC-SIV" itself, were o= riginally designed by Phil Rogaway, who also suggested substituting PMAC fo= r CMAC to me in the first place. I wrote a blog post about a set of 5 libra= ries I have written implementing the construction here:

https://tonyarcieri.= com/introducing-miscreant-a-multi-language-misuse-resistant-encry= ption-library

# Why?

= There are a number of other misuse resistant schemes available, including t= he (hopefully) nearly finalized work on AES-GCM-SIV being done through this= group, and a misuse resistant scheme is almost certainly going to be part = of the CAESAR portfolio. So why AES-PMAC-SIV? What makes it unique?<= br style=3D"font-size:12.8px">
AES-PMAC-SIV is, to my knowledge, the simplest fully par= allelizable misuse resistant scheme, particularly applicable to environment= s that require small code size, have hardware accelerated AES, but do not h= ave the analogue of a CLMUL instruction. Embedded and "Internet of Thi= ngs" devices often fall into this category, with AES acceleration exce= edingly common but CLMUL-style instructions generally only available on sma= rtphone-class devices or x86 desktops/laptops/servers.

For this reason we see a similar split in AES-GCM versus AES-CCM adop= tion. The latter is generally preferred in the sort of embedded environment= s I am referencing due to these restrictions. I think it would be nice to h= ave an "IoT friendly" misuse resistant scheme.

"IoT" seems like an area which could greatly benefit from= misuse resistance, as these devices often have limited/poor random number = generation capability, so a nonce-based misuse resistant scheme would provi= de an additional layer of defense in the event of catastrophic RNG failures= .

# Properties

AES-PMAC= -SIV is a two-pass offline mode of AES which provides misuse resistant auth= enticated encryption (MRAE) and supports fully parallel implementations.

Traditionally using a 2-pass mode might be considered a blocker for IoT = use cases, as devices in this class may generally be rather starved of RAM = and unable to hold large messages for a two-pass encryption process. This i= s a valid concern, and one I think can be addressed in a provably secure ma= nner by employing the CHAIN and/or STREAM constructions[2] to transform AES= -PMAC-SIV (or other authenticated modes) into an online mode. STREAM in par= ticular is very simple and easy to implement. Specifying these schemes is a= rguably out-of-scope for an AES-PMAC-SIV RFC, however.

# Performance=

A naive Rust implementation of AES-PMAC-SIV performs* a= t ~2.4 cycles/byte for 16kB messages on a 3.1GHz i7.

Ac= cording to Rogaway, an ideal assembly implementation should perform at ~1.2= 5 cycles/byte. I believe this is approximately half the speed of AES-GCM-SI= V (AES-PMAC-SIV needs to run the AES function twice as often), although I h= ave been having trouble finding implementations of the AES-GCM-SIV draft to= benchmark against.

*NOTE: Rough measurements, turbo= boost not disabled, more due diligence required for a more accurate figure=

# Security

The security = proofs for AES-SIV rely on AES-CMAC being a secure PRF. As AES-PMAC is also= a secure PRF, the proofs also hold for it as well.

I asked Rogaway for some more specifics on this and whether the proofs of= AES-SIV's security and security bounds hold for PMAC as well as they d= o with CMAC. Here's what he had to say:

"= The proof in the SIV paper uses generic properties of the SIV construction:= you can stick in any provably-sound PRF. Quantitative results will depend = on the quality of the PRF, but in the case of CMAC and PMAC, the =E2=80=98b= asic=E2=80=99 bounds are the same (within a small constant). I remember the= re being somewhat improved bounds for PMAC, like [Nandi, Mandal 2007], but = by the time you throw in CTR, it probably doesn=E2=80=99t help. So, yes, ef= fectively equivalent, as far as I know."

= I think this area could warrant some further study. If you're an academ= ic cryptographer who is interested in studying (and potentially writing a p= aper about) AES-PMAC-SIV, please let me know.

# IPR

Th= e IPR status of the underlying AES-SIV construction is covered in RFC 5297:= there are no IPR concerns.

Regarding PMAC specifically, it was orig= inally patented by Phil Rogaway, but he has since abandoned his patents. A = statement to this effect from Rogaway can be found in the PMAC FAQ[3]:
<= br>"I abandoned all patent filings pertaining to PMAC many years ago. = As far as I know, there is no IP relevant to using PMAC =E2=80=94 nothing o= wned by me or by anyone else."

# Other MRAE Constructions
=

There are a number of newer constructions which are a v= ariation in the same ideas as AES-PMAC-SIV and its component parts, such as= SIVx / PMAC2x[4], ZMAC / ZAE[5], and 1k-PMAC_Plus[6], which try to attain = higher security bounds i.e. Beyond Birthday Bound (BBB) security. In discus= sing these schemes with the chairs we agreed that the perhaps the main reas= on AES-PMAC-SIV is so attractive is because it's so simple and boring, = with well-understood security properties and well-scrutinized component par= ts that have been around for over a decade and the basis of much cryptograp= hy research.

Newer schemes may seem alluring but m= ay not actually achieve their stated goals[7].

Sev= eral of the round 3 CAESAR candidates are MRAE, including some of Rogaway&#= 39;s latest work: AEZ. However these candidates are generally optimizing fo= r performance and interesting security properties as opposed to simplicity = of implementation and minimal code size. If you feel there's a candidat= e I've overlooked with similar properties please let me know.

AES-GCM-SIV is quite interesting but has a more complex imp= lementation requiring CLMUL-style acceleration and lower security bounds (2= ^32 due to GCM, as opposed to 2^64 AES birthday bound for AES-PMAC-SIV). As= I mentioned earlier, GCM has previously been a no-go in the embedded space= for lack of CLMUL-like instructions.

# Status

=
I have announced a set of libraries implementing this constructi= on in several languages (see link at the top), however there is not yet wid= espread usage of this construction in the "running code" sense of= "rough consensus and running code". In addition to writing a dra= ft I'd like to encourage some organic usage, particularly in the IoT sp= ace, and get feedback as to how well this scheme works in the real world.
[1]=C2=A0http://web.cs.ucdavis.edu/~rogaway/ocb/pmac.pdf<= br>[2]=C2=A0http://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf=
[3]=C2=A0http://web.cs.ucdavis.edu/~rogaway/ocb/pmac-bak.ht= m
[7]=C2=A0https://eprint.iacr.org/2017/220

I apprec= iate any feedback from the group, including any clarifications on anything = I have said above but most especially whether or not you think this is a go= od item for the group to work on.

--
Tony Arcieri

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


--f403043cd170224d5d055d7cdfb0-- From nobody Wed Nov 8 12:28:51 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47A0129BC5 for ; Wed, 8 Nov 2017 12:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net 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 4HeXzjENg5Em for ; Wed, 8 Nov 2017 12:28:48 -0800 (PST) Received: from homiemail-a23.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A0C129BA0 for ; Wed, 8 Nov 2017 12:28:48 -0800 (PST) Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 6EE144B0063; Wed, 8 Nov 2017 12:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=k0UJhcys9B5HYYTU63aZADyqg18=; b=w2+kPEO2mnoDoO PmBxNfR/7VvfTxKcjVObjWDd1ZfG+FQojQm7SlpoI0BQpbreTDmbBQGHnQuSCW3D hvZSAcAidXwnsQe5XC3INuqHiTHNcss34TWtLTbcLqz4aNSDrHhdN7IFKGmLKXGo wBiFj5O8eczdQwK1SxSHZ47p+OoL4= Received: from [10.0.1.2] (cpe-75-80-147-12.san.res.rr.com [75.80.147.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id E5D5B4B0062; Wed, 8 Nov 2017 12:28:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Greg Rose In-Reply-To: Date: Wed, 8 Nov 2017 12:28:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E7519DE-DB3C-4671-AC7E-12C966443F60@seer-grog.net> References: <150128095682.20726.13629584340935749844.idtracker@ietfa.amsl.com> To: Cfrg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cfrg] draft-harkins-pkex-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: Wed, 08 Nov 2017 20:28:50 -0000 Here are some comments on the PKEX current draft. I had already sent = most of them to Dan Harkins, he asked me to share with CFRG. At the end of the introduction section, it's worth mentioning that at = the end of the process both parties have also derived a usable shared = symmetric key "z". It doesn't actually say that! 1.2: "Groups can be either traditional finite field or can be based on = elliptic curves." The pedant in me wants to say something like "the = multiplicative group of a finite field or ...". =46rom reading ahead I = now understand that you only intend it to apply to Mod-P groups, so I = would actually say "the multiplicative group of the field of integers = modulo an odd prime." Also perhaps "Other groups are possible but MUST = NOT be used with this specification.", or maybe I'm overstating the = intent. Since there are many possible generators, maybe say "There is a = distinguished generator of the group, denoted G. The order of G is q, = which MUST itself be a large prime (in all the examples below, q is = (P-1)/2)." I suggest adding to "{a}b[c]" description: "The result of this is a = ciphertext that includes authentication information dependent on both a = and c, whether c is actually transmitted or is somehow reconstructed. = The other side can decrypt a if it knows b and neither {a}b nor c has = been altered during transmission, otherwise an error will be flagged." 5: Each party is assumed to know the other's identity in advance; the = protocol doesn't reveal the identities. 5.1 it should be stressed that x and y (the ephemeral secret keys) SHALL = be generated with high quality (pseudo-)randomness and never re-used. 5.1, maybe clarify "verified to be valid"... for elliptic curves M and N = must be valid points (both coordinates) in the group. 5.1, Alice's Q is called Qa, but Bob's is called Qr. I'd prefer it to be = called Qb :-). Actually, in the last paragraph of section 5.1, I believe = that it IS called Qb (before being deleted). 5.2 at end, they also share "z", a high-quality shared secret that could = be used for further key derivation. Is this considered ephemeral or not? = In some contexts it might be extremely useful. Appendix A, regarding validation/generation: - For elliptic curves, given a randomly generated X coordinate, there = will be two possible Y-coordinates (or none). For completeness, should = you specify that one of them should be chosen? While it's astronomically = unlikely, it is possible that a single byte counter would wrap without = ever finding a candidate. - You write "for FFC it is checked by seeing whether the exponentiation = of the candidate to the power of the prime minus one divided by the = order, modulo the prime, is one)." I find it unclear what you mean by = "divided by the order" here. I guess you must mean "divided by the order = of the generator G" as opposed to the group order? In the case of all = the primes you use, that means x^((P-1)/2), but you're allowing for the = use of other kinds of moduli, like the el-Gamal style, right? Having = said all this, I think the clarification should be done up in the = Notation section, after the first paragraph. Can I suggest the following = words: "It is important that public and secret keys be validated, that is that = they represent valid elements of the group. For elliptic curve groups, a = point is valid if the coordinates are both less than the field modulus = and they jointly satisfy the curve equation. For a randomly generated X = coordinate, there might not be any corresponding Y coordinate, otherwise = there will be two; in this case we choose the numerically smaller (mod = P) value for the Y coordinate. For Mod-P groups, the generator G usually = has a smaller order than the multiplicative group itself. Groups use a = generator of order q, where q is some large prime divisor of (P-1). In = all the example groups shown, the order of G is q =3D (P-1)/2. It is = important for security that the value X be checked to be in the correct = subgroup, 1 < X < P, and X^q =3D 1 (mod P)." That's all very well for validation, but if you try using the generation = algorithm above with an el-Gamal style group, with a q that's much = smaller than p, it'll almost certainly never terminate. Usually this is = done by generating the random field element then raising it to the power = ((p-1)/q), which will force it to be in the right subgroup (but must = check that you didn't end up with 1). This process will unfortunately = not generate the same values that you already have (and invalidate all = the FFC test vectors :-( ), I don't know how important that might be to = you. Aside: you use the acronyms ECC and FFC extensively but don't define = them. Typos: Appendix A "an candidate". Your address: "avenue" should be capitalized. Those are the comments on the draft as it is proposed. I also want to = make an observation that I think makes the scheme more usable, but = changes the mathematics and would invalidate the test vectors, at least = for the elliptic curve variants. Public keys are points on the specified curve, with (X,Y) coordinates = modulo P, the prime defining the underlying field. =E2=80=9CCompact = form=E2=80=9D, as expressed in RFC 6090, just means transmitting only = the X coordinate. The recipient then verifies the received key, in part = by calculating a corresponding Y coordinate. For Modulo-P underlying = fields, there will be two possible Y coordinates for any valid point (or = none if the X coordinate was invalid). As is noted in RFC 6090, the = result of scalar multiplication on a compact point depends only on the X = coordinate. (Note: this is not generally true for non-Modulo-P fields or = other representations, but does apply to the only ones mentioned here.) Some standards might want to specify the use of compact representation, = that is, only the X coordinate is transmitted for the PKEX protocol = messages themselves. A corresponding Y coordinate must have been = calculated and it can either be saved or recalculated at need. One of = the two Y values can be chosen essentially at random. The two = possibilities are (X,Y) and (X,-Y), and are group inverses of each = other. Focusing on the first message transmitted, here is the problem: 1. Both calculate Qa/Qb as Hash(something identifying the party and = the shared password) * Pi. These are points on the curve. Both sides = will calculate the same points. 2. Alice calculates X, her ephemeral public key, also a point on the = curve. 3. Alice calculates M as X + Qa, again this is a point on the curve. = But in this case, since the operation is point addition and not scalar = multiplication, the Y coordinate matters! 4. Alice transmits M, but in "compact representation", it really = only transmits the X coordinate F(M). 5. Bob receives F(M) (the X coordinate of M) and calculates a = corresponding Y coordinate. With probability 0.5 it might choose a = different Y coordinate than was calculated in step 3. 6. Bob calculates X=E2=80=99 =3D M =E2=80=93 Qi. Again, this is = actually point addition of the inverse of the point Qi. If in step 5 Bob chooses the same Y coordinate that Alice calculated, = everything is fine. But what if Bob chose the other Y coordinate? Q-P =E2=89=A0 -(-P+Q) in general for points P and Q. X=E2=80=99 will not = be equal to X. The same logic applies to the next message from Bob to = Alice. It is important for the PKEX protocol as written that the entire point = (or a compressed point, which disambiguates between the positive and = negative Y values, but this is not the same as compact representation) = to be transmitted. The reason for this discrepancy is that appendix C of = RFC6090 refers only to scalar multiplication of a point, as is used in = ECDH and ECDSA; however PKEX uses addition/subtraction of two different = points in its exchange phase, and then it does matter. Note that there = is nothing wrong with the draft RFC as written; at no time does it = mention compact representation of points, and it is very careful to use = the notation F(B) to denote extraction of the X coordinate. However an alternative is worth considering. With the following change, = less information would need to be transmitted, and an elliptic curve = point addition could be replaced by a simpler and faster modular = addition, while yielding identical security. I believe that with this = change, compact representation (well, something equivalent in size = anyway) could actually be used in PKEX. In step (3) above, one could calculate M as F(X) + F(Qa) (mod P), where = P is the prime defining the underlying field of the elliptic curve. Now = it=E2=80=99s a scalar value taking up the same space as the original = F(M), although it will have a different value so the test vectors need = to change. In step (6), calculate X=E2=80=99 as M =E2=80=93 F(Qa) (mod = P). (Similarly for Bob's response message.) Such a change works for PKEX for either kind of group (since F(.) is the = identity function for the multiplicative mod P groups). Greg. Phone/Signal: +1 619 890 8236=20 GPG/PGP: 1081A37C 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C From nobody Wed Nov 8 13:02:51 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81426129BE9 for ; Wed, 8 Nov 2017 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 n6HaPQhGzIKJ for ; Wed, 8 Nov 2017 13:02:46 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0117.outbound.protection.outlook.com [104.47.1.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592001271DF for ; Wed, 8 Nov 2017 13:02:46 -0800 (PST) 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=uE6f1pet0oDTHzOLJCSl/6lnpFmItUgs9jqo4G/C+JQ=; b=ON3ZYarI/S13dw1m7B+DMsNIsnbZEtHxq4Lwjhlhy0dq3BgSykaRho+KVjtz5LwhZf74EoiqoIXUM2j7fDBGWcuEZwhb594y1X80jh15/tH7OCxEbfshXa1W6VG4J4z5z4duKFO9gOs2SqPnU+gAu3szpmEPzXygrB8BIxn0HxY= 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.197.13; Wed, 8 Nov 2017 21:02:43 +0000 Received: from VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b]) by VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b%13]) with mapi id 15.20.0197.022; Wed, 8 Nov 2017 21:02:43 +0000 From: Yehuda Lindell To: "cfrg@irtf.org" Thread-Topic: [Cfrg] AES-PMAC-SIV Thread-Index: AQHTWNTr1HIrj/yEZk6KtiskCsF1pQ== Date: Wed, 8 Nov 2017 21:02:43 +0000 Message-ID: <3E54E0CC-AE74-4CDC-A499-17219D9E0987@biu.ac.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2a01:6500:a049:624e:45f3:c8f2:81ca:560c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR04MB3021; 6:j/h/+d8cJTj+mvmanpJUBcOKx20koua5PETQ2Iyd2map/9DuSmhUCgPVTYuzntSRRul6cZAQJWQFfPa/2rp/wXN4tq4pb17jzNxHg4iOkQNadEwcsDNdJDDb8KnzxVNu7En4dEfOLOk70gn/CpTt3JVQv0Szm9kTL9UCPVPQckxjHIZCS3bs4O3jMOZLY48QyhfVGPcApuj9SbJ59LyQOfRwPDcp3ewVczm1YUau6mB33+wMADTSkt2fvIdl7iWaQQ/82KDda/wJcdsZekvvnbtfX26v7ao3J9lPAi23bUeYKDFrc9kVdbTovsMPOpDxg+SInmAiee/y1jNxq3XFceniQhOIYBqshsJTqYwwcJA=; 5:/k5+e7OQRkBPws3ULIUGr8UnA4dq40EbF8tlZF9nPuoIXEdB/MieNbqAE7g+wShu+xTUNmZtpmjaTWbwkzLmxyc1UWad4x581kQ3nSfnfO6IjxRUThH4cVEdKcLxdQwNXXA0bCdk3yj0HKjrdYLnNGutPBu1y2iwj1OYbJ07w18=; 24:tvpm0Y0G6PlcEm9rwW+JlU5SqoZLPL2rmVG1fc1A+G7i0JKrh6UevSj0rSHUQ5JTl0ftml8/8PxhrBEHjwphvp58jZZwpMCvwdQUtf2ou0o=; 7:cxb+DazrgXC50+8MRiV7Mp883ew+i7GaJBl55rEnO6gEMxsHBs3MlJau4PSDGrseFGd/TsavzxCz2ImE3e/urgfL/M+JD/aFjqaQkJ0hYJvlqq+MjAvslgqj5cLt8vuNEvx3/xI0WjQchPkm/oTIJZb38HPHn5yxk80fU+RTlsY9SOy8hGIxU3kzu2yxMkeDvDKxH4aCmed0kmWby1ldfXXWli0q93zUp92/GSdy5iE4UGAsEQEk+hMeYQN1yyw1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5a515dd6-92c5-4257-0281-08d526ec0e08 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249)(49563074); 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:(166708455590820)(211171220733660); 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)(100000703101)(100105400095)(93006095)(93001095)(3231021)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(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: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(199003)(189002)(36756003)(2900100001)(74482002)(50986999)(54356999)(99936001)(7736002)(5660300001)(2906002)(230783001)(966005)(3280700002)(3660700001)(42882006)(101416001)(6916009)(74826001)(102836003)(6116002)(14454004)(1730700003)(81166006)(25786009)(8676002)(81156014)(316002)(478600001)(33656002)(68736007)(786003)(2351001)(105586002)(83716003)(8936002)(82746002)(106356001)(72206003)(53936002)(5250100002)(54896002)(236005)(86362001)(6512007)(6306002)(99286004)(6486002)(6506006)(189998001)(5640700003)(2501003)(97736004)(6436002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB3021; H:VI1PR04MB3021.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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=_6B7AD210-1087-4B84-9DD3-82C3C02A1603"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: biu.ac.il X-MS-Exchange-CrossTenant-Network-Message-Id: 5a515dd6-92c5-4257-0281-08d526ec0e08 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 21:02:43.1242 (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: [Cfrg] AES-PMAC-SIV 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, 08 Nov 2017 21:02:49 -0000 --Apple-Mail=_6B7AD210-1087-4B84-9DD3-82C3C02A1603 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA96692B-1EE4-49DA-9C7E-701FBE370358" --Apple-Mail=_AA96692B-1EE4-49DA-9C7E-701FBE370358 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Regarding PMAC-SIV versus AES-GCM-SIV: it may be the case that some = people do not want to implement GMAC based modes on embedded devices; = I=E2=80=99m not sure, and there is some psychology here. In any case, I do not want to relate to the question of standardizing = PMAC-SIV. But, I feel I must respond to some comments made regarding = AES-GCM-SIV, since there are some significant inaccuracies. 1) I don=E2=80=99t know how it can be hard to find implementations of = AES-GCM-SIV to benchmark against. In addition to reporting measurements = in the papers, we have also explicitly referenced both the github AES-NI = implementation at https://github.com/Shay-Gueron/AES-GCM-SIV = , and the BoringSSL = implementation. Note that BoringSSL can be compiled both with AES-NI + = CLMUL and without AES-NI (and CLMUL). So, you can compare easily on = modern x86 processors and also on ARM v7 (which does not have AES-NI and = CLMUL). 2) The statement about bounds is blatantly false. Indeed, AES-SIV has a = birthday limit on the number of blocks. After encrypting 2^64 blocks, = the adversary has an advantage of 1/2. Thus, in order to limit the = adversary=E2=80=99s advantage to 2^-32, you can encrypt at most 2^48 = blocks. In contrast, AES-GCM-SIV comes with BEYOND BIRTHDAY BOUNDS. This = is described explicitly in the AES-GCM-SIV papers. In fact, if the same = nonce is always used, then AES-GCM-SIV has the same bounds as AES-SIV, = but when nonces repeat a bounded amount, AES-GCM-SIV=E2=80=99s bounds = are way beyond AES-SIV. (GCM indeed has a 2^32 bound on the NUMBER OF MESSAGES when using a = random IV, in order to keep the adversary advantage below 2^-32. = However, in the setting with random nonces, AES-GCM-SIV can encrypt 2^48 = messages of length 2^21 each, or 2^64 messages of length 2^13 each, and = still have an adversarial advantage of only 2^-32.) --Apple-Mail=_AA96692B-1EE4-49DA-9C7E-701FBE370358 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Regarding PMAC-SIV versus AES-GCM-SIV: it may = be the case that some people do not want to implement GMAC based = modes on embedded devices; I=E2=80=99m not sure, and there is some = psychology here. 
 
In any = case, I do not want to relate to the question of standardizing = PMAC-SIV. But, I feel I must respond to some comments made = regarding AES-GCM-SIV, since there are some = significant inaccuracies.
 
1) I = don=E2=80=99t know how it can be hard to find implementations of = AES-GCM-SIV to benchmark against. In addition to reporting = measurements in the papers, we have also explicitly referenced = both the github AES-NI implementation at https://github.com/Shay-Gueron/AES-GCM-SIV, and = the BoringSSL implementation. Note that BoringSSL can be compiled both with AES-NI + CLMUL = and without AES-NI (and CLMUL). So, you can compare easily on modern x86 processors and also on = ARM v7 (which does not have AES-NI and CLMUL).
 
2) The statement about bounds is blatantly false. = Indeed, AES-SIV has a birthday limit on the number of blocks. After = encrypting 2^64 blocks, the adversary has an advantage of = 1/2. Thus, in order to limit the adversary=E2=80=99s advantage to = 2^-32, you can encrypt at most 2^48 blocks. In contrast, = AES-GCM-SIV comes with BEYOND BIRTHDAY BOUNDS. This is described = explicitly in the AES-GCM-SIV papers. In fact, if = the same nonce is always used, then AES-GCM-SIV has the same = bounds as AES-SIV, but when nonces repeat a bounded amount, = AES-GCM-SIV=E2=80=99s bounds are way beyond AES-SIV. 
 
(GCM indeed has a 2^32 bound on the = NUMBER OF MESSAGES when using a random IV, in order to keep the = adversary advantage below 2^-32. However, in the setting with = random nonces, AES-GCM-SIV can encrypt 2^48 messages of length 2^21 = each, or 2^64 messages of length 2^13 each, and still have an = adversarial advantage of only 2^-32.)
 

 
= --Apple-Mail=_AA96692B-1EE4-49DA-9C7E-701FBE370358-- --Apple-Mail=_6B7AD210-1087-4B84-9DD3-82C3C02A1603 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/5w4gFAloDcPEACgkQgpgt7E/5 w4gyBA//U0snS2KLmqPMo7KmDQ5r0XHWWy4dIWxf8sNPO3UsMxRHe+wsY5xAzMDB BAEzK27BP4Xp8gMigWSlChOsEt3J76wMBJ0lXJpJxOegUl1wq7Ix0kc9aNUzLhKV DTbgX+a2dXSDoiA2AkkZaq7QGq2hJFTlMuivhZuPMxbqxHuWapAx4yHb6n7rShlR 3MGVQBgk2oM4S9qPMQj3txDxb6r4l4VbY95CeGUwduMuEUiOxGnDzWTFiqpMBq6S u/qK8lTisGo9UPIeanRDoAuDA07MpjMjnEV4rDw4ZxwDzIkqO5V6vmLcSN0uSAPk 9EBe0xqKN/XFiJszWm+1bwNMpC16toVMroEOIsL7dyOJYK+wXm9LLX4XaZ4LylNI Bxw4dSoqKDNLgo3GVlsGnMFSArAT5HRy9Yv0AlQEY+1+uwLkpWCv9WmbWRUGL8IQ Y9EsPmKeul+ACaG5SftwRp1C0i5QnHTCExHHLAWPybhXdR7dmLXYqs/ZLDUHXkQH VDEhKSQO4dh/7lq5gM4z81gnT3LWZf9701UPdG8oDjRpJvA9sM4WCOyCZmWeJNVI 4kUtUCvCjRPqb9SU8mdzF1xDmJmZEegnB2BaPKySNekbP93JkeuNb3gpznsP13jn wNzs0HDJKp3YhvWFgdllxLYaGKjybX+QGDF0R26AgbtOSJ5J1p8= =YLzd -----END PGP SIGNATURE----- --Apple-Mail=_6B7AD210-1087-4B84-9DD3-82C3C02A1603-- From nobody Wed Nov 8 17:29: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 9834E126FB3 for ; Wed, 8 Nov 2017 17:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, 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 fQLr5yVJiCJf for ; Wed, 8 Nov 2017 17:29:40 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E10B126DED for ; Wed, 8 Nov 2017 17:29:40 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id y196so2996862vkc.5 for ; Wed, 08 Nov 2017 17:29:40 -0800 (PST) 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=WUjgYt2UVJwUuxehDGScV54yh32g36p15xHLjXMMjRE=; b=HVee1cDnPonLupGJvwdGXxdDMTaA8DH08PPufsYKK1/INGJeTr/92KXZ9cZ+QcpFVS UuL4aYRWdGlpBwNKO+JNbdQlA9PJYb+Sj7f2SKffomCkpQNGpZkO1VrKPch9JYF5/pz+ 76olMcmNR67zjP8pTdnvRiNLLvQfyW0LNtey+7AMfsWWIV69zOsA0St59IqbQER8AhGJ 9iJFtodlWXuWGm06icGmi0iEFFK4/l5+DGvtkpG6WH2ifO7CdtrUFh1cIv2SlIRP7Yd+ wyQtuXp/e9zIPt73n50tr1clxgsbfUEYpKV6r7K3tKFXM1Jk1dYn5AMCH+T/2UNZI+tt cJjA== 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=WUjgYt2UVJwUuxehDGScV54yh32g36p15xHLjXMMjRE=; b=HHMNBlJ3xMugbIVgidFYaJHM84EqtwzFEA/jkfuFiExXlnBUOV3iJCgfYr/YsNbhnk GlygOcurcGb0necP683WIr+gqQxzzCUad67SP+QkrNm+HCUB+4bIlGW1ZKSVF/+Bktz/ PV8RxAY22B33fNkLKOX61/2z6z0XJA5mJrQVZSM0OVCWmYLPHAT57ktbW4he2BqNixn7 8bYxqn7n5upsPqg+36qP1Hg5eRRH87Cto0R4AL2Ft1rCGI98f1FfKUGfPxwUEb7NvV7r rtLOPa22OhymKfBm6u7bJKo6XDTyjfRst8zB1w8KJIvNQY7BIfwEsxiA3absjTnhJGYl Lf6w== X-Gm-Message-State: AJaThX6x+wcgWvAG95VpMWohC1GJHjVpwvufdvjgE66pFy6YjsEBjSEb SRwhR3b0zE/9R7kjJAOI/I2izyb49XISCv4njlc= X-Google-Smtp-Source: ABhQp+SC4ZXmPWj0M5tTdDbG79BM2KHSmhk3RV2IzOCjXlrU6sId/Pvw276KItGu5yd1f7WzNGr3iZT7kK0eR55g8yg= X-Received: by 10.31.3.98 with SMTP id 95mr1954663vkd.82.1510190979411; Wed, 08 Nov 2017 17:29:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.14.199 with HTTP; Wed, 8 Nov 2017 17:29:18 -0800 (PST) In-Reply-To: <3E54E0CC-AE74-4CDC-A499-17219D9E0987@biu.ac.il> References: <3E54E0CC-AE74-4CDC-A499-17219D9E0987@biu.ac.il> From: Tony Arcieri Date: Wed, 8 Nov 2017 17:29:18 -0800 Message-ID: To: Yehuda Lindell Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a1142870edef461055d82bc62" Archived-At: Subject: Re: [Cfrg] AES-PMAC-SIV 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, 09 Nov 2017 01:29:42 -0000 --001a1142870edef461055d82bc62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2017 at 1:02 PM, Yehuda Lindell wrote: > 1) I don=E2=80=99t know how it can be hard to find implementations of AES= -GCM-SIV > to benchmark against. In addition to reporting measurements in the papers= , > we have also explicitly referenced both the github AES-NI implementation = at > https://github.com/Shay-Gueron/AES-GCM-SIV, and the BoringSSL > implementation. Note that BoringSSL can be compiled both with AES-NI + > CLMUL and without AES-NI (and CLMUL). So, you can compare easily on > modern x86 processors and also on ARM v7 (which does not have AES-NI and > CLMUL). > Thank you. I'm not sure how I didn't find this. I assure you I looked! > 2) The statement about bounds is blatantly false. Indeed, AES-SIV has a > birthday limit on the number of blocks. After encrypting 2^64 blocks, the > adversary has an advantage of 1/2. Thus, in order to limit the adversary= =E2=80=99s > advantage to 2^-32, you can encrypt at most 2^48 blocks. In contrast, > AES-GCM-SIV comes with BEYOND BIRTHDAY BOUNDS. This is described explicit= ly > in the AES-GCM-SIV papers. In fact, if the same nonce is always used, the= n > AES-GCM-SIV has the same bounds as AES-SIV, but when nonces repeat a > bounded amount, AES-GCM-SIV=E2=80=99s bounds are way beyond AES-SIV. > The specific bounds I am referring to are the ones referred to in section 9 (Security Considerations) of draft-irtf-cfrg-gcmsiv-06: If the nonce is fixed then AES-GCM-SIV acts like AES-GCM with a random > nonce, with the caveat that identical plaintexts will produce identical > ciphertexts. However, we feel that the 2^32 limit for AES- GCM is too ris= ky > in a multi-key setting. Thus with AES-GCM-SIV we recommend that, for a > specific key, a nonce not be repeated more than 2^8 times. I apologize if this is a mischaracterization. I actually asked a number of people about this particular bound prior to posting, and at one point was of the opinion I shouldn't even mention it. I would definitely appreciate any clarifications you can provide to these bounds and how these relate to the corresponding ones in AES-SIV. --=20 Tony Arcieri --001a1142870edef461055d82bc62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 8, 2017 at 1:02 PM, Yehuda Lindell <Yehuda.Lindell@biu.ac.i= l> wrote:
1) I = don=E2=80=99t know how it can=C2=A0be hard to find implementations of AES-G= CM-SIV to benchmark against. In addition=C2=A0to reporting measurements in = the=C2=A0papers, we have also explicitly referenced both=C2=A0the github AE= S-NI implementation at=C2=A0https://github.com/Shay-Gueron/AES-GCM-SIV, and the= =C2=A0BoringSSL implementation. Note that<= /span>=C2=A0BoringSSL can be compiled both = with AES-NI + CLMUL and without AES-NI (and=C2=A0CLMUL). So, you can=C2=A0compare easily on modern x86 processors and also on ARM v7=C2=A0(which does not have AES-NI and CLMUL).

The specific bounds I am referring to are= the ones referred to in section 9 (Security Considerations) of=C2=A0draft-= irtf-cfrg-gcmsiv-06:

If the nonce is fixed then AES-GCM-SI= V acts like AES-GCM with a random nonce, with the caveat that identical pla= intexts will produce identical ciphertexts. However, we feel that the 2^32 = limit for AES- GCM is too risky in a multi-key setting. Thus with AES-GCM-S= IV we recommend that, for a specific key, a nonce not be repeated more than= 2^8 times.


--
Tony Arcier= i
--001a1142870edef461055d82bc62-- From nobody Thu Nov 9 00:54:11 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3DC12ECB1 for ; Thu, 9 Nov 2017 00:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rNFXeN9aNR6v for ; Thu, 9 Nov 2017 00:54:06 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10139.outbound.protection.outlook.com [40.107.1.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4856A12ECB0 for ; Thu, 9 Nov 2017 00:54:04 -0800 (PST) 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=056ZpQTZ8/jOHAwQq+uVREhPDdYi1wM3rD1hqZbwX18=; b=jzKlPq1+mJ7jsejABn+b9I/zm/sjOBjGFg8LqFLxAIuMJ+Kml/HefqoFYL1u/HaIbNfTTcOrtfV0cy5Aqx7/iSA73B12cHHFTcJUbVVNprGqYDgU50PXDWBhw3NlZRaUtMvNAe01xlafHYSkQJaFpb9gFcv/V3+ekx0h/ykVhhw= Received: from VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) by VI1PR04MB3024.eurprd04.prod.outlook.com (10.170.228.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Thu, 9 Nov 2017 08:54:01 +0000 Received: from VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b]) by VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b%13]) with mapi id 15.20.0218.011; Thu, 9 Nov 2017 08:54:01 +0000 From: Yehuda Lindell To: Tony Arcieri CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] AES-PMAC-SIV Thread-Index: AQHTWNTrWV+54hA9UE+Txk/NBDiCS6MLQqgAgAB8PoA= Date: Thu, 9 Nov 2017 08:54:01 +0000 Message-ID: <36353EBA-9639-46C7-96E7-34635E4F37BB@biu.ac.il> References: <3E54E0CC-AE74-4CDC-A499-17219D9E0987@biu.ac.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yehuda.Lindell@biu.ac.il; x-originating-ip: [132.71.147.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR04MB3024; 6:mHvysPe6+2wm5SpyJW2lg8dcwZ7xjEro8c4lzvgA2Tkpw7FSS8tiaJKEZiXBbo9PL2ucoCNETyY0FZW14DvVlOIwuwJPB/7k3PMrJhTjbwfkwqGqloMQidQfu8trwbEhQL+HCeebqwXNZKnwBAgEQEa4m0s5KMyWEn/eT+woWwPdx9GUPArqDElT0miscaU0NdeidXBoOp2souLfi1uhCbYNLru7fFBdrAb0Wi9KswoSMJds7oByMpJPXLy0yGnXfiU7Wvr+FXTXfffFlPDNOXazpYPIbXq2T9ckvhTYzFEczetLwyPOXAj6uCnE+Kc1NVikPcvFzScKqA2g0CmcYvrXiuKi9ioUT3/xC/yUc1c=; 5:RuYOOknTc+OIZe64C8Clj49ZLxcQ8CR+nW36zP4QeM/OMZoiCBq+q5jntOeHEIy7MA+bkVr9bzO2DNI9XX/FNgidTjSuP07A8V/AeCVr3gxWQWG+0+9mQs/wAaAQvBkx7yEgMrZtLn5d/2sEK28gAaY1u1ijMEtL+Dzt2t/9+kQ=; 24:q9w/R4uTUqZytsnWGLP4sPeITA35e0Ax+StWylwDgiYLXojcwHvUthOmekzXb0UEZQu53PTOGbzNMqVIQstUgWo25/PjIUqfVDK7bJx3dbo=; 7:3EF9Eg8RxrXEV8oM4ldMK0A4iILMfiRSO2tTdys+bQxWlA50MikYvO0NhBTS8LwIl/W3UDVbUmDP7opFjk4KAmfNFkUkiQ5B9SBNwFAu7vlnLAwFm3CX84tH1MFvFy6+AItShVFIouAgok0KjHe6va2eyUjxp/0Fk6IBuCuq3uYCbHSn9CSPnXp6FVEq+YA5tN1TEikHlkN6121ZqzJt282NcfgMJQhdGeYJi0VFYiaD/BhJfCc5zS2ocMIWgS+q x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a7d36481-68af-4f02-4ddc-08d5274f6c2f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249)(49563074); SRVR:VI1PR04MB3024; x-ms-traffictypediagnostic: VI1PR04MB3024: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231021)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR04MB3024; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR04MB3024; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(199003)(24454002)(189002)(66066001)(606006)(54356999)(50986999)(33656002)(99936001)(76176999)(106356001)(786003)(74826001)(53936002)(36756003)(1411001)(83716003)(2950100002)(14454004)(53546010)(316002)(101416001)(2900100001)(105586002)(189998001)(5250100002)(42882006)(5660300001)(6916009)(68736007)(25786009)(7736002)(82746002)(74482002)(230783001)(97736004)(3660700001)(3280700002)(91966014)(229853002)(478600001)(72206003)(2906002)(6306002)(8676002)(966005)(86362001)(81166006)(236005)(54896002)(6512007)(81156014)(8936002)(4326008)(39060400002)(6246003)(6506006)(6486002)(6436002)(99286004)(102836003)(6116002)(3846002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB3024; H:VI1PR04MB3021.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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=_93D35536-3722-4D4D-9E2D-CE6B8D199DAD"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: biu.ac.il X-MS-Exchange-CrossTenant-Network-Message-Id: a7d36481-68af-4f02-4ddc-08d5274f6c2f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2017 08:54:01.3419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61234e14-5b87-4b67-ac19-8feaa8ba8f12 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3024 Archived-At: Subject: Re: [Cfrg] AES-PMAC-SIV 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, 09 Nov 2017 08:54:09 -0000 --Apple-Mail=_93D35536-3722-4D4D-9E2D-CE6B8D199DAD Content-Type: multipart/alternative; boundary="Apple-Mail=_A3D95B9A-B014-4A8D-85B9-8F343962E0F4" --Apple-Mail=_A3D95B9A-B014-4A8D-85B9-8F343962E0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The intention in the spec text is that if the nonce is fixed then = AES-GCM-SIV has a birthday bound on the overall number of blocks (like = AES-GCM, AES-CCM, AES-SIV, etc.), even if the adversary is = nonce-respecting. This means that you can encrypt up to 2^48 blocks = overall with the same nonce in AES-GCM-SIV, with the adversarial = advantage of only 2^-32. The detailed analysis of all of these security considerations appear in = the series of papers referred to. I suggest looking at = https://eprint.iacr.org/2017/168.pdf = and = https://eprint.iacr.org/2017/702.pdf = . We have also put up a webpage with information and FAQs. See: = http://cyber.biu.ac.il/aes-gcm-siv Yehuda > On 9 Nov 2017, at 3:29, Tony Arcieri wrote: >=20 > On Wed, Nov 8, 2017 at 1:02 PM, Yehuda Lindell = > wrote: > 1) I don=E2=80=99t know how it can be hard to find implementations of = AES-GCM-SIV to benchmark against. In addition to reporting measurements = in the papers, we have also explicitly referenced both the github AES-NI = implementation at https://github.com/Shay-Gueron/AES-GCM-SIV = , and the BoringSSL = implementation. Note that BoringSSL can be compiled both with AES-NI + = CLMUL and without AES-NI (and CLMUL). So, you can compare easily on = modern x86 processors and also on ARM v7 (which does not have AES-NI and = CLMUL). >=20 > Thank you. I'm not sure how I didn't find this. I assure you I looked! >=20 > 2) The statement about bounds is blatantly false. Indeed, AES-SIV has = a birthday limit on the number of blocks. After encrypting 2^64 blocks, = the adversary has an advantage of 1/2. Thus, in order to limit the = adversary=E2=80=99s advantage to 2^-32, you can encrypt at most 2^48 = blocks. In contrast, AES-GCM-SIV comes with BEYOND BIRTHDAY BOUNDS. This = is described explicitly in the AES-GCM-SIV papers. In fact, if the same = nonce is always used, then AES-GCM-SIV has the same bounds as AES-SIV, = but when nonces repeat a bounded amount, AES-GCM-SIV=E2=80=99s bounds = are way beyond AES-SIV. >=20 > The specific bounds I am referring to are the ones referred to in = section 9 (Security Considerations) of draft-irtf-cfrg-gcmsiv-06: >=20 > If the nonce is fixed then AES-GCM-SIV acts like AES-GCM with a random = nonce, with the caveat that identical plaintexts will produce identical = ciphertexts. However, we feel that the 2^32 limit for AES- GCM is too = risky in a multi-key setting. Thus with AES-GCM-SIV we recommend that, = for a specific key, a nonce not be repeated more than 2^8 times. >=20 > I apologize if this is a mischaracterization. I actually asked a = number of people about this particular bound prior to posting, and at = one point was of the opinion I shouldn't even mention it. I would = definitely appreciate any clarifications you can provide to these bounds = and how these relate to the corresponding ones in AES-SIV. >=20 > -- > Tony Arcieri --Apple-Mail=_A3D95B9A-B014-4A8D-85B9-8F343962E0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

The intention in the spec text is that if the nonce is fixed = then AES-GCM-SIV has a birthday bound on the overall number of blocks = (like AES-GCM, AES-CCM, AES-SIV, etc.), even if the adversary is = nonce-respecting. This means that you can encrypt up to 2^48 blocks = overall with the same nonce in AES-GCM-SIV, with the adversarial = advantage of only 2^-32.

The detailed analysis of all of these security considerations = appear in the series of papers referred to. I suggest looking at https://eprint.iacr.org/2017/168.pdf and https://eprint.iacr.org/2017/702.pdf. 

We have also put up a = webpage with information and FAQs. See: http://cyber.biu.ac.il/aes-gcm-siv 

Yehuda


On 9 Nov 2017, at 3:29, Tony Arcieri <bascule@gmail.com> = wrote:

On Wed, Nov 8, 2017 at 1:02 PM, Yehuda Lindell = <Yehuda.Lindell@biu.ac.il> wrote:
1) I don=E2=80=99t know how it can be hard to find = implementations of AES-GCM-SIV to benchmark against. In addition to = reporting measurements in the papers, we have also explicitly = referenced both the github AES-NI implementation at https://github.com/Shay-Gueron/AES-GCM-SIV, and = the BoringSSL implementation. Note that BoringSSL can be = compiled both with AES-NI + CLMUL and without AES-NI (and CLMUL). So, you = can compare easily on modern x86 processors and also on ARM = v7 (which does not have AES-NI and CLMUL).

Thank you. I'm not sure how I didn't = find this. I assure you I looked!
 
2) = The statement about bounds is blatantly false. Indeed, AES-SIV has = a birthday limit on the number of blocks. After encrypting 2^64 = blocks, the adversary has an advantage of 1/2. Thus, in order = to limit the adversary=E2=80=99s advantage to 2^-32, you can encrypt = at most 2^48 blocks. In contrast, AES-GCM-SIV comes with = BEYOND BIRTHDAY BOUNDS. This is described explicitly in the = AES-GCM-SIV papers. In fact, if the same nonce is always used, = then AES-GCM-SIV has the same bounds as AES-SIV, but when nonces = repeat a bounded amount, AES-GCM-SIV=E2=80=99s bounds are way = beyond AES-SIV. 

The specific bounds I am referring to = are the ones referred to in section 9 (Security Considerations) = of draft-irtf-cfrg-gcmsiv-06:

If the nonce is fixed then = AES-GCM-SIV acts like AES-GCM with a random nonce, with the caveat that = identical plaintexts will produce identical ciphertexts. However, we = feel that the 2^32 limit for AES- GCM is too risky in a multi-key = setting. Thus with AES-GCM-SIV we recommend that, for a specific key, a = nonce not be repeated more than 2^8 times.
I apologize if this is a = mischaracterization. I actually asked a number of people about this = particular bound prior to posting, and at one point was of the opinion I = shouldn't even mention it. I would definitely appreciate any = clarifications you can provide to these bounds and how these relate to = the corresponding ones in AES-SIV.

--
Tony = Arcieri

= --Apple-Mail=_A3D95B9A-B014-4A8D-85B9-8F343962E0F4-- --Apple-Mail=_93D35536-3722-4D4D-9E2D-CE6B8D199DAD 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/5w4gFAloEF6gACgkQgpgt7E/5 w4iQyQ//VEc0HXDWm22YJIojNT+tcxuORF/1e8HHdP97f4pk9ys+QCE2IDQZXuYn j2hDrxRTFVUfaWkdJYhHD5gEJhJ3f8SVSokF2s3Cv8gtiS4OuUP2jRFJV0o7fB2V lP9jiOmFWKBpAMrXQudpG92BSCVUVvlmItdB1XKLWZIui2wP63+u0WkdiA+FMqRC W79A0B/hxfinoSEQKONo4U4JG85ycaM1Uaz2/GpfROru5Jcbzcc+mPUb8OIggC2m HhmRKWD+77qvR4p4wUIfl/r6g/+p62OcuEGmA+XQYu2ZIzl++RglyXJbAPDAjpFV fJ3f3AO13tAFQQDpflVfPtt0jgt83Q40CjipJzS8WtZeldbmb+q0fBxZgsRH4hsg JQg4fv+E2il1nRpharFO1bcQvwuJL+gBDPhGQBNaV4zHCmCaAwhRaGxrds1hI/lW XVcnW+sd/bdZSq1cfYbgKD2VL6eW+V0cuLCBSapWwyyUC7ZBE6bdOyGJW7FPmjUC /MhYt+alzabQKAM6AWtWTq9l2wXrCz4TnULDIGlggpmViwnDSEpPKXiQntdHpRaz xD97Xm0585hdvCF2kgXQo4mRO1LFt/I7hBUwIZmQLoTkDovfW2BBWKqGS8kyg9AY LPWQ0Pm21G1yyUBM9kkbfNQh2nXUtUEzYqotVaGCwM+OKXOajo4= =G9Tg -----END PGP SIGNATURE----- --Apple-Mail=_93D35536-3722-4D4D-9E2D-CE6B8D199DAD-- From nobody Sat Nov 11 19:56:07 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 46FAD1270AE for ; Sat, 11 Nov 2017 19:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 u1uJHLDeFwZO for ; Sat, 11 Nov 2017 19:56:02 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 69BA31201FA for ; Sat, 11 Nov 2017 19:56:02 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id j58so16134538qtj.0 for ; Sat, 11 Nov 2017 19:56:02 -0800 (PST) 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=j3/Zcq8nt/7plJ21DTxUlhpZbH1nfNxC6mTXOAHBm8s=; b=OfjW6UGrvl3gOFUatKs3WWPZzmIXkJ6JDbecjAdM4tZy8fsP9cJAGw5U2d/KTtA/ma 0sU074M80XHPAUlkjlYVplwxR9Zbl5U1Zfb1ZhJwjZ3Su2DCGxTs57jtS4h3zwGn8wPU xMnbx6vrskLCb4Zqvx79haQ8pRyifgC6YvK5nUfiFK3bQFOKf0/UdD4JK4+hx4brCxjx JmozOwA+yyWvyJjEFn0wlK0T7k8XS3+tgfX8SpUCSSjFA07kd2DT/Z6MXsFYLi+tsXDt WWuqMkwZ8MWcrxKeAigJzGrlmhgg4D7n913kHEAAeMEgLaEbLfpL6e+BV9ri6ZbQRQqO eVGw== 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=j3/Zcq8nt/7plJ21DTxUlhpZbH1nfNxC6mTXOAHBm8s=; b=Y0k0lnTJNn4d7/Zhx6suafC0lh5gint9f5aHtfshFXgNIMFPsDSlQS509jyXD74Hti Ln7bX/DvkwcUa3OhBAsMDjl3pfIP75qKiGI6q05ql8PcErSFpi+AyGJbJRuLWN757OYs 2hONpSO6cYcHNLONum6vfS98w4eBoyW6yPxW+aiYtjYKR8Sws4AxGZ5WX4wlbcrLxlTA 3qLqKiaH++CthGidBwN8LjmmZ5iV+o0EBsoAGvZCzgBv2LHzVl83hqqQqBv64NprKgDx b9bdDbdF+lRaAhMaDEeczZEgE5X1a4LM3EzxoNmoXWichz1+Kv+GO8+wM1RPSk8Ltc6J N49g== X-Gm-Message-State: AJaThX4OZI6aWgI+rLvhvxSycOb5shxTtN/W6mGJCCtHCKjwY6ocIWVs nRxQupuv51sJttypj96wdpUN/pRfcMgVhJ5NjJo= X-Google-Smtp-Source: AGs4zMbSMebYNIa9XmVswFPXiI1no0C90/Wor/C66syCDAxnKXB40+aBu/NenT3eZ6ZD4oQIsFvK8H9A67k6F3k1Pow= X-Received: by 10.200.42.104 with SMTP id l37mr8020244qtl.73.1510458961368; Sat, 11 Nov 2017 19:56:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Sat, 11 Nov 2017 19:56:00 -0800 (PST) From: "Stanislav V. Smyshlyaev" Date: Sun, 12 Nov 2017 06:56:00 +0300 Message-ID: To: "cfrg@irtf.org" , "David McGrew (mcgrew)" Content-Type: multipart/alternative; boundary="001a113ff480d71afc055dc121eb" Archived-At: Subject: [Cfrg] Review of draft-mcgrew-hash-sigs-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 03:56:05 -0000 --001a113ff480d71afc055dc121eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Document: draft-mcgrew-hash-sigs-08 Reviewer: Stanislav Smyshlyaev Review Date: 2017-11-11 Summary: Minor revision needed The hash-based signature scheme described in the I-D provides message authentication algorithms that remain secure after introduction of effective full-scale quantum computers. This scheme is based on the Merkle tree scheme and employs specific variant of Winternitz one-time signature. The scheme requires a small set of fixed domain parameters and can be easily adopted for the use with national-specific cryptographic primitives. A particularly important feature of the scheme is the fact that each invocation of a fixed hash function H outputs a unique byte string (except a negligible of identifiers collision). The proposed scheme was proven to be existentially unforgeable under adaptive chosen message attack (GMR-secure) in random oracle model when using second preimage resistant hash function ([F17]). It seems also not to be vulnerable against so called duplicate signature key selection attack (which is out of GMR-security definition and was firstly introduced in [BM99] since an attacker who wants to create his own key pair which can be used for successful verification of a target signature has to find a second preimage of a used hash function. The current version of the document lacks, however, comments on the post-quantum security. It would be great if such a comment appears. Since the proposed signature scheme is stateful, it is extremely important to manage its states in a secure way. The I-D proposes helpful technical implementation notes that cover synchronization issues when storing key in non-volatile memory. The document is very important, well-written and fully defines the proposed algorithms. I particularly like that there are very helpful sections that give an overview of the design rationale. There is a number of concerns, that should be addressed before the publication. Once the comments are resolved, I think that the document can be published. Formulae and algorithms to be checked for correctness: The second paragraph of Section 4.2 states that length of LM-OTS signature equals np, while it seems to be equal to 4 + n(p+1) The description of the algorithm 6 lacks parsing of parameter otstype The description of the algorithm 6b supposes that otssigtype is set directly after q, while the informal description in Section 5.4 states that otssigtype follows after the OTS value Other comments: Throughout the text: consider replacing 'signature system' with a commonly used 'signature scheme' Chapter 1: "moderatley" -> "moderately" Chapter 2: "A message/signature pair are valid" -> "... is valid" "the signature and message pair are not valid" -> "... is not valid" Section 3.1: "a four byte string S " -> "a four-byte string S" Section 3.1.1: The i^th element in an array A is denoted as A[i] -> the i-th element... The same change should be done throughout the text to avoid confusion with powers of i. Section 3.2: "I - a 16 byte identi=C2=ADfier" -> "I - a 16-byte identifier" "i =3D a value between 0 and 264" -> "i - a value between 0 and 264" Function H is used in the definition of par=C2=ADameter i, but that functio= n is not yet defin=C2=ADed at that point. "a two byte identifier " -> "a two-byte identifier" Chapter 4: "a diversification parameter q (which is used as part of the security string, as listed in Section 3.2" - ")" should be added Section 4.1: Definitions of n, w, p, ls and H: last three definifons end with ".", while the first two do not. The definition or re=C2=ADference should be gi=C2=ADven for the notion of W= inte=C2=ADrnitz coefficient. Also the same should be done with the not=C2=ADions Winternitz tree, Winternitz chain and LMS tree. Section 4.2: "Here SHA256 denotes the NIST standard hash function [FIPS180]." - since SHA-256 is defined together with SHA-1, SHA-384 etc., it seems better to say something like "Here SHA256 denotes the SHA-256 hash function, defined in NIST standard [FIPS180]." Section 4.5: "A checksum is used to ensure that any forgery attempt that manipulates the elements of an existing signature will be detected." - the sentence is too general and seem to not add any real information to the reader. In my opinion, it would be better to say explicitly about the vulnerability that appears if we do not use the checksum. Section 4.7: "Signature Typecode Type ," -> "Signature Typecode Type," Chapter 5: There is "Leight=C2=ADon Micali Signatures", but in the introduction this n= otion was men=C2=ADtioned as "Leighton-M=C2=ADicali Signatures". Al=C2=ADso, the = abbreviation LMS was already given in Section 1. Section 5.1: "h : the height (number of levels - 1) in the tree, and" - 1) "of" instead of "in", 2) it seems that "and" should be omitted. There are two sentences about possible usage of different hash functions - I'd prefer to seem them combined in a one, they look quite confusing in the current version. Consider adding in the end of Section 5.1 a paragraph, which explicitly defines the sizes of private key, public key and signature in terms of the used parameters. It can be useful for a reader, who first opens the document and wants to understand the overall properties of the scheme. Section 5.4: Line 3 =E2=80=9Can LM-OTS signature, and=E2=80=9D - it seems that =E2=80=9C= and=E2=80=9D should be omitted. Section 5.4.1: It seems strange that the section for "LMS Signature Verification" has the number "5.5" and the "LMS Signature Generation" has "5.4.1" - maybe use "5.6" and "5.5" instead? Section 5.5: It seems more reasonable to use "Algorithm 6a" instead of "Algorithm 6" Chapter 6: In the first paragraph a general description is given for HSS with 2 levels, and in the I-D it is defined for up to 8 levels. It seems more helpful to modify the first paragraph for the case of arbitrary number of levels, not only for two. Chapter 8: "Other hash functions may be used in future specifications; all the ones that we will be likely to support (SHA-512/256 and the various SHA-3 hashes) would work well with a 16 byte I value." - mentioning SHA-256 here among "other hash functions" looks confusing, given the whole I-D defines schemes for SHA-256. Chapter 12: "an attacker who does not know the private key associated with a public key can find a message and signature that are valid with that public key" - maybe "a new message" or "a message which is different from all previously signed ones". There is a very helpful text about formatted inputs of a hash - I'd recommend to add a subtitle before it (use 12.1 before "The format of the inputs to..."). "pseuddorandom" -> "pseudorandom" "This can be shown (in [Fluhrer17]) ..." -> "This is shown (in [Fluhrer17]) ..." Section 12.1 "It is essential for security that the application ensure" -> "ensures" "until the data has been to the underlying hardware" - maybe add "stored" or "written" after "has been"? In your IETF 97 slides there was a slide with "Anti-Copying Token in Private Key Files" (slide 19 in https://datatracker.ietf.org/ meeting/97/materials/slides-97-cfrg-hash-based-signatures- update-and-batch-message-signing/) - won't it be helpful to add those recommendation in Chapter 12 also? Chapter 12: "where HSS need only perform one" -> "needs only to perform one" "HSS is somewhat simpler" - this looks quite vague and uncertain - maybe it would be better to get rid of this phrase?.. References: "Buchmann, J., Dahmen, E., and . Andreas Hulsing," - remove "." before "Andreas" Appendix A: "however any other cryptographical secure method of generating private keys would also be safe." - formally, this is not true: if the previously mentioned formula is used with, say, 254 instead of 255, it would be generally "cryptographically secure", but won't be very good for the considered case. Maybe just get rid of this (quite vague) sentence at all? "cryptographical secure method" -> " cryptographically secure method" [BM99]: Blake-Wilson S., Menezes A., "Unknown key-share attacks on the station-to-station (STS) protocol", Lect. Notes Comput. Sci., 1560, 1999, 156?170. [F17]: Fluhrer S., "Further analysis of a proposed hash-based signature standard", EPrint IACR Archieve, http://eprint.iacr.org/2017/553.pdf. --001a113ff480d71afc055dc121eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
Document: draft-mcgrew-hash-sigs-08
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-11-11
Summary: Minor revision needed

The hash-b= ased signature scheme described in the I-D provides message authentication = algorithms that remain secure after introduction of effective full-scale qu= antum computers. This scheme is based on the Merkle tree scheme and employs= specific variant of Winternitz one-time signature. The scheme requires a s= mall set of fixed domain parameters and can be easily adopted for the use w= ith national-specific cryptographic primitives. A particularly important fe= ature of the scheme is the fact that each invocation of a fixed hash functi= on H outputs a unique byte string (except a negligible of identifiers colli= sion).
=C2=A0
The proposed scheme was proven to be exis= tentially unforgeable under adaptive chosen message attack (GMR-secure) in = random oracle model when using second preimage resistant hash function ([F1= 7]). It seems also not to be vulnerable against so called duplicate signatu= re key selection attack (which is out of GMR-security definition and was fi= rstly introduced in [BM99] since an attacker who wants to create his own ke= y pair which can be used for successful verification of a target signature = has to find a second preimage of a used hash function. The current version = of the document lacks, however, comments on the post-quantum security. It w= ould be great if such a comment appears.
=C2=A0
Since t= he proposed signature scheme is stateful, it is extremely important to mana= ge its states in a secure way. The I-D proposes helpful technical implement= ation notes that cover synchronization issues when storing key in non-volat= ile memory.
=C2=A0
The document is very important, well= -written and fully defines the proposed algorithms. I particularly like tha= t there are very helpful sections that give an overview of the design ratio= nale.

There is a number of concerns, that should b= e addressed before the publication. Once the comments are resolved, I think= that the document can be published.


Formulae and algorithms to be checked for correctness:=C2=A0
Th= e second paragraph of Section 4.2 states that length of LM-OTS signature eq= uals np, while it seems to be equal to 4 + n(p+1)
The description= of the algorithm 6 lacks parsing of parameter otstype
The descri= ption of the algorithm 6b supposes that otssigtype is set directly after q,= while the informal description in Section 5.4 states that otssigtype follo= ws after the OTS value

Other comments:
<= br>
Throughout the text: consider replacing 'signature system= ' with a commonly used 'signature scheme'

<= div>Chapter 1:

"moderatley" -> "= moderately"

Chapter 2:

"A message/signature pair are valid"=C2=A0 -> "... is = valid"

"the signature and message pair a= re not valid" -> "... is not valid"

<= div>Section 3.1:

"a four byte string S "= -> "a four-byte string S"

Section 3.= 1.1:

The i^th element in an array A is denoted as = A[i] -> the i-th element...

The same change sho= uld be done throughout the text to avoid confusion with powers of i.
<= div>
Section 3.2:

"I - a 16 byt= e identi=C2=ADfier" -> "I - a 16-byte identifier"

"i =3D a value between 0 and 264" -> "i= - a value between 0 and 264"

Function H is u= sed in the definition of par=C2=ADameter i, but that function is not yet de= fin=C2=ADed at that point.

"a two byte identi= fier "=C2=A0 -> "a two-byte identifier"

Chapter 4:

"a diversification paramet= er q (which is used as part of the security string, as listed in Section 3.= 2" - ")" should be added

Section 4.= 1:

Definitions of n, w, p, ls and H: last three de= finifons end with ".", while the first two do not.

=
The definition or re=C2=ADference should be gi=C2=ADven for the = notion of Winte=C2=ADrnitz coefficient. Also the same should be done with t= he not=C2=ADions Winternitz tree, Winternitz=C2=A0 chain and LMS tree.

Section 4.2:

"Here SHA25= 6 denotes the NIST standard hash function [FIPS180]." - since SHA-256 = is defined together with SHA-1, SHA-384 etc., it seems better to say someth= ing like "Here SHA256 denotes the SHA-256 hash function, defined in NI= ST standard [FIPS180]."

Section 4.5:

"A checksum is used to ensure that any forgery attemp= t that manipulates the elements of an existing signature will be detected.&= quot; - the sentence is too general and seem to not add any real informatio= n to the reader. In my opinion, it would be better to say explicitly about = the vulnerability that appears if we do not use the checksum.
Section 4.7:

"Signature Typecode = Type ," -> "Signature Typecode Type,"

Chapter 5:

There is "Leight=C2=ADon Mic= ali Signatures", but in the introduction this notion was men=C2=ADtion= ed as "Leighton-M=C2=ADicali Signatures". Al=C2=ADso, the abbrevi= ation LMS was already given in Section 1.

Section = 5.1:

"h : the height (number of levels - 1) i= n the tree, and" - 1) "of" instead of "in", 2) it = seems that "and" should be omitted.

Ther= e are two sentences about possible usage of different hash functions - I= 9;d prefer to seem them combined in a one, they look quite confusing in the= current version.

Consider adding in the end of Se= ction 5.1 a paragraph, which explicitly defines the sizes of private key, p= ublic key and signature in terms of the used parameters. It can be useful f= or a reader, who first opens the document and wants to understand the overa= ll properties of the scheme.

Section 5.4:

Line 3 =E2=80=9Can LM-OTS signature, and=E2=80=9D - it see= ms that =E2=80=9Cand=E2=80=9D should be omitted.

S= ection 5.4.1:

It seems strange that the section fo= r "LMS Signature Verification" has the number "5.5" and= the "LMS Signature Generation" has "5.4.1" - maybe use= "5.6" and "5.5" instead?

Sect= ion 5.5:

It seems more reasonable to use "Alg= orithm 6a" instead of "Algorithm 6"

Chapter 6:

In the first paragraph a general descr= iption is given for HSS with 2 levels, and in the I-D it is defined for up = to 8 levels. It seems more helpful to modify the first paragraph for the ca= se of arbitrary number of levels, not only for two.

Chapter 8:

"Other hash functions may be use= d in future specifications; all the ones that we will be likely to support = (SHA-512/256 and the various SHA-3 hashes) would work well with a 16 byte I= value." - mentioning SHA-256 here among "other hash functions&qu= ot; looks confusing, given the whole I-D defines schemes for SHA-256.
=

Chapter 12:

"an attacker = who does not know the private key associated with a public key can find a m= essage and signature that are valid with that public key" - maybe &quo= t;a new message" or "a message which is different from all previo= usly signed ones".

There is a very helpful te= xt about formatted inputs of a hash - I'd recommend to add a subtitle b= efore it (use 12.1 before "The format of the inputs to...").

"pseuddorandom" -> "pseudorandom&quo= t;

"This can be shown (in [Fluhrer17]) ...&qu= ot; -> "This is shown (in [Fluhrer17]) ..."

Section 12.1

"It is essential for secu= rity that the application ensure" -> "ensures"
=
"until the data has been to the underlying hardware&quo= t; - maybe add "stored" or "written" after "has be= en"?

In your IETF 97 slides there was a slide= with "Anti-Copying Token in Private Key Files" (slide 19 in htt= ps://datatracker.ietf.org/meeting/97/materials/slides-97-cfrg-has= h-based-signatures-update-and-batch-message-signing/) - won&#= 39;t it be helpful to add those recommendation in Chapter 12 also?

Chapter 12:
"where HSS need only perform on= e" -> "needs only to perform one"
"HSS is = somewhat simpler" - this looks quite vague and uncertain - maybe it wo= uld be better to get rid of this phrase?..=C2=A0

R= eferences:

"Buchmann, J., Dahmen, E., and . A= ndreas Hulsing," - remove "." before "Andreas"

Appendix A:

"however an= y other cryptographical secure method of generating private keys would also= be safe." - formally, this is not true: if the previously mentioned f= ormula is used with, say, 254 instead of 255, it would be generally "c= ryptographically secure", but won't be very good for the considere= d case.
Maybe just get rid of this (quite vague) sentence at all?=

"cryptographical secure method" -> &= quot; cryptographically secure method"


[BM99]: Blake-Wilson S., Menezes A., "Unknown key-share attac= ks on the station-to-station (STS) protocol", Lect. Notes Comput. Sci.= , 1560, 1999, 156?170.
=C2=A0
[F17]: Fluhrer S., &q= uot;Further analysis of a proposed hash-based signature standard", EPr= int IACR Archieve, http://eprint.iacr.org/2017/553.pdf.
=C2=A0<= /div>


--001a113ff480d71afc055dc121eb-- From nobody Mon Nov 13 10:22:53 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 334FC124BAC; Mon, 13 Nov 2017 10:22:46 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151059736615.656.8326137133984286664@ietfa.amsl.com> Date: Mon, 13 Nov 2017 10:22:46 -0800 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-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: Mon, 13 Nov 2017 18:22:46 -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 : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption Authors : Shay Gueron Adam Langley Yehuda Lindell Filename : draft-irtf-cfrg-gcmsiv-07.txt Pages : 39 Date : 2017-11-13 Abstract: This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-07 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-gcmsiv-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-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 Nov 13 11:59: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 71D5E126C89 for ; Mon, 13 Nov 2017 11:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JN6AUeQaRyJd for ; Mon, 13 Nov 2017 11:58:57 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50131.outbound.protection.outlook.com [40.107.5.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC02F1241F3 for ; Mon, 13 Nov 2017 11:58:56 -0800 (PST) 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=16wJ1+qGmzR6H5A+4WiKBAdGvoL+AyfUhGd1nZ7WWzM=; b=ZHSj6FwBUFv3vRMnu+RKemBkgJh1Cvq31LVQ7r29TkPVaTqQsqFVD+/rr/rHTTULHmTVLa7ceL47/CJiPzEMIICgGWIaUFirQAK2DSC5asd1Xd/wOX6bizddiHt5XlATX3nYEayPmDfcVIyEfNARQai8ES5vZgpzkvmMEmm4UL8= Received: from VI1PR04MB3021.eurprd04.prod.outlook.com (10.170.228.143) by VI1PR04MB3023.eurprd04.prod.outlook.com (10.170.228.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 19:58:53 +0000 Received: from VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b]) by VI1PR04MB3021.eurprd04.prod.outlook.com ([fe80::a142:8cff:3d80:717b%13]) with mapi id 15.20.0218.015; Mon, 13 Nov 2017 19:58:53 +0000 From: Yehuda Lindell To: "cfrg@irtf.org" Thread-Topic: AES-GCM-SIV spec update (v07) Thread-Index: AQHTXLnU1J3Um5ll8kuxTnuYh+2+VA== Date: Mon, 13 Nov 2017 19:58:53 +0000 Message-ID: <9C110B46-E280-410E-9C1F-1014EB4D408A@biu.ac.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yehuda.Lindell@biu.ac.il; x-originating-ip: [2a01:6500:a049:624e:45f3:c8f2:3168:c20e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR04MB3023; 6:33yYf4crvhBGg2OfP96P9U8HspE6oDPJTWmggyZQ8zMBNWBxknWE/iSJ4CDovh8qeSmmwvHnq9luXUgWd6XHlzp/Y5VsGG8P3hpQql3ZqcfFkuLUo2n14mhQdfv2Q8JUyK2laFjrRZ4ZYuxwGpjIaDb0GdquthSjSGRBI7aABvWW4H5px2zzrLaPGBb/IpT7zNWiU18UiO+r6s4VzTwBksJYwxXk0tXenCi6WtPPcrcUlyVSXx8BIvISMFnYDRIl5x+p7kP2R0ybjfx5vtyZORV2gpEeXjirbw7Qn3ZlOjSB8ebrwnwnErpaUoUFzPf/nfL2kk+4flUzep1UEXR7XnhbShMb2kvmEcEniDzbPAQ=; 5:jfryWvyceFGiVnFdN9SHlrlvstYAwvvwAQBGfoFlS0hLPqHWkygvoOklpxyROxmQTN/uvOG60Ba+E8QWYhpUZVJVM8E1bip9dRnh9XmXlmj9/28/CmnnBdDD5UNj3t4ynL6BgqJFPE9yevnIHnzm9JqqU5N0vjiI2ZjyeFoS2d4=; 24:4U16aq40QTzhhc15Gh76Xa8GY+4Vt4tH0d28axQJYEupIBOaJ+B/UiT/Kak8q1GCg+svbFbZdYSrp29Tw0LJWDWUApBLmd3/UpDzcRVsDuY=; 7:ajXPM73s6YTn16P9u8xPawfFAJUgTq4NPfcO2ULCkkh6bSfU5+GolLTl7gcyhKl0JjcYs0BVHG4mSNsVkqyEo1CvF/JXDsMuQPglqAgEEGGTPy0hekOSRr5h2MrY2XJIVitkndBt9AswrA4mvGfmpMB6uKL5LCs00XCNiq6kqEmm5P7KeAcSJAz/PdqgcoyFlXXyevI7w17scObkwkG3HRnk5ujU/r2dOPYm9hgLSm4v1abmLBAkYSQqcycYcq4t x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 476fe525-9e5e-4d46-a234-08d52ad0f75e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:VI1PR04MB3023; x-ms-traffictypediagnostic: VI1PR04MB3023: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(3231022)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR04MB3023; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR04MB3023; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39830400002)(199003)(189002)(230783001)(33656002)(305945005)(101416001)(36756003)(74482002)(5250100002)(99936001)(50986999)(102836003)(6116002)(54356999)(7736002)(2501003)(2900100001)(25786009)(74826001)(3660700001)(68736007)(15650500001)(14454004)(3280700002)(316002)(2906002)(72206003)(966005)(6512007)(82746002)(6436002)(786003)(478600001)(5640700003)(6486002)(6306002)(53936002)(106356001)(86362001)(189998001)(6916009)(97736004)(2351001)(42882006)(8936002)(81156014)(105586002)(83716003)(99286004)(81166006)(1730700003)(8676002)(5660300001)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB3023; H:VI1PR04MB3021.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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=_40C5AEFF-05E3-44F6-91CA-EAE240CE634D"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: biu.ac.il X-MS-Exchange-CrossTenant-Network-Message-Id: 476fe525-9e5e-4d46-a234-08d52ad0f75e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 19:58:53.2969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61234e14-5b87-4b67-ac19-8feaa8ba8f12 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3023 Archived-At: Subject: [Cfrg] AES-GCM-SIV spec update (v07) 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, 13 Nov 2017 19:58:59 -0000 --Apple-Mail=_40C5AEFF-05E3-44F6-91CA-EAE240CE634D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We have updated the AES-GCM-SIV spec and uploaded draft version 7. There = is no difference whatsoever with respect to the algorithm; the only = changes in the document are in the Security Considerations section. We = found that some of the text there was easily misunderstood and so we = have made it clearer. This is also a good opportunity to point to a website that we have setup = for AES-GCM-SIV with links, FAQs and more. The URL is: = https://cyber.biu.ac.il/aes-gcm-siv/ All the best, Adam, Shay and Yehuda --Apple-Mail=_40C5AEFF-05E3-44F6-91CA-EAE240CE634D 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/5w4gFAloJ+RwACgkQgpgt7E/5 w4gY9A//WwSYkaDnKHhrzWjqwCXuhHD5joLxBWpSn+PVlquBddUNdF2taZp9Q3p8 8hJBZM8VVfMdvdaBWWjfbLMv/Tq/67pycKWGiiQkTVTh1atZYbTtJPkNXnZFK2R9 +fte6lnUrVM87RLeVVq3nsA20s2qDqX0X+aNfEL6jCs0BUymLqWx2jmN9H0LnCpY 9LOYNpGDkvtAwVgfWAjFXkFadZJpZzvFHTs09RaPfvLQ4Avo0R1+eQBOCFObtZpy f3HGf1CE6N8JoWp/AM16CkYWOQeLrXRIgGH8JT3A6CSoKad6ZojdxgBgWew8aQKy iKn8aiPwkO/3l8L29zan86Xq2ChUsuumrvv+mBJqeXEq3/RO7kQ+GM654Kr2Bz0U pxumVSkWL1hAUruPHbVKuQxnCvwva+hfYIF9TJNVGD3o852PEccVII0Cf1e/cFza R6PNG3koMHlLO/CQaskNUEmCK+MYcY/XdSVIzR30mLqic2CpjdJvIAxIrxvnld6Z xpMpSooGzU+O8Mx69UaBEG5y3mYonEXViHMhGKckVGUahUd+iBlDnBBaLi/Tdd+N 1dp/f6l3xgfDKJ8JcHWB3cXBgpYjJycq/HC+x8OuhRI2ZIsb+kLZTbc2I+KiOG6m EWC7xQhnaS56hx0+l+UwSNf8cnIymLKmMmpdOHfgqR1g4Cok9i0= =G98v -----END PGP SIGNATURE----- --Apple-Mail=_40C5AEFF-05E3-44F6-91CA-EAE240CE634D-- From nobody Mon Nov 13 12:24: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 44AAC1241F3 for ; Mon, 13 Nov 2017 12:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, 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 coOLOoZhRYG5 for ; Mon, 13 Nov 2017 12:24:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) (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 585D81201F8 for ; Mon, 13 Nov 2017 12:24:34 -0800 (PST) Received: from [73.119.134.196] (helo=[192.168.1.170]) by psg.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eELHV-0008oQ-Km for cfrg@ietf.org; Mon, 13 Nov 2017 20:24:33 +0000 To: cfrg@ietf.org From: Paul Selkirk Message-ID: <6a3950fc-c98b-9617-160f-beb51f0adc31@psgd.org> Date: Mon, 13 Nov 2017 15:24:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cfrg] review of draft-mcgrew-hash-sigs-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:24:37 -0000 Greetings. I've been asked to look into implementing this draft for the CrypTech project (http://cryptech.is). I'm not a cryptographer, and I had no previous familiarity with hash-based signatures. But I do have some experience both writing and implementing standards, and I have to admit it took several readings before I understood this one. There is a certain amount of sloppiness and imprecision in terminology in this document, e.g. "type" and "typecode" mean different things at different levels, and it's not always immediately clear which typecode is being talked about. Also, some concepts are under-explained for the uninitiated, most notably the hierarchical signing system (both the justification and the construction). For the record, I support this work, and believe it can be implemented as-is. The following comments are mostly editorial, to improve the clarity, consistency, and readability of the spec. 1. Introduction After paragraph 3, I'd add a short explanation of Merkle trees for the benefit of newcomers like myself, e.g. In the Merkle scheme, a binary tree of height h is used to hold 2^h OTS key pairs. Each inner node of the tree holds a hash of the concatenation of its children's public keys. The public key of the tree is the hash value contained in the root node (a recursive hash of the OTS public keys), while the private key of the tree is the collection of all the OTS private keys, together with the index of the next OTS private key to use. I would break up paragraph 4, and add a short explanation of the HSS, e.g. In this note we describe the Leighton-Micali Signature (LMS) system, which is a variant of the Merkle scheme, and a Hierarchical Signature System (HSS) built on top of it that can efficiently scale to larger numbers of signatures. In order to support signing large numbers of messages on resource-constrained systems, the Merkle tree can be subdivided into a number of smaller trees. Only the bottom-most tree is used to sign messages, while trees above that are used to sign their children. For example, in the simplest case with 2 levels, the root tree is used to sign 2^h trees with 2^h OTS key pairs, for a total of 2^(2h) key pairs. The advantage of this scheme is that only the "active" trees are instantiated, which saves both time (for key generation) and space (for key storage). Signing is also somewhat faster, although signatures are larger and verification is slower. Paragraph break before "This note is structured as follows." 2. Interface It's not clear why paragraphs 2-4 are indented. Are you quoting another document? 3.2. Security string As a small nit, you say things like "this is bytes 0-15 of the hash", where you really mean "of the string being hashed". I tend to think of "the hash" as being the output of the hash function. A much larger nit is that the "security string" is not a single thing, and this section is full of forward references to later parts of the document, so it's very hard to parse it without having previously read the rest of the document. 4. LM-OTS One-Time Signatures In order to facilitate its use in an N-time signature system, the LM- OTS key generation, signing, and verification algorithms all take as input a diversification parameter q This is the only use of the phrase "diversification parameter". I'm really not sure what it means. q is the leaf number, or alternately the current index into the LMS secret key. This feels like a layer violation. When the LM-OTS signature system is used outside of an N-time signature system, this value SHOULD be set to the all-zero value. Using LM-OTS outside of LMS is outside the scope of this document. 4.1. Parameters Increasing w will shorten the signature, but at a cost of a larger computation to generate and verify a signature. Remove this sentence because it's redundant to the slightly fuller discussion in section 4.2. 4.2. Parameter Sets As a purely editorial matter, it's unclear why this is a separate section from "Parameters", where they're a single section 5.1 for LMS. I might combine the sections, and merge the last paragraph of 4.1 with the first paragraph of 4.2. 4.3. Private Key The format of the LM-OTS private key is an internal matter to the implementation, and this document does not attempt to define it. But then it goes on to suggest a format, and the rest of the document assumes that format is used. 1. retrieve the value p from the type, This is redundant to step 3. and the value I the 16 byte identifier of the LMS public/private keypair that this LM-OTS private key will be used with This is phrased awkwardly, and implies that it's someone else's job to generate I. I suggest changing step 1 to something like the following (with language borrowed from section 3.2): 1. Generate I, a 16 byte identifier. It MUST be chosen uniformly at random, or via a pseudorandom process. (Or insert this step in between steps 3 and 4, for consistency with section 4.4.) As a side note, our project already uses RFC4122 version 4 UUIDs, which are effectively 122-bit random numbers with a few fixed bits. I'm assuming that the security of this system doesn't require a full 128 bits for I. 4.6. Signature Generation The LM-OTS signature of a message is generated by first prepending the LM key identifier I, the LM leaf identifier q, Change "LM" to "LMS". 5. Leighton Micali Signatures "Leighton Micali" should be consistently hypenated as "Leighton-Micali" throughout the document. In general, the j^th node at level L has node number 2^L + j. This use of L is distinct from HSS, but could possibly cause confusion. I might change L to i here. I might also move this whole description of node numbers to section 5.3, which is the only place it's actually used. 5.1. Parameters H SHOULD be the same as in Section 4.1, but MAY be different. There are 2^h leaves in the tree. The hash function used within the LMS system SHOULD be the same as the hash function used within the LM-OTS system used to generate the leaves. You say the same thing in immediately adjacent paragraphs. 5.2. LMS Private Key The format of the LMS private key is an internal matter to the implementation, and this document does not attempt to define it. Again, you then define a suggested format, and the rest of the document assumes that format is used. In particular, q is a mandatory and visible part of the signature. 5.3. LMS Public Key The public key format should really be on a line by itself, pulled out of the paragraph, e.g. The LMS public key is the string u32str(type) || u32str(otstype) || I || T[1] Better yet, include an algorithm, e.g. 1. Generate I, a 16 byte identifier. It MUST be chosen uniformly at random, or via a pseudorandom process. 2. compute the hash value of each leaf node as follows: r = 2 * 2^h - 1 while (r >= 2^h) { T[r] = H(I||u32str(r)||u16str(D_LEAF)||OTS_PUB[r-2^h]); r = r - 1 } 3. compute the hash value of each inner node as follows: r = 2^h - 1 while (r > 0) { T[r] = H(I||u32str(r)||u16str(D_INTR)||T[2*r]||T[2*r+1]); r = r - 1 } 4. return u32str(type) || u32str(otstype) || I || T[1] 5.4. LMS Signature Again, I'd pull out the symbolic representation of the signature onto its own line (or into pseudo-code, as below), for clarity and emphasis. More seriously, the authentication path is under-specified. The array of values contains the siblings of the nodes on the path from the leaf to the root but does not contain the nodes on the path themselves. The array for a tree with height h will have h values. The first value is the sibling of the leaf, the next value is the sibling of the parent of the leaf, and so on up the path to the root. This never says what is in path[i]. A close reading of the verification algorithm tells us that it's the m-byte hash value of the tree node, but it really needs to be made explicit here. Also, in the symbolic version, you say path[0] || path[1] || ... || path[h-1]. This reverses the usual ordering, where layer 0 is the root of the tree, and layer h-1 is the bottom of the tree. I understand why it's phrased this way, but it's rather jarring. I think it would really clarify things to include an algorithm, e.g. 1. set type to the typecode of the LMS algorithm 2. using the current value q from the LMS private key, create the LM-OTS signature for the message, using OTS_PRIV[q] 3. compute the array path as follows: r = 2^h + q i = 0 while (r > 1) { if (r is odd): path[i] = T[r-1] else path[i] = T[r+1] r = r/2 i = i + 1 } 4. S = u32str(q) || ots_signature || u32str(type) || path 5. q = q + 1 6. return S 6. Hierarchical signatures This is the most under-specified part of the whole document, which is unfortunate, because it's the point of the whole document. The prose should describe the rationale and form of the tree-of-trees (as I suggested above), and there should be pseudo-code. It's also worth explaining that the meta-tree is conceptual, as only one tree at each level is instantiated at a time. On a first reading, it appears to be a list of trees rather than a tree of trees. Perhaps there should be a Parameters subsection, to discuss the number of levels L. There isn't an algorithm or symbol associated with it, but it still needs to be established before anything is instantiated. L has a maximum value of 8, which seems oddly prescriptive. Is there an engineering reason for that limit? The HSS scheme can sign a maximum of 2^200 messages with h=25, which is pretty huge, but only 2^40 messages with h=5. I'm not trying to cause trouble, but I get curious when I see magic numbers. HSS does not require all trees to use the same LMS type code (i.e. to be the same height). While most reasonable people would use same-height trees, is there a use case for trees of different heights (or even different hash algorithms, once there are codes to support that)? It seems like there should be some guidance here. 6.1. Key Generation While it's true that only the root tree needs to be instantiated before the public key is published, the child trees need to be instantiated before any messages can be signed, so I'd prefer to do that in the key generation process. Again, this would really benefit from some pseudo-code, e.g. 1. generate L LMS key pairs, as specified in sections 5.2 and 5.3 2. sign each child public key with the private key of its parent: i = 0 while (i < L-1) { sig[i] = lms_signature(pub[i+1], priv[i]) i = i + 1 } 3. return u32str(L) || pub[0] As a notational issue, I think of the signature as belonging with the thing being signed, rather than with the key that is used to sign it, e.g. 2. sign each non-root public key with the private key of its parent: i = 1 while (i < L) { sig[i] = lms_signature(pub[i], priv[i-1]) i = i + 1 } I understand that it's done the first way so that sig[L-1] can be the signature of the message, but that could be designated sig_msg or some other way. 6.2. Signature Generation This is harder to pseudo-code, given the number of things that need to be explained. 1. If the message-signing key prv[L-1] is exhausted, regenerate that key pair, together with any parent key pairs that might be necessary. If the root key pair is exhausted, then the HSS key pair is exhausted, and it MUST NOT generate any more signatures. if (prv[L-1].q == 2^h) { d = L-1 while (prv[d-1].q == 2^h) { if (d == 0) return FAILURE d = d - 1 } while (d < L) { regenerate keypair pub[d], prv[d] sign pub[d] with prv[d-1] } } 2. Sign the message sig[L-1] = lms_sign(msg, prv[L-1]) 3. Create the list of signed public keys i = 0 while (i < L-1) { signed_pub_key[i] = sig[i] || pub[i+1] i = i + 1 } 4. return u32str(L-1) || signed_pub_key[0] || ... || signed_pub_key[L-2] || sig[L-1] 7. Formats I would prefer to rename some of the types for consistency: ots_algorithm_type -> lmots_algorithm_type ots_signature -> lmots_signature hbs_algorithm_type -> lms_algorithm_type hbs_reserved -> lms_reserved hbs_public_key -> lms_public_key Why is there a gap between hbs_reserved and lms_sha256_n32_h5? Is it because the completely different enum ots_algorithm_type has values 1-4? Many of the objects start with a typecode. A verifier MUST check each of these typecodes, and a verification operation on a signature with an unknown type, or a type that does not correspond to the type within the public key MUST return INVALID. The expected length of a variable-length object can be determined from its typecode, and if an object has a different length, then any signature computed from the object is INVALID. This seems out of place in a section devoted to XDR formats. From nobody Wed Nov 15 00:54:12 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2F9129474 for ; Wed, 15 Nov 2017 00:54:11 -0800 (PST) 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 (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 oZ6PZw6qYTVr for ; Wed, 15 Nov 2017 00:54:08 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 F05D012947E for ; Wed, 15 Nov 2017 00:54:03 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF8pfNV023422 for ; Wed, 15 Nov 2017 08:54:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=/BToZFaC/AberZrUAkXw07x2s4k44HLj2jTFVoZ6l/0=; b=U+nDrBmjxgwUtGvZhKgsLe8F9MUUQlNTW1RSxiCQgAul0fozEIfc9QfXdc/8mDG6s1BC /5AnTP6TIa2aafwL/ipvjSQ2ql+I6Hgs3qAUS/9LbZvw6RabUfc78QfoIDQV/1asqTYG 1L8MxVFW3l58c1JxkvN9P3j/TryWSIfa+jRGfgzZ2hkS2p+Unk/7GF1sASrXdcbpNX65 weWNu0MEaQ0kLhwx4RqYtWvNklZrsHCzPXXlmVaUu3Yk9yAzn27imRgMXWBlw1ZdB5nf t9DWvylXOiU8KkLIYaFxPJ5V5awfrjIpnLYiCUCtSSjXDdC6OczslWYzw0fHxl4tIpLf iA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2e8d5prkqj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Nov 2017 08:54:01 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF8pIb9022986 for ; Wed, 15 Nov 2017 03:54:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wmn68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Nov 2017 03:54:00 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 03:53:58 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 03:53:58 -0500 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; Wed, 15 Nov 2017 03:53:58 -0500 From: "Salz, Rich" To: "cfrg@irtf.org" Thread-Topic: Draft minutes for CFRG at IETF 100 meeting Thread-Index: AQHTXe9FbaXqVW5R6U+W3eb+UK7+NQ== Date: Wed, 15 Nov 2017 08:53:57 +0000 Message-ID: <863761D0-A32B-4C05-A476-AFDE4E2A9F12@akamai.com> 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.147.38] Content-Type: multipart/alternative; boundary="_000_863761D0A32B4C05A476AFDE4E2A9F12akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-15_04:, , 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-1709140000 definitions=main-1711150127 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-15_04:, , 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-1709140000 definitions=main-1711150127 Archived-At: Subject: [Cfrg] Draft minutes for CFRG at IETF 100 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: Wed, 15 Nov 2017 08:54:11 -0000 --_000_863761D0A32B4C05A476AFDE4E2A9F12akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q3J5cHRvIEZvcnVtIFJlc2VhcmNoIEdyb3VwDQpXZWRzIDE1IG5vdiAxNywgYWZ0ZXJub29uIElJ DQpBbGV4c2V5IGNoYWlyaW5nDQpSaWNoIFNhbHogbWludXRlcw0KWW9hdiBOaXIgamFiYmVyIHNj cmliZQ0KDQpEb2Mgc3RhdHVzDQogICAgICAgICAgICAgICAgU2VlIGNoYWlyIHNsaWRlcyBmb3Ig ZGV0YWlscw0KDQpDcnlwdG8gUmV2aWV3IHBhbmVsDQogICAgICAgICAgICAgICAgTG90cyBvZiBn b29kIHJldmlld3MgZG9uZQ0KDQpSZS1rZXlpbmcgbWVjaGFuaXNtcyBmb3Igc3ltbWV0cmljIGtl eXMsIFN0YW5pc2xhdiBTbXlzaGx5YWV2DQogICAgICAgICAgICAgICAgRXhwbGFuYXRpb24gb2Yg Z29hbHMsIHJlc3BvbnNlIHRvIHJldmlld3MgYW5kIGZlZWRiYWNrLiBQbGFuIHRvIGdldCB2ZXJz aW9uIGFkZHJlc3NpbmcgZXhpc3RpbmcgcmV2aWV3cyBieSBlbmQgb2YgSmFudWFyeS4NCiAgICAg ICAgICAgICAgICBRJkEgYWJvdXQgaG93IHRvIHNpZ25hbCByZS1rZXkgaW4sIGZvciBleGFtcGxl LCBub24tVExTIHVzZXMNCg0KVHJhbnNpdGlvbiBmcm9tIGNsYXNzaWNhbCB0byBQb3N0LVF1YW50 dW0gQ3J5cHRvZ3JhcGh5LCBQYXVsIEhvZmZtYW4NCiAgICAgICAgICAgICAgICAoTGFzdCB0aW1l IEtlbm55IHNwb2tlLCBQYXVsIHdhc27igJl0IHByZXNlbnQ7IHRoaXMgdGltZSBQYXVs4oCZcyBw cmVzZW50IGFuZCBLZW5ueSBpc27igJl0LiAgSG1tKQ0KICAgICAgICAgICAgICAgIEhlbHBpbmcg cGVvcGxlIHdobyBsaWtlIHRvIG1ha2UgcHJlZGljdGlvbnMsIG1ha2UgcHJlZGljdGlvbnMNCiAg ICAgICAgICAgICAgICBQcm9wb3NlZCBDRlJHIGFkb3B0aW9uLiAgQ29uc2Vuc3VzIGluIHJvb20g d2FzIHN0cm9uZ2x5IGluIGZhdm9yLCBzb21lIG5lZWQgbW9yZSBpbmZvLiBUbyBiZSBjb25maXJt ZWQgb24gdGhlIGxpc3QuDQogICAgICAgICAgICAgICAgUSZBIGFib3V0IG51bSBvZiBxdWJpdHMg bmVlZGVkIGZvciAySyBSU0EsIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIHNtYWxsZXItc2l6ZWQg bWFjaGluZXMsIGFuZCBwcmFjdGljYWxpdHkgb2YgdXNpbmcgKG11Y2gpIGxhcmdlciBjdXJ2ZXMg d2l0aCBleGlzdGluZyBhbGdvcml0aG1zDQogICAgICAgICAgICAgICAgR2V0IHlvdXIgZnJpZW5k cyB0byBoZWxwIHJldmlldyBhbmQvb3IgcHJvdmlkZSBjb250ZW50IQ0KDQpTUEFLRTIsIGEgUEFL RSwgQmVuamFtaW4gS2FkdWsNCiAgICAgICAgICAgICAgICBFeHBpcmVkIGJhY2sgaW4gRmVicnVh cnkgMjAxNiwgYW5kIEJlbiBwaWNrZWQgaXQgdXAgYW5kIGhhcyBhIG5ldyB2ZXJzaW9uIGNvbWlu ZyBvdXQNCiAgICAgICAgICAgICAgICBJbml0aWFsIHVzZS1jYXNlIGlzIEtSQiBwcmUtYXV0aCBi ZWZvcmUgZ2V0dGluZyBhIHRpY2tldDsgdGhlcmXigJlzIG90aGVycw0KICAgICAgICAgICAgICAg IFEmQSBvbiB0ZWNoIGRldGFpbHMsIGFuZCBwb2ludGluZyBvdXQgdGhlIOKAnHBha2UgcmVxdWly ZW1lbnRz4oCdIFJGQyB0aGF0IHRoaXMgc2hvdWxkIHJlZmVyZW5jZQ0KDQpQRUtYLCBQdWJsaWMg S2V5IEV4Y2hhbmdlIERhbiBIYXJraW5zDQogICAgICAgICAgICAgICAgRGVmaW5lIGEgd2F5IHRv IGV4Y2hhbmdlIOKAmHJhd+KAmSBwdWJsaWMga2V5cywgaW5jbHVkaW5nIGF1dGggYW5kIGJpbmRp bmcgYW4gaWRlbnRpdHkNCiAgICAgICAgICAgICAgICBIYXMgaGFkICBjcnlwdG8gcmV2aWV3LCBo YXMgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMNCiAgICAgICAgICAgICAgICBMb29raW5n IHRvIGhhdmUgQ0ZSRyBhZG9wdGlvbjsgaW5zdWZmaWNpZW50IHJlYWRlcnMgaW4gcm9vbSwgd2ls bCB0YWtlIHRvIHRoZSBsaXN0DQogICAgICAgICAgICAgICAgUSZBIGFib3V0IGlkZW50aXR5LCBi aW5kaW5nIHRvIGtleSBldGMNCg0KQ3J5cHRvZ3JhcGhpY2FsbHkgdHJhdmVyc2FibGUgYmxvY2tj aGFpbnMgb3Ig4oCYc2tpcGNoYWluc+KAmSBCcnlhbiBGb3JkDQogICAgICAgICAgICAgICAgQWRk cmVzc2luZyBwcm9ibGVtIG9mIGVmZmljaWVudCB2ZXJpZmljYXRpb24gb2YgYmxvY2sgY2hhaW5z IOKAkyBob3cgdG8g4oCcY2F0Y2ggdXDigJ0gb24gc3RhdGUNCiAgICAgICAgICAgICAgICBTZWUg 4oCcQ2hhaW5pYWPigJ0gcGFwZXIgaW4gVXNlbml4IFNlY3VyaXR5IDIwMTcgcHJvY2VlZGluZ3Mg KHdoaWNoIGhhcyBtb3JlIHRoYW4ganVzdCB0aGUgc2tpcGNoYWluIGNyeXB0b2dyYXBoaWMgc3Ry dWN0dXJlKQ0KICAgICAgICAgICAgICAgIFEmQSBhYm91dCBzaWduaW5nIHJvc3RlciBjaGFuZ2Vz LCBhbmQgcGlja2luZyB0cnVzdGVkIGVudGl0aWVzIChzZWUgcGFwZXIpDQoNCg0K --_000_863761D0A32B4C05A476AFDE4E2A9F12akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DcnlwdG8gRm9ydW0gUmVzZWFyY2ggR3Jv dXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+V2VkcyAxNSBub3YgMTcsIGFmdGVybm9vbiBJSTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BbGV4c2V5IGNoYWlyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJpY2ggU2FseiBt aW51dGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvYXYgTmlyIGphYmJlciBzY3JpYmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRvYyBzdGF0dXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlZSBjaGFpciBzbGlkZXMg Zm9yIGRldGFpbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNy eXB0byBSZXZpZXcgcGFuZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IExvdHMgb2YgZ29vZCByZXZpZXdzIGRvbmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlLWtleWluZyBtZWNoYW5pc21zIGZvciBzeW1tZXRy aWMga2V5cywgU3RhbmlzbGF2IFNteXNobHlhZXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGxhbmF0aW9uIG9mIGdvYWxzLCByZXNwb25zZSB0 byByZXZpZXdzIGFuZCBmZWVkYmFjay4gUGxhbiB0byBnZXQgdmVyc2lvbiBhZGRyZXNzaW5nIGV4 aXN0aW5nIHJldmlld3MgYnkgZW5kIG9mIEphbnVhcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBRJmFtcDtBIGFib3V0IGhvdyB0byBzaWduYWwg cmUta2V5IGluLCBmb3IgZXhhbXBsZSwgbm9uLVRMUyB1c2VzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UcmFuc2l0aW9uIGZyb20gY2xhc3NpY2FsIHRvIFBvc3Qt UXVhbnR1bSBDcnlwdG9ncmFwaHksIFBhdWwgSG9mZm1hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKExhc3QgdGltZSBLZW5ueSBzcG9rZSwgUGF1 bCB3YXNu4oCZdCBwcmVzZW50OyB0aGlzIHRpbWUgUGF1bOKAmXMgcHJlc2VudCBhbmQgS2Vubnkg aXNu4oCZdC4mbmJzcDsgSG1tKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSGVscGluZyBwZW9wbGUgd2hvIGxpa2UgdG8gbWFrZSBwcmVkaWN0aW9u cywgbWFrZSBwcmVkaWN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUHJvcG9zZWQgQ0ZSRyBhZG9wdGlvbi4mbmJzcDsgQ29uc2Vuc3VzIGlu IHJvb20gd2FzIHN0cm9uZ2x5IGluIGZhdm9yLCBzb21lIG5lZWQgbW9yZSBpbmZvLiBUbyBiZSBj b25maXJtZWQgb24gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBRJmFtcDtBIGFib3V0IG51bSBvZiBxdWJpdHMgbmVlZGVkIGZvciAy SyBSU0EsIHBvc3NpYmlsaXR5IG9mIG11bHRpcGxlIHNtYWxsZXItc2l6ZWQgbWFjaGluZXMsIGFu ZCBwcmFjdGljYWxpdHkgb2YgdXNpbmcgKG11Y2gpIGxhcmdlciBjdXJ2ZXMgd2l0aCBleGlzdGlu ZyBhbGdvcml0aG1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHZXQgeW91ciBmcmllbmRzIHRvIGhlbHAgcmV2aWV3IGFuZC9vciBwcm92aWRlIGNv bnRlbnQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TUEFLRTIs IGEgUEFLRSwgQmVuamFtaW4gS2FkdWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZWQgYmFjayBpbiBGZWJydWFyeSAyMDE2LCBhbmQgQmVu IHBpY2tlZCBpdCB1cCBhbmQgaGFzIGEgbmV3IHZlcnNpb24gY29taW5nIG91dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5pdGlhbCB1c2UtY2Fz ZSBpcyBLUkIgcHJlLWF1dGggYmVmb3JlIGdldHRpbmcgYSB0aWNrZXQ7IHRoZXJl4oCZcyBvdGhl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFEm YW1wO0Egb24gdGVjaCBkZXRhaWxzLCBhbmQgcG9pbnRpbmcgb3V0IHRoZSDigJxwYWtlIHJlcXVp cmVtZW50c+KAnSBSRkMgdGhhdCB0aGlzIHNob3VsZCByZWZlcmVuY2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBFS1gsIFB1YmxpYyBLZXkgRXhjaGFuZ2UgRGFu IEhhcmtpbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IERlZmluZSBhIHdheSB0byBleGNoYW5nZSDigJhyYXfigJkgcHVibGljIGtleXMsIGluY2x1 ZGluZyBhdXRoIGFuZCBiaW5kaW5nIGFuIGlkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIYXMgaGFkJm5ic3A7IGNyeXB0byByZXZpZXcs IGhhcyBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTG9va2luZyB0byBoYXZlIENGUkcgYWRvcHRp b247IGluc3VmZmljaWVudCByZWFkZXJzIGluIHJvb20sIHdpbGwgdGFrZSB0byB0aGUgbGlzdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUSZhbXA7 QSBhYm91dCBpZGVudGl0eSwgYmluZGluZyB0byBrZXkgZXRjPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DcnlwdG9ncmFwaGljYWxseSB0cmF2ZXJzYWJsZSBibG9j a2NoYWlucyBvciDigJhza2lwY2hhaW5z4oCZIEJyeWFuIEZvcmQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZHJlc3NpbmcgcHJvYmxlbSBvZiBl ZmZpY2llbnQgdmVyaWZpY2F0aW9uIG9mIGJsb2NrIGNoYWlucyDigJMgaG93IHRvIOKAnGNhdGNo IHVw4oCdIG9uIHN0YXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTZWUg4oCcQ2hhaW5pYWPigJ0gcGFwZXIgaW4gVXNlbml4IFNlY3VyaXR5IDIw MTcgcHJvY2VlZGluZ3MgKHdoaWNoIGhhcyBtb3JlIHRoYW4ganVzdCB0aGUgc2tpcGNoYWluIGNy eXB0b2dyYXBoaWMgc3RydWN0dXJlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUSZhbXA7QSBhYm91dCBzaWduaW5nIHJvc3RlciBjaGFuZ2VzLCBh bmQgcGlja2luZyB0cnVzdGVkIGVudGl0aWVzIChzZWUgcGFwZXIpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_863761D0A32B4C05A476AFDE4E2A9F12akamaicom_-- From nobody Wed Nov 15 23:11: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 4FBAB1293E0 for ; Wed, 15 Nov 2017 23:11:27 -0800 (PST) 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 (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 EC0ziQIlx65Z for ; Wed, 15 Nov 2017 23:11:25 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 B4FD612702E for ; Wed, 15 Nov 2017 23:11:25 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAG77h38006806 for ; Thu, 16 Nov 2017 07:11:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=q2hfjdP+iMlK6EphBUVKWxZLCho83gjzElOdgoPbyds=; b=gzElnzmQHEk1wUhMhOj5E/lvSOh+WqU3KHyNm7uTj+WECzbGyQ/2pi/4r4lodVFvGlgl zju2zkAchKe95uWY7P0NirSIrf8AdNcdZjsOjsjJwvbCqczyuG0DSU4Vc/ST/NqIWHzJ B2/ubd0MASirvHUD8romc3yMkCBhu09JtLefMSitVQsBGSZq1sqGWHkudIi5fXQe2bJp qQuYs4FAhWTcTDhst4SmPAQSYcyRFIBez8xs2dOtiRAwmfnKC4ZfP24y/KHVi8q+z6e8 XazZ+GgVNe+X7P3XV7PEsdGM37ENFz+WQCxcj9sITsfEptE9OkPeMO9R64/nJi5V4mJP sw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2e8d4pujtv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Nov 2017 07:11:24 +0000 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 vAG7AUSm023306 for ; Thu, 16 Nov 2017 02:11:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e7p3wrfn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 16 Nov 2017 02:11:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Nov 2017 02:11:10 -0500 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; Thu, 16 Nov 2017 02:11:10 -0500 From: "Salz, Rich" To: "cfrg@irtf.org" Thread-Topic: I like PKEX Thread-Index: AQHTXqoTZAQltIulBkOMVFlFBjIuLg== Date: Thu, 16 Nov 2017 07:11:09 +0000 Message-ID: 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.147.27] Content-Type: multipart/alternative; boundary="_000_EA0997AC6EB9464985029A185A77760Dakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , 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-1709140000 definitions=main-1711160101 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160100 Archived-At: Subject: [Cfrg] I like PKEX 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, 16 Nov 2017 07:11:27 -0000 --_000_EA0997AC6EB9464985029A185A77760Dakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgUEtFWCBzdHVmZiBpcyB2ZXJ5IGludGVyZXN0aW5nLiAgSXQgaW52ZXJ0cyB0 aGUgdHJ1c3QgbW9kZWwgdXNlZCBvbiB0aGUgV2ViLiAgIFN1cHBvc2UgSSB3YW50IHRvIGRvIHNv bWUgb25saW5lIGJhbmtpbmcgd2l0aCBteWJhbmsuY29tLiBNeSBicm93c2VyIGNoZWNrcyB0aGUg c2VydmVyIGNlcnQsIGFuZCBkZWNpZGVkIHRvIHRydXN0IGl0IGlmIHRoZSBDQSB2ZXJpZmllcyB0 aGUgaWRlbnRpdHkuIEkgdGhlbiB0eXBlIG15IG5hbWUgYW5kIHBhc3N3b3JkIGludG8gdGhlIHdl YnNpdGUuIFRoZXJlIGlzIGEgcmlzayBpZiBJIGVuZCB1cCBhdCB0aGUgd3Jvbmcgd2Vic2l0ZS4N Cg0KV2l0aCBQS0VYLCBJIGNhbiB1c2UgbXkgbmFtZSBhbmQgcGFzc3dvcmQgYW5kIHRoZSBiYW5r IGNhbiB1c2Ugc29tZXRoaW5nIGxpa2UgbXkgYWNjb3VudCBudW1iZXIgb3Igb3RoZXIgc2ltaWxh ciBpbmZvLCBhbmQgd2UgZXhjaGFuZ2UgYW5kIGdldCBhIHNoYXJlZCBzZWNyZXQuIFdlIHRoZW4g dXNlIHRoYXQgc2VjcmV0IHRvIGdldCBhbiBhdXRoZW50aWNhdGVkIEVDRFNBIGtleSBhbmQgdGhl biBJIHN3aXRjaCB0byBUTFMgYW5kIGdldCBpdHMgYmVuZWZpdHMuICBObyB0aGlyZC1wYXJ0eSB0 cnVzdCBpcyBuZWVkZWQuDQoNCkkgdGhpbmsgdGhpcyBzb2x2ZXMgYW4gaW50ZXJlc3RpbmcgdXNl LWNhc2UgYW5kIGl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBpdCBpbiBvdXIgdG9vbGJveC4NCg0K --_000_EA0997AC6EB9464985029A185A77760Dakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <359E98361285D04EBDE73F7AF1CF5807@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHRoaW5rIHRoZSBQS0VYIHN0dWZmIGlz IHZlcnkgaW50ZXJlc3RpbmcuJm5ic3A7IEl0IGludmVydHMgdGhlIHRydXN0IG1vZGVsIHVzZWQg b24gdGhlIFdlYi4mbmJzcDsmbmJzcDsgU3VwcG9zZSBJIHdhbnQgdG8gZG8gc29tZSBvbmxpbmUg YmFua2luZyB3aXRoIG15YmFuay5jb20uIE15IGJyb3dzZXIgY2hlY2tzIHRoZSBzZXJ2ZXIgY2Vy dCwgYW5kIGRlY2lkZWQgdG8gdHJ1c3QNCiBpdCBpZiB0aGUgQ0EgdmVyaWZpZXMgdGhlIGlkZW50 aXR5LiBJIHRoZW4gdHlwZSBteSBuYW1lIGFuZCBwYXNzd29yZCBpbnRvIHRoZSB3ZWJzaXRlLiBU aGVyZSBpcyBhIHJpc2sgaWYgSSBlbmQgdXAgYXQgdGhlIHdyb25nIHdlYnNpdGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XaXRoIFBLRVgsIEkgY2FuIHVzZSBt eSBuYW1lIGFuZCBwYXNzd29yZCBhbmQgdGhlIGJhbmsgY2FuIHVzZSBzb21ldGhpbmcgbGlrZSBt eSBhY2NvdW50IG51bWJlciBvciBvdGhlciBzaW1pbGFyIGluZm8sIGFuZCB3ZSBleGNoYW5nZSBh bmQgZ2V0IGEgc2hhcmVkIHNlY3JldC4gV2UgdGhlbiB1c2UgdGhhdCBzZWNyZXQgdG8gZ2V0IGFu IGF1dGhlbnRpY2F0ZWQNCiBFQ0RTQSBrZXkgYW5kIHRoZW4gSSBzd2l0Y2ggdG8gVExTIGFuZCBn ZXQgaXRzIGJlbmVmaXRzLiZuYnNwOyBObyB0aGlyZC1wYXJ0eSB0cnVzdCBpcyBuZWVkZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHRoaW5rIHRoaXMgc29s dmVzIGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGFuZCBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUg aXQgaW4gb3VyIHRvb2xib3guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EA0997AC6EB9464985029A185A77760Dakamaicom_-- From nobody Wed Nov 15 23:21:07 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 A432B12950A for ; Wed, 15 Nov 2017 23:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 rPWnXII8urLY for ; Wed, 15 Nov 2017 23:21:04 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429251293E0 for ; Wed, 15 Nov 2017 23:21:04 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id b189so7435076wmd.0 for ; Wed, 15 Nov 2017 23:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TjCRtcxftXPxp2AkVeol9MFqltblE9Pfe5xvQVaT+1c=; b=GEnnFdI/fzWxcCcCU3Zj8k0CZ7r1VqWM8HpDF1vZh/hQ2b23fJ5rH1c/MpULRMS0b7 1IQKizQnHvmDa9TFAqKn8NuIwc6mmktczed3NAoaBKolXIXHSuIZcgWR6WBuJN/MCxOw qfebJx75e6hV+D6Q+owVxqf9XUW8qeyjh4LpkaenDcaLokLb0nhYT6pB2D0Q7MkgazvW S7J9OqBaz44sCp69N73OIBGZtmMz6IwIGV7BNZ2l1k1I4RybT703Cqp8wisDqetTwSaV ZALj1Cc3AF2J3Q/BlHEiIs9ksz1dUO/v+bozAd7yMrw2cYI9epge3LOHdibOxJ40CXL+ SYmQ== 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=TjCRtcxftXPxp2AkVeol9MFqltblE9Pfe5xvQVaT+1c=; b=o0XWLZxR0KbFRYi2ZpT4YaTjoBujYatwghOwgh+DcD/KXzpphPsU99rxNrpM/AdlRs Bm7KNuCJzizrrwCCTqwv1/P6AYj+HLbMEmwmQURMr7DT91bNNbP81R3gv87bxIKeEi/k Hys/CfD8r1ayb1yxYCYEOLl7Bol5Apl+1tDd3FzkcK3SvXfwJiGLsGl/knSeSD9EDXXA +2c7ayByvbPRIeeTDeqpBJXFsZjnM7loY6EgQi7MY82FctBCncSzTo+PfFa51wrh5m3C oh8hKPsiLQK0mn1UwjIvyuT4W+lfzCCixCCYFEJzgqaWA8wqATA+g9wrnxywMvfECfvE 5EOA== X-Gm-Message-State: AJaThX6OziepaSBhQ1OXbwQPo7cO6zF6nl2Zjmi/yBB5WT5WCVQGntCA r3CfVLK8UkK0izxd0njawuiwjIKhe54mxE64TxQPeA== X-Google-Smtp-Source: AGs4zMaQg6L6i4NUOnc0BBUm/Zi60+bzi4XNGDFDoiqHNg2x2AYXugEBUvcT/tbqF1mmVUv3L/vw7varoLzLlsc3Ke4= X-Received: by 10.28.69.91 with SMTP id s88mr679832wma.19.1510816862609; Wed, 15 Nov 2017 23:21:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 15 Nov 2017 23:21:02 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Thu, 16 Nov 2017 15:21:02 +0800 Message-ID: To: "Salz, Rich" Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="94eb2c0723a66ab935055e1476a7" Archived-At: Subject: Re: [Cfrg] I like PKEX 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, 16 Nov 2017 07:21:06 -0000 --94eb2c0723a66ab935055e1476a7 Content-Type: text/plain; charset="UTF-8" Sorry, what is PKEX? On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich wrote: > I think the PKEX stuff is very interesting. It inverts the trust model > used on the Web. Suppose I want to do some online banking with > mybank.com. My browser checks the server cert, and decided to trust it if > the CA verifies the identity. I then type my name and password into the > website. There is a risk if I end up at the wrong website. > > > > With PKEX, I can use my name and password and the bank can use something > like my account number or other similar info, and we exchange and get a > shared secret. We then use that secret to get an authenticated ECDSA key > and then I switch to TLS and get its benefits. No third-party trust is > needed. > > > > I think this solves an interesting use-case and it would be nice to have > it in our toolbox. > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --94eb2c0723a66ab935055e1476a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, what is PKEX?
<= br>
On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <= span dir=3D"ltr"><= rsalz@akamai.com> wrote:

I think the PKEX st= uff is very interesting.=C2=A0 It inverts the trust model used on the Web.= =C2=A0=C2=A0 Suppose I want to do some online banking with mybank.com. My browser checks the serve= r cert, and decided to trust it if the CA verifies the identity. I then type my name and password into = the website. There is a risk if I end up at the wrong website.

=C2=A0

With PKEX, I can us= e my name and password and the bank can use something like my account numbe= r or other similar info, and we exchange and get a shared secret. We then u= se that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.=C2=A0 No third-pa= rty trust is needed.

=C2=A0

I think this solves= an interesting use-case and it would be nice to have it in our toolbox.=

=C2=A0


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


--94eb2c0723a66ab935055e1476a7-- From nobody Wed Nov 15 23:22: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 ED7751294F0 for ; Wed, 15 Nov 2017 23:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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 7XELxGDBmtn0 for ; Wed, 15 Nov 2017 23:22:35 -0800 (PST) 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 2440D12894A for ; Wed, 15 Nov 2017 23:22:35 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAG7HM0W004065; Thu, 16 Nov 2017 07:22:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=xGjfuFPE5sSgeNHef19yiKdf+jbYbQL1EwVy50ZIVJk=; b=fA8F2D7ilNVl+oW018IZxraF1ApE4/0NnKRojPWUz5hLarGBjJUtv36dga1NirRvrcFH sUCFOUQ92Z3FdIo27dhwIJFvE4TXvBD4y4KZ169lYhB99n0yUbzefGt47OtAMvCEMfqK 06d3kmZ++tWQJft/74U2zH1aFX+aNHv/D8L6Py+w6RT7ooM09iBQDpeTtuPl97AxmWLq CEb7HnoK2LlO6ApR7rYyo6R/G00tyfWY+mR8iQjisAtANXR1X4XuUOxhbU3qiyAomfL3 yerEIN970PoBTGU/HtKv5J9I75sjYGIq1jmimQEQhyfaVlg79e3iqCP+Wtp5HgjKdW7C Cg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2e8d5kku6d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2017 07:22:32 +0000 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 vAG7HXEl030866; Thu, 16 Nov 2017 02:22:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e7p3wrh6g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2017 02:22:31 -0500 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; Thu, 16 Nov 2017 02:22:30 -0500 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; Thu, 16 Nov 2017 02:22:30 -0500 From: "Salz, Rich" To: Richard Barnes CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] I like PKEX Thread-Index: AQHTXqoTZAQltIulBkOMVFlFBjIuLqMW7WcAgAAAaIA= Date: Thu, 16 Nov 2017 07:22:29 +0000 Message-ID: <4284CE2B-1D0C-421A-BEF1-8B319C252851@akamai.com> References: In-Reply-To: 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.147.27] Content-Type: multipart/alternative; boundary="_000_4284CE2B1D0C421ABEF18B319C252851akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , 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-1709140000 definitions=main-1711160102 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160102 Archived-At: Subject: Re: [Cfrg] I like PKEX 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, 16 Nov 2017 07:22:37 -0000 --_000_4284CE2B1D0C421ABEF18B319C252851akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9tYXRlcmlhbHMvc2xpZGVz LTEwMC1jZnJnLXB1YmxpYy1rZXktZXhjaGFuZ2UvDQoNClNvcnJ5LCB3aGF0IGlzIFBLRVg/DQoN Ck9uIFRodSwgTm92IDE2LCAyMDE3IGF0IDM6MTEgUE0sIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1h aS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCkkgdGhpbmsgdGhlIFBLRVgg c3R1ZmYgaXMgdmVyeSBpbnRlcmVzdGluZy4gIEl0IGludmVydHMgdGhlIHRydXN0IG1vZGVsIHVz ZWQgb24gdGhlIFdlYi4gICBTdXBwb3NlIEkgd2FudCB0byBkbyBzb21lIG9ubGluZSBiYW5raW5n IHdpdGggbXliYW5rLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9fbXliYW5rLmNvbSZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09M25ySnBfRWpYWTBnb2NMYUJNenVkb0padVZ3aTNj OUpjYlBUbDdtREJFZyZzPTRYTEJwWmh6c25sWlFrVUlUZ0tNOUJDeGM5Q1N1amxiTDNlTTVteHlI bTgmZT0+LiBNeSBicm93c2VyIGNoZWNrcyB0aGUgc2VydmVyIGNlcnQsIGFuZCBkZWNpZGVkIHRv IHRydXN0IGl0IGlmIHRoZSBDQSB2ZXJpZmllcyB0aGUgaWRlbnRpdHkuIEkgdGhlbiB0eXBlIG15 IG5hbWUgYW5kIHBhc3N3b3JkIGludG8gdGhlIHdlYnNpdGUuIFRoZXJlIGlzIGEgcmlzayBpZiBJ IGVuZCB1cCBhdCB0aGUgd3Jvbmcgd2Vic2l0ZS4NCg0KV2l0aCBQS0VYLCBJIGNhbiB1c2UgbXkg bmFtZSBhbmQgcGFzc3dvcmQgYW5kIHRoZSBiYW5rIGNhbiB1c2Ugc29tZXRoaW5nIGxpa2UgbXkg YWNjb3VudCBudW1iZXIgb3Igb3RoZXIgc2ltaWxhciBpbmZvLCBhbmQgd2UgZXhjaGFuZ2UgYW5k IGdldCBhIHNoYXJlZCBzZWNyZXQuIFdlIHRoZW4gdXNlIHRoYXQgc2VjcmV0IHRvIGdldCBhbiBh dXRoZW50aWNhdGVkIEVDRFNBIGtleSBhbmQgdGhlbiBJIHN3aXRjaCB0byBUTFMgYW5kIGdldCBp dHMgYmVuZWZpdHMuICBObyB0aGlyZC1wYXJ0eSB0cnVzdCBpcyBuZWVkZWQuDQoNCkkgdGhpbmsg dGhpcyBzb2x2ZXMgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgYW5kIGl0IHdvdWxkIGJlIG5pY2Ug dG8gaGF2ZSBpdCBpbiBvdXIgdG9vbGJveC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KQ2ZyZyBtYWlsaW5nIGxpc3QNCkNmcmdAaXJ0Zi5vcmc8 bWFpbHRvOkNmcmdAaXJ0Zi5vcmc+DQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nmcmc8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaXJ0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19jZnJnJmQ9RHdNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT0zbnJKcF9FalhZMGdv Y0xhQk16dWRvSlp1VndpM2M5SmNiUFRsN21EQkVnJnM9eUstRFN3Zm5oUGtmV1BINFFNNWJENDN5 TXBSWkNkUFpRR0E4VlVhNkFEVSZlPT4NCg0K --_000_4284CE2B1D0C421ABEF18B319C252851akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <81BC8E9708F0F74CB36ACF48621B8341@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFscy9zbGlkZXMtMTAwLWNmcmctcHVibGlj LWtleS1leGNoYW5nZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDAv bWF0ZXJpYWxzL3NsaWRlcy0xMDAtY2ZyZy1wdWJsaWMta2V5LWV4Y2hhbmdlLzwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5LCB3aGF0IGlzIFBLRVg/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAxNiwgMjAxNyBh dCAzOjExIFBNLCBTYWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSB0aGluayB0aGUgUEtFWCBzdHVmZiBpcyB2ZXJ5IGludGVyZXN0aW5nLiZuYnNwOyBJdCBp bnZlcnRzIHRoZSB0cnVzdCBtb2RlbCB1c2VkIG9uIHRoZSBXZWIuJm5ic3A7Jm5ic3A7IFN1cHBv c2UgSSB3YW50IHRvIGRvIHNvbWUgb25saW5lIGJhbmtpbmcgd2l0aA0KPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX215YmFuay5jb20m YW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBo OUZ2eDg2RnRzS0ktdyZhbXA7bT0zbnJKcF9FalhZMGdvY0xhQk16dWRvSlp1VndpM2M5SmNiUFRs N21EQkVnJmFtcDtzPTRYTEJwWmh6c25sWlFrVUlUZ0tNOUJDeGM5Q1N1amxiTDNlTTVteHlIbTgm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpteWJhbmsuY29tPC9hPi4gTXkgYnJvd3NlciBjaGVj a3MgdGhlIHNlcnZlciBjZXJ0LCBhbmQgZGVjaWRlZCB0byB0cnVzdCBpdCBpZiB0aGUgQ0EgdmVy aWZpZXMgdGhlIGlkZW50aXR5LiBJIHRoZW4gdHlwZSBteSBuYW1lIGFuZCBwYXNzd29yZCBpbnRv IHRoZSB3ZWJzaXRlLiBUaGVyZSBpcyBhIHJpc2sgaWYgSSBlbmQgdXAgYXQgdGhlIHdyb25nIHdl YnNpdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIFBLRVgsIEkgY2FuIHVzZSBt eSBuYW1lIGFuZCBwYXNzd29yZCBhbmQgdGhlIGJhbmsgY2FuIHVzZSBzb21ldGhpbmcgbGlrZSBt eSBhY2NvdW50IG51bWJlciBvciBvdGhlciBzaW1pbGFyIGluZm8sIGFuZCB3ZSBleGNoYW5nZSBh bmQgZ2V0IGEgc2hhcmVkIHNlY3JldC4gV2UgdGhlbiB1c2UgdGhhdA0KIHNlY3JldCB0byBnZXQg YW4gYXV0aGVudGljYXRlZCBFQ0RTQSBrZXkgYW5kIHRoZW4gSSBzd2l0Y2ggdG8gVExTIGFuZCBn ZXQgaXRzIGJlbmVmaXRzLiZuYnNwOyBObyB0aGlyZC1wYXJ0eSB0cnVzdCBpcyBuZWVkZWQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoaXMgc29sdmVzIGFuIGludGVyZXN0 aW5nIHVzZS1jYXNlIGFuZCBpdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgaXQgaW4gb3VyIHRvb2xi b3guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpDZnJnIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpDZnJnQGlydGYub3JnIj5DZnJnQGlydGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlydGYub3Jn X21haWxtYW5fbGlzdGluZm9fY2ZyZyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPTNuckpwX0VqWFkwZ29j TGFCTXp1ZG9KWnVWd2kzYzlKY2JQVGw3bURCRWcmYW1wO3M9eUstRFN3Zm5oUGtmV1BINFFNNWJE NDN5TXBSWkNkUFpRR0E4VlVhNkFEVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nmcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4284CE2B1D0C421ABEF18B319C252851akamaicom_-- From nobody Wed Nov 15 23:23:59 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 C2DC312894A for ; Wed, 15 Nov 2017 23:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 R-B1vpN1UnX8 for ; Wed, 15 Nov 2017 23:23:55 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 5772512950A for ; Wed, 15 Nov 2017 23:23:54 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id 8so40396930qtv.1 for ; Wed, 15 Nov 2017 23:23:54 -0800 (PST) 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=rteTuh4VE1dVJAvC7Lkfg5T7gW0Ie9Dop+3B3N95hTo=; b=iOwhrHMXYOPd0mE3hSAJ7NEbwoUBFRVkD7NfoikSKhxYGL6HEIJgOewiPyXVcxfsnW tELmap22ZRzXFzPug0W6BftEWIBwZrQ8GljFbGCrcKvHiliVmKMUH0ITD2f56u8p6ibO qYJ/67h9oCmqDM++L3gcxu9ZFCKEu3kC8hp9erwozf4ukph9gjUl06gcFPhgqePdMxKb X4hsbxqd+pUSest9bRixl+IJ6tXr3VfebhUJ/FlrLX838BUcYBAFRxOSaEsHVM2NLNyN DRDoaXLFqa0z2fNUhoNLp3gaK4mW7QlvQ2ludAmMzjJPaGkQGtIOdeSLTfAv24oQTUFI 2COQ== 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=rteTuh4VE1dVJAvC7Lkfg5T7gW0Ie9Dop+3B3N95hTo=; b=DrLeRRx8tqllyqPTRuJhnfrp9BBF9Kc0HwspGj0Hr0umhYJnbWDQcdIesxLIcwlS2a +rRsC12X/qN0zeu5PteTo4Xp2Mj1kspCtgHGGCkGOQJxk4Xvv0uXPzJKrnIhP7FouwqV 37qT0gmiLqW4UcHKabtAQwsy0UbycR04utQxyqmEZmz7AlXQhGbrq5W/blQdnaB+9JBa 6w00MFTLwPRd/h9HmYIYHKI8YeBzbf9+8cze24qH4ky3jvoOvgT/hnitPcZyDGx6nwCb RAzlOE1cz+6Ie9OZ831cHIJ+37Oh4asN+UflYSxO9v0GRtc0tRTdG7uI0YpBv5W54RsM TviA== X-Gm-Message-State: AJaThX6VQ8cQhVRZuNgd/Oe9sCVx8N9euYPrmJBR6ahYWsfy+ZpDg2XJ +7GX8RtsjEzYxB67cHClo4wyABEfyWur/nFTuyU= X-Google-Smtp-Source: AGs4zMaqTW0gu+OqzdDH7jsXMQAasm2qebit6OzYwUodAE8Den8QnCaEzUyLwJ1VqbFDHySc5GzQhpJVAVU4suuGtOo= X-Received: by 10.55.108.135 with SMTP id h129mr1013357qkc.111.1510817033491; Wed, 15 Nov 2017 23:23:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Wed, 15 Nov 2017 23:23:53 -0800 (PST) In-Reply-To: References: From: "Stanislav V. Smyshlyaev" Date: Thu, 16 Nov 2017 15:23:53 +0800 Message-ID: To: Richard Barnes Cc: "Salz, Rich" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a1148809a9a2005055e1480b3" Archived-At: Subject: Re: [Cfrg] I like PKEX 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, 16 Nov 2017 07:23:58 -0000 --001a1148809a9a2005055e1480b3 Content-Type: text/plain; charset="UTF-8" In fact, PKEX (password-authenticated key exchange protocol by Dan Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for Richard), as all secure PAKE protocols can help to upgrade most cases of authentication, when some shared secret (password or, as in Rich's example, an account number), to solutions which do not require having a primary trust to someone you're authenticating to. I'd also like to see PAKEs in the messengers, as I commented during the CFRG meeting yesterday. 2017-11-16 15:21 GMT+08:00 Richard Barnes : > Sorry, what is PKEX? > > On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich wrote: > >> I think the PKEX stuff is very interesting. It inverts the trust model >> used on the Web. Suppose I want to do some online banking with >> mybank.com. My browser checks the server cert, and decided to trust it >> if the CA verifies the identity. I then type my name and password into the >> website. There is a risk if I end up at the wrong website. >> >> >> >> With PKEX, I can use my name and password and the bank can use something >> like my account number or other similar info, and we exchange and get a >> shared secret. We then use that secret to get an authenticated ECDSA key >> and then I switch to TLS and get its benefits. No third-party trust is >> needed. >> >> >> >> I think this solves an interesting use-case and it would be nice to have >> it in our toolbox. >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a1148809a9a2005055e1480b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In fact, PKEX (password-authenticated key exchange protoco= l by Dan Harkins,=C2=A0https://tools.ietf.org/html/draft-harkins-pkex-04 - for Richa= rd), as all secure PAKE protocols can help to upgrade most cases of authent= ication, when some shared secret (password or, as in Rich's example, an= account number), to solutions which do not require having a primary trust = to someone you're authenticating to.=C2=A0

I'd a= lso like to see PAKEs in the messengers, as I commented during the CFRG mee= ting yesterday.

<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">

2017-11-16 15:21 GMT+08:00 Richard Barnes= <rlb@= ipv.sx>:

Sorry, what is = PKEX?

On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@ak= amai.com> wrote:

I think the PKEX st= uff is very interesting.=C2=A0 It inverts the trust model used on the Web.= =C2=A0=C2=A0 Suppose I want to do some online banking with mybank.com. My browser checks the serve= r cert, and decided to trust it if the CA verifies the identity. I then type my name and password into = the website. There is a risk if I end up at the wrong website.

=C2=A0

With PKEX, I can us= e my name and password and the bank can use something like my account numbe= r or other similar info, and we exchange and get a shared secret. We then u= se that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.=C2=A0 No third-pa= rty trust is needed.

=C2=A0

I think this solves= an interesting use-case and it would be nice to have it in our toolbox.=

=C2=A0


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



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


--001a1148809a9a2005055e1480b3-- From nobody Thu Nov 16 00:30:47 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 C3D37129AA3 for ; Thu, 16 Nov 2017 00:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 y1kWEnrPh6sG for ; Thu, 16 Nov 2017 00:30:33 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 2BAE6129A8F for ; Thu, 16 Nov 2017 00:30:33 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id u42so17775596qte.7 for ; Thu, 16 Nov 2017 00:30:33 -0800 (PST) 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=//pYPwTG8Bcd/8ficfhbMx/Z/sAxtqn2rnZMTUgw9bI=; b=FPNF1p1yXMkJDDchH7ky39+LUAr9dZEMLJb+u81FT3aH8nkhR9N9d77AZKbjdM6Wez Fhd7N6MhUuClq632KSX7ObNAcLMC9Lx7OgcemiElhWcPgwlj2rivjQYAm7EPX6L0qTui gPHV0e6d9WRo2YVlfufVdYIatGJDFPctIO3cG7/5OHGjDb+V0Zw5IwLlszGG1QI30GM5 aM6B/qp05KjldFGBju990qaM3VTnUnBQ/wUZHJ15aHRhfvXyTgDZw3X4Q1ZoTb/3IpJ9 d+Wck/9piH0cuqH3j9nHG44Lf5l9kmgIc2wadqH+X6tXMkUvEsVpxdWNQr4Uw3JnUJxY ILaQ== 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=//pYPwTG8Bcd/8ficfhbMx/Z/sAxtqn2rnZMTUgw9bI=; b=fDQEMnpey47xRdpla0eLapbQAt+QsrQGU8Cd49ErRP4dqm0KY2gaf2jNg08pdrKmMO rfsPYMmTWAeuSCRkJpLDQLBU49vjb9mV3oSoQEwlMs6SEZltcg7lT5GB+39XrmoH6jao twdSFgqwavaKJ1Iv49V26lSqp4Y0/VwT4Ul3f2R1HM3moF1OqmfVWJvZ0jKfKJSs05bQ BFC9KkvvnGAQvN4yTuFdy0Kr8dIkczxzC4H9RFugxiZ4UOX/AZGpxjH3yihUa2hS1rYb 2ba7y7NfdBCU2HZBCkEB14/FUtoXQkZXM641FTn8mX29Fo+nYCitJuCpUWbAjdLB/197 ovkA== X-Gm-Message-State: AJaThX44zpRdEuYqdcEW4qL4Po7uJxYsJ6iUhRVxNUSB3t3fM4/GMRPN sk0ftib9HExrxJBDBLlCIRHXtTeeUxucPVj2954= X-Google-Smtp-Source: AGs4zMaIwOF1z+Ei59OXhmD2VzoYsuFXkQ8FTAOtfHeIW+uhSikDTkX+VteSFPFmIv3pnl4NVAX1TjzRfpsZWI43yuo= X-Received: by 10.55.108.135 with SMTP id h129mr1033018qkc.111.1510817460508; Wed, 15 Nov 2017 23:31:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.67 with HTTP; Wed, 15 Nov 2017 23:31:00 -0800 (PST) In-Reply-To: References: From: "Stanislav V. Smyshlyaev" Date: Thu, 16 Nov 2017 15:31:00 +0800 Message-ID: To: Richard Barnes Cc: "Salz, Rich" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a1148809a0ddc7d055e149afc" Archived-At: Subject: Re: [Cfrg] I like PKEX 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, 16 Nov 2017 08:30:45 -0000 --001a1148809a0ddc7d055e149afc Content-Type: text/plain; charset="UTF-8" Though, unfortunately, I am not aware of any online banking systems or messengers that use PAKEs for user authentication, I'd like to mention (hope you consider it interesting) that there are some existing cloud signature solutions (digital signature servers) in Russia that use one of PAKEs to authenticate users to their private keys stored in a cloud - in a way that is pretty similar to the one that has been mentioned by Rich. Best regards, Stanislav 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev : > In fact, PKEX (password-authenticated key exchange protocol by Dan > Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for > Richard), as all secure PAKE protocols can help to upgrade most cases of > authentication, when some shared secret (password or, as in Rich's example, > an account number), to solutions which do not require having a primary > trust to someone you're authenticating to. > > I'd also like to see PAKEs in the messengers, as I commented during the > CFRG meeting yesterday. > > > 2017-11-16 15:21 GMT+08:00 Richard Barnes : > >> Sorry, what is PKEX? >> >> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich wrote: >> >>> I think the PKEX stuff is very interesting. It inverts the trust model >>> used on the Web. Suppose I want to do some online banking with >>> mybank.com. My browser checks the server cert, and decided to trust it >>> if the CA verifies the identity. I then type my name and password into the >>> website. There is a risk if I end up at the wrong website. >>> >>> >>> >>> With PKEX, I can use my name and password and the bank can use something >>> like my account number or other similar info, and we exchange and get a >>> shared secret. We then use that secret to get an authenticated ECDSA key >>> and then I switch to TLS and get its benefits. No third-party trust is >>> needed. >>> >>> >>> >>> I think this solves an interesting use-case and it would be nice to have >>> it in our toolbox. >>> >>> >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >>> >>> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > --001a1148809a0ddc7d055e149afc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
T= hough, unfortunately, I am not aware of any online banking systems or messe= ngers that use P= AKEs for user authentication, I'd like to mention (hope you cons= ider it interesting) that there are some existing cloud signature solutions= (digital signature servers) in Russia that use one of PAKEs to authenticate=C2=A0users to t= heir private keys stored in a cloud - in a way that is pretty similar to th= e one that has been mentioned by Rich.


Best regards,
Stanislav


2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <smyshsv@gmail.co= m>:
In fac= t, PKEX (password-authenticated key exchange protocol by Dan Harkins,=C2=A0= https://tools.ietf.org/html/draft-harkins-pkex-04 - for Richa= rd), as all secure PAKE protocols can help to upgrade most cases of authent= ication, when some shared secret (password or, as in Rich's example, an= account number), to solutions which do not require having a primary trust = to someone you're authenticating to.=C2=A0

I'd a= lso like to see PAKEs in the messengers, as I commented during the CFRG mee= ting yesterday.

<= br clear=3D"all">
<= p>2017-11-16 15:21 GMT+08:00 Richard Barnes <rlb@ipv.sx>:

=
Sorry, what is PKEX?

On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@akamai.com= > wrote:
<= div class=3D"m_-1111708317710430014h5">

I think the PKEX st= uff is very interesting.=C2=A0 It inverts the trust model used on the Web.= =C2=A0=C2=A0 Suppose I want to do some online banking with mybank.com. My browser checks the serve= r cert, and decided to trust it if the CA verifies the identity. I then type my name and password into = the website. There is a risk if I end up at the wrong website.

=C2=A0

With PKEX, I can us= e my name and password and the bank can use something like my account numbe= r or other similar info, and we exchange and get a shared secret. We then u= se that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.=C2=A0 No third-pa= rty trust is needed.

=C2=A0

I think this solves= an interesting use-case and it would be nice to have it in our toolbox.=

=C2=A0


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



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



--001a1148809a0ddc7d055e149afc-- From nobody Thu Nov 16 04:21:50 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 028CB12947E; Thu, 16 Nov 2017 04:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uni-paderborn.de 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 1tK-dRdmgivQ; Thu, 16 Nov 2017 04:21:44 -0800 (PST) Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145EB129476; Thu, 16 Nov 2017 04:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=uni-paderborn.de; s=20170601; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4IRtF3tKH1nqGtfK/oaxi0S5+v2z9Pg0dIlrpin3TAU=; b=f0H+rctKQ39O0TYlZTrNY55NL8 /Yj9CTXUPAGgFO0a1hNjZlvN0sk7Pf2IG50GkJompWl2v3UDfxNEOSpjI8kVxRub6o1YVB93saQMs onjVhtZWSqZUyxab3ido5sOs4i9CS88a+8TRAJW9Al29Yq1x88EiDKQNFvP+EtiWTdvE=; To: "Paterson, Kenny" References: <59F5D882.30707@isode.com> Cc: "crypto-panel@irtf.org" , cfrg@irtf.org, mcgrew@cisco.com From: Tibor Jager Message-ID: <83851479-b427-c7d5-798f-03a791c5d5be@upb.de> Date: Thu, 16 Nov 2017 13:21:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IMT-Spam-Score: 0.0 () X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.16.120316, AntiVirus-Engine: 5.43.0, AntiVirus-Data: 2017.11.16.5430001 X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de Archived-At: Subject: Re: [Cfrg] [Crypto-panel] Request for review: draft-mcgrew-hash-sigs-08 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 12:21:49 -0000 Dear all, Please find my review of draft-mcgrew-hash-sigs-08 below. Cheers, Tibor Summary: The proposal is very carefully written and complete. I like very much that it provides helpful overview sections, good examples and is *extremely* clear. There are no major comments or concerns, but a few minor comments and recommendations. Among the points listed below, I consider a generalization of the discussion of race conditions that may lead to multiple signatures signed with the same state as the most important one. I've also checked the pseudocodes, but just by reading and not implementing them, so I may have missed something there. Minor comments: p.2: The "small private key" holds only if the keys are generated using the procedure from Appendix A (or any other pseudorandom function). I suggest to replace: "The characteristics of these signature systems are small private and public keys and fast signature generation and verification, but large signatures and moderatley slow key generation (in comparison with RSA and ECDSA)." -> "The characteristics of these signature systems are small public keys and fast signature generation and verification, but large signatures and moderatley slow key generation (in comparison with RSA and ECDSA). Private keys can be made very small by appropriate key generation, as described in Appendix A." p.2: I suggest to clarify by replacing: "A One-Time Signature (OTS) system can be used to sign one message securely, but cannot securely sign more than one" -> "A One-Time Signature (OTS) system can be used to sign one message securely, but will become insecure if more than one is signed with the same public/secret key pair." p.4 "When B is a byte and i is an integer, then B >> i denotes the logical right-shift operation." -> "When B is a byte and i is an integer, then B >> i denotes the logical right-shift operation by i positions." p.6/7: At first reading, I found r and q redundant. Only later in the document their different purpose became clear. p.8: The Winternitz coefficient w is a member of the set {1,2,4,8}. Later in the spec, only terms of the form 2^w-1 become relevant. I understand that this probably the notation from the paper, but it seems a bit weird to consider constant w-th powers of 2, instead of integer constants directly. One could (slightly) simplify this by letting w be a member of the set {1,3,15,255} and later work with w instead of 2^w-1. One could then easily even consider other values for w. Also {1,4,16,256} would appear a bit more natural. p.15: "size of the hash function" -> "output length of the hash function" p.16, Algorithm 5: Is step 3 of this algorithm really necessary? If yes, an explaining remark would be helpful. It seems to me that this instruction is not necessary. p.18/19: Algorithm 6a, step 3: "compute the candidate the LMS root value Tc ... using algorithm 6b" The caption of Algorithm 6b uses a different wording: "compute an LMS Public Key Candidate". I suggest to replace in algorithm 6a, step 3: "compute the candidate the LMS root value Tc ... using algorithm 6b" -> "compute the candidate the LMS Public Key Candidate Tc ... using algorithm 6b" to unify notation and improve clarity. p.20: A developer may wonder for which choices of N it should implement the scheme from Section 5, and when the scheme from Section 6 becomes more reasonable. I understand that this is difficult to say in general, but at least some recommendations or hints, e.g. in form of table with some example calculations of key size, computational difficulty of signing, etc., would clearly be helpful to assist this decision. p.31/32: I got the impression that the root of the problem does not become very clear here. The draft discusses volatile memory etc., but I think that more generally *any* race condition that can result in re-use of individual OTS keys is problematic. One could also point out that this makes it difficult to parallelize the generation of signatures, in particular with modern multi-core operating CPUs in mind. This could be explained more clearly here. Typos: p.2: "moderatley" p.2: "incorporate" -> "incorporated" p.11: "priva key" -> "private key" On 30/10/2017 10:54, Paterson, Kenny wrote: > Thanks Tibor, that would be great. > > On 30/10/2017 08:17, "Crypto-panel on behalf of Tibor Jager" > wrote: > >> Hi Alexey and Kenny, >> >> I can have a look at this, too. >> >> Cheers, >> Tibor >> >> On 29/10/2017 14:32, Alexey Melnikov wrote: >>> Dear Crypto Panel, >>> >>> CFRG Chairs would like to request review of >>> before >>> forwarding it to IRSG for final review and approval. >>> >>> Can we have some volunteer(s) please? >>> >>> Thank you, >>> Kenny and Alexey >>> >>> _______________________________________________ >>> Crypto-panel mailing list >>> Crypto-panel@irtf.org >>> https://www.irtf.org/mailman/listinfo/crypto-panel >>> >> >> _______________________________________________ >> Crypto-panel mailing list >> Crypto-panel@irtf.org >> https://www.irtf.org/mailman/listinfo/crypto-panel > From nobody Wed Nov 22 07:08:55 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 73B871288A9 for ; Wed, 22 Nov 2017 07:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 yheTaiNmJg3V for ; Wed, 22 Nov 2017 07:08:51 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 45B5C12783A for ; Wed, 22 Nov 2017 07:08:51 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id i14so18630190lfc.1 for ; Wed, 22 Nov 2017 07:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=hyOFnlmF9Z/tlgkj8BfoKS61QOsfF3ITqWFSguCFHWg=; b=KAbEvFh93iyKCc37pfXATywBrjkSaJ392kGp1J6kTAcqn5lZk8qWQTqYJ0AUFulTNc YLLX1l9UDtrrzE2Gz/sUbIg+sJ58VNULomX7fA3103iVKmxoWNcK6HP47JbEpEtrcJVI jAalfghswecU5AUQakKDdjPRqHS0ndtw26OC7IKSR3Y6XQusybGFfc4fQe5ipCPqa3LD cPz1dcUJ3XpAMn9PE9VPsGk5P/S9+LnES6Tsk5m9m2Ctg2WjAzUMQa79YQJLs8F5U9zv yEge05/DOas9oo0pVjormSMgvbQAUwNqafUwPQ19FC+PLkzCCDwJEVKW9/1eiuMLA2qW dXBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=hyOFnlmF9Z/tlgkj8BfoKS61QOsfF3ITqWFSguCFHWg=; b=K3aKi9cOSKn8NImiHt2uZEf2mVVoxhtmmQJmR2AHKmL756wTmRVsZE4WmV5BD8ouKK 1lxI7gs8TiVJZBYhKLTxQS4ZGOFKpHDLvwOpkdQyV0+h21MrT2yt+cGRhqZ9r7GXxYIg aGRyBXsRQVMwhO3srlOpA5sS6E4c8gjZ0uoqwAWgdo/JeoTaCd+0u7JNVVVswAmH7yNu ssOxYc9y+++sGrcEMiPf+nFqsVIg1VUu7BNhkcPA8K1Hu+YfPk940gXcU4rQac7jIP3L PE+8IT50aTVd0uUt8wz9R+OObPSf/UvNT/fcn/vbVotV9Q+d7GrgwTAp0oUoOzCLD/8l r47A== X-Gm-Message-State: AJaThX5ZP6W89lUYBP/PKsnDUDw0fQoH21+kkRpaVr883TinG+pm6xEh zq/u6wCAWTSAEubY3pm83ZvMtHy+xroVHZjJUg8= X-Google-Smtp-Source: AGs4zMY0K9TvqUaoTiQK2K5rOhKVru5ysuDxrDgDPKbzQV5UGR+NOLk5ApIfo9kpIbwJBaohctR/8KM1TtXuUTwLR/4= X-Received: by 10.25.33.73 with SMTP id h70mr6112825lfh.60.1511363329432; Wed, 22 Nov 2017 07:08:49 -0800 (PST) MIME-Version: 1.0 Sender: stefano.tessaro@gmail.com Received: by 10.25.44.130 with HTTP; Wed, 22 Nov 2017 07:08:48 -0800 (PST) In-Reply-To: <6FE8E700-E7F8-46F5-8EC4-E948FDB1D9BE@biu.ac.il> References: <6FE8E700-E7F8-46F5-8EC4-E948FDB1D9BE@biu.ac.il> From: Stefano Tessaro Date: Wed, 22 Nov 2017 07:08:48 -0800 X-Google-Sender-Auth: OyYnXem6rAJXCBy67auHfHGKOt0 Message-ID: To: Yehuda Lindell Cc: "cfrg@irtf.org" , Paterson Kenny Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 22 Nov 2017 15:08:53 -0000 Dear all, We have made a version of our work available at http://www.cs.ucsb.edu/~tessaro/papers/BHT17.pdf We have extended the bounds to cover a large class of KDFs. In particular, our bound covers the KDF in the current AES-GCM-SIV proposal, as well as the simpler one we suggested in an earlier e-mail, which is the one from the initial AES-GCM-SIV proposal. Regards, Priyanka Bose Viet Tung Hoang Stefano Tessaro On Mon, Oct 2, 2017 at 10:29 PM, Yehuda Lindell wrote: > Dear all, > > The paper by Bose, Hoang and Tessaro (BHT) shows that AES-GCM-SIV has exc= ellent multi-user security bounds (according to the authors, this is the fi= rst scheme that has been shown to have the property that the multi-user sec= urity is essentially as good as the single user security). Thus, this is gr= eat support for AES-GCM-SIV as a standard. > > Conceptually, the reason why AES-GCM-SIV gets much better multi-user secu= rity than other modes is due to the continual key derivation that ensures t= hat even if two users have the same key, the damage is minimal since they m= ust 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 mo= de, and without truncation). They say that it is more efficient, and this i= s true theoretically. However, practically, when using AES-NI, the cost of = 2 additional encryptions for the key derivation is almost zero due to the p= ipeline (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, du= ring the CFRG discussions (e.g., due to the fact that for 256-bit keys, thi= s rules out the possibility of keys of the form K||K). Instead, an OCB styl= e derivation was promoted. Subsequently, we ended up with the current trunc= ated CTR method. We therefore propose to not change the key derivation meth= od (again). > > Thanks, > > Shay, Adam and Yehuda > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --=20 Stefano Tessaro Assistant Professor of Computer Science University of California, Santa Barbara http://cs.ucsb.edu/~tessaro/ From nobody Thu Nov 30 10:19:24 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416CF1293D8 for ; Thu, 30 Nov 2017 10:19:22 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bCTBHa9NwsjQ for ; Thu, 30 Nov 2017 10:19:20 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 42E67127977 for ; Thu, 30 Nov 2017 10:19:19 -0800 (PST) X-AuditID: 1209190c-4afff70000004a55-6c-5a204ba5ea8c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id BE.A9.19029.5AB402A5; Thu, 30 Nov 2017 13:19:18 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vAUIJE0H000590 for ; Thu, 30 Nov 2017 13:19:16 -0500 Received: from localhost (EQUAL-RITES.MIT.EDU [10.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAUIJD84030321 for ; Thu, 30 Nov 2017 13:19:14 -0500 From: Greg Hudson To: cfrg@ietf.org Date: Thu, 30 Nov 2017 13:19:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUixG6norvMWyHK4MF9fouju9pYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeX5Z5aC+eIVl1oWszYwzhXsYuTkkBAwkWh5f5O9i5GLQ0hg MZPE6wmfWCCco4wSb/a/Z4Jw2pgk2m4+YQZpYRNQlli/fytQFQeHiICgRMcaGZCwsIC5xK/d 29hAbBYBVYkD9/tYQUp4BQwlni/OAgnzAlWfnPmEBcRmFpCQOPjiBfMERu5ZSFKzkKQWMDKt YpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECAoBTkmeHYxn3ngdYhTgYFTi4bUQ VIgSYk0sK67MPcQoycGkJMob6QUU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKb4gSU401JrKxK LcqHSUlzsCiJ824L2hUpJJCeWJKanZpakFoEk5Xh4FCS4M0CGSpYlJqeWpGWmVOCkGbi4AQZ zgM0/LEHyPDigsTc4sx0iPwpRlWOZzNfNzALseTl56VKifPOAhkkAFKUUZoHN+cVozjQO8K8 X0GyPMA4h5vwCmg4E9DwzOXyIMNLEhFSUg2MrtKipTd/5DfcvK+aZf5hs1WNjcq5uCkbvvaZ L5rzUOki48WrG3Zcv9a+W0XR2n/RutWTvTmWJXzJOV1QvThcqD95Xuzi3Z9zrM6wbTypWn5M ybfB+nOCmMtyhieLpm4UZppwXtLm5HTzk8cSfjTfzT/0b9HbZS+WVrxd8oG5PMKKYeIThlez I5VYijMSDbWYi4oTAXQdudywAgAA Archived-At: Subject: [Cfrg] draft-irtf-cfrg-spake2 edwards25519 M/N values 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, 30 Nov 2017 18:19:22 -0000 I would like to see M/N values for edwards25519 added to draft-irtf-cfrg-spake2. This addition requires minor adjustments to the text and Python code. Combined with my suggestions from https://www.ietf.org/mail-archive/web/cfrg/current/msg09370.html the introductory text for the section should read: For each curve in the table below, we construct a string using the curve OID from [RFC5480] or its name, combined with 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 [RFC7748] curves 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. The new M and N points are: For edwards25519: M = d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf seed: edwards25519 point generation seed (M) N = d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab seed: edwards25519 point generation seed (N) I would also like the draft to list the seed string for each point, as included above. The Python code should read: def canon_pointstr(s): return chr(ord(s[0]) & 1 | 2) + s[1:] def iterated_hash(seed, n): h = seed for i in xrange(n): h = SHA256.new(h).digest() return h def bighash(seed, start, sz): n = -(-sz // 32) hashes = [iterated_hash(seed, i) for i in xrange(start, start + n)] return ''.join(hashes)[:sz] def gen_point(seed, ec, order, need_canonicalization): for i in xrange(1, 1000): pointstr = bighash(seed, i, ec.nbytes_point()) if need_canonicalization: pointstr = canon_pointstr(pointstr) try: p = ec.decode_point(pointstr) if p != ec.identity() and ec.mul(p, order) == ec.identity(): return pointstr, i except Exception: pass (I will submit a pull request to Ben's github repository for the draft with all of this.)