From nobody Wed May 3 15: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 430051294BF for ; Wed, 3 May 2017 15:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 PnJ3Qv5GF7Gr for ; Wed, 3 May 2017 15:28:47 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6A7741296D2 for ; Wed, 3 May 2017 15:27:04 -0700 (PDT) Received: from [169.254.218.211] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v43MQePa045258 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 3 May 2017 15:26:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.218.211] From: "Paul Hoffman" To: cfrg@irtf.org Date: Wed, 03 May 2017 15:27:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 03 May 2017 22:28:48 -0000 Greetings again. I have just published a very, very preliminary Internet Draft to help people understand when they have to make the transition from classical to post-quantum cryptography. The draft information is here: Name: draft-hoffman-c2pq Revision: 00 Title: The Transition from Classical to Post-Quantum Cryptography Document date: 2017-05-03 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-hoffman-c2pq-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-c2pq-00 This -00 is full of holes, but gives a structure for how to tell people about quantum computers that apply to breaking cryptographic keys, how to tell when those computers might become feasible, and what they need to think about for the transition. It most emphatically does *not* cover post-quantum algorithms other than to say "go look here for more info on that". That is, this document is about determining when people need to make the transition, not the algorithms to which they might transition. Clearly, the draft needs a lot of input. Not only are there holes, there may be flat-out errors in it. That's why there is the strong disclaimer at the beginning; I am not a cryptographer, a mathematician, or a physicist, but I do work in fields where people are asking "should we even be thinking about post-quantum crypto". Suggestions for text are great, suggestions that come with references are even better. Does this seem like something that CFRG might be interested in adopting as an RG document? If so, I can make the next version draft-irtf-cfrg...; if not, I can keep this as an individual draft that will get published in the IETF stream instead of the IRTF stream. --Paul Hoffman From nobody Thu May 4 03:17: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 BA93F129568 for ; Thu, 4 May 2017 03:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLdzpKL2EFaH for ; Thu, 4 May 2017 03:17:35 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7EE129510 for ; Thu, 4 May 2017 03:17:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 49D3F201C9; Thu, 4 May 2017 12:17:32 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjZCDasMw9iL; Thu, 4 May 2017 12:17:29 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id CC1B9200AB; Thu, 4 May 2017 12:17:29 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Thu, 4 May 2017 12:17:29 +0200 From: "Tams, Benjamin" To: Paul Hoffman , "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyt1OhpEFxGFkCkNWaQhkLfN6Hj4WzA Date: Thu, 4 May 2017 10:17:29 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: 46B80F45-DE3A-4FD2-89B1-CF5B4A9E99F8 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 04 May 2017 10:17:38 -0000 Hi Paul, thank you for producing the initial draft. I think such a document can be v= ery useful for the community and individual organizations for being taken into account for= properly managing=20 risk in view of possible attacks by quantum computers. I briefly read over = the document.=20 Here are some personal comments on the organization of the document. If the intention of the final document is to help people understand when th= ey have to make the transition from classical to post-quantum cryptography, I would like to pr= opose to set the focus=20 more on what an organization should consider for deciding whether or not to= go from classical to=20 post-quantum cryptography. My very personal vision is to motivate the reade= r to consider the following questions. 1. What if useful quantum computers arise in the short term (e.g. 0-10 year= s),=20 middle term (eg. 10-15 years), or long term (e.g. 15-25 years)? 2. What if I use classical cryptography today, that can be broken=20 by a quantum computer in the short, middle or long term? 3. When should I switch to post-quantum cryptography for digital signatures= , asymmetric encryption, or symmetric encryption?=20 4. Is my application worth for being attacked by someone who can use a quan= tum computer? If it is, why? (This question is already addressed in Section 5 o= f the draft). Essentially, I think the intention of the document should not be to convinc= e the reader to use or not to use post-quantum cryptography. It should rather leave it to the r= eader to decide whether or not (and if to which extent) he considers it necessary to apply = post-quantum=20 cryptography in his application.=20 Anyway, if an organization's decision is to use post-quantum cryptography (= a decision that we should leave open), then the organization should be able to access a specif= ication suitable for implementation, timely. While CFRG may already specify documents for PQ-safe digital signatures, CFRG seems to hesitate to specify something for= PQ-safe public key encryption. It is (not just) my opinion, that the need for PQ-safe publ= ic key encryption is much higher, though less matured.=20 If we leave it open by a CFRG (or similar) document, that the reader's dec= ision is to use PQ-safe public key encryption, then we should also provide a corresponding specific= ation - a building block=20 that is still missing for IETF drafts (https://tools.ietf.org/html/draft-w= hyte-qsh-tls13-04). Also see=20 previous posts in this forum (https://www.ietf.org/mail-archive/web/cfrg/current/msg09087.html). @CFRG: Still, I am happy if there are people that are willing to specify PQ= -safe public key encryption. Alternatively, I would like to consider to initiate an individu= al submission for such a draft. Kind regards, Benjamin -----Urspr=FCngliche Nachricht----- Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Paul Hoffman Gesendet: Donnerstag, 4. Mai 2017 00:27 An: cfrg@irtf.org Betreff: [Cfrg] New draft on the transition from classical to post-quantum = cryptography Greetings again. I have just published a very, very preliminary Internet=20 Draft to help people understand when they have to make the transition=20 from classical to post-quantum cryptography. The draft information is=20 here: Name: draft-hoffman-c2pq Revision: 00 Title: The Transition from Classical to Post-Quantum Cryptography Document date: 2017-05-03 Group: Individual Submission Pages: 12 URL: =20 https://www.ietf.org/internet-drafts/draft-hoffman-c2pq-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-c2pq-00 This -00 is full of holes, but gives a structure for how to tell people=20 about quantum computers that apply to breaking cryptographic keys, how=20 to tell when those computers might become feasible, and what they need=20 to think about for the transition. It most emphatically does *not* cover=20 post-quantum algorithms other than to say "go look here for more info on=20 that". That is, this document is about determining when people need to=20 make the transition, not the algorithms to which they might transition. Clearly, the draft needs a lot of input. Not only are there holes, there=20 may be flat-out errors in it. That's why there is the strong disclaimer=20 at the beginning; I am not a cryptographer, a mathematician, or a=20 physicist, but I do work in fields where people are asking "should we=20 even be thinking about post-quantum crypto". Suggestions for text are=20 great, suggestions that come with references are even better. Does this seem like something that CFRG might be interested in adopting=20 as an RG document? If so, I can make the next version=20 draft-irtf-cfrg...; if not, I can keep this as an individual draft that=20 will get published in the IETF stream instead of the IRTF stream. --Paul Hoffman _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Thu May 4 12:23:30 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77537129502 for ; Thu, 4 May 2017 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 IdTfWQjlQatb for ; Thu, 4 May 2017 12:23:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D5A128BB7 for ; Thu, 4 May 2017 12:23:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8C4D13004FE for ; Thu, 4 May 2017 15:23:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0Vg_978knWJK for ; Thu, 4 May 2017 15:23:23 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5709F30024B; Thu, 4 May 2017 15:23:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 4 May 2017 15:23:22 -0400 Cc: IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: <54165178-B90A-49B2-965B-428AD2AA2639@vigilsec.com> References: To: Kenny Paterson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Research Group Last Call: draft-nir-cfrg-rfc7539bis 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, 04 May 2017 19:23:28 -0000 I took a look, and I think the document is ready to be published as an = RFC. Russ > On Apr 27, 2017, at 6:13 AM, Paterson, Kenny = wrote: >=20 > Dear CFRG, >=20 > This message starts 2 weeks RGLC on draft-nir-cfrg-rfc7539bis = ("ChaCha20 > and Poly1305 for IETF Protocols"), which will end on Thursday 11th = May. > The draft is available here: >=20 > https://datatracker.ietf.org/doc/draft-nir-cfrg-rfc7539bis/ >=20 >=20 > Please provide your review comments, as well as statement of support = (or > not) in reply to this message or directly to CFRG chairs. >=20 > Thanks, >=20 > Alexey and Kenny From nobody Sun May 7 17:18:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24255128854 for ; Sun, 7 May 2017 17:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 DYtjFbomRj2i for ; Sun, 7 May 2017 17:18:54 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E5DA012702E for ; Sun, 7 May 2017 17:18:53 -0700 (PDT) Received: from [169.254.120.20] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v480IS0h011346 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 May 2017 17:18:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.120.20] From: "Paul Hoffman" To: "Tams, Benjamin" Cc: "cfrg@irtf.org" Date: Sun, 07 May 2017 17:18:51 -0700 Message-ID: <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> In-Reply-To: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 00:18:55 -0000 On 4 May 2017, at 3:17, Tams, Benjamin wrote: > thank you for producing the initial draft. I think such a document can > be very useful for > the community and individual organizations for being taken into > account for properly managing > risk in view of possible attacks by quantum computers. Thanks > I briefly read over the document. > > Here are some personal comments on the organization of the document. > > If the intention of the final document is to help people understand > when they have to make the > transition from classical to post-quantum cryptography, I would like > to propose to set the focus > more on what an organization should consider for deciding whether or > not to go from classical to > post-quantum cryptography. My very personal vision is to motivate the > reader to consider the > following questions. > > 1. What if useful quantum computers arise in the short term (e.g. 0-10 > years), > middle term (eg. 10-15 years), or long term (e.g. 15-25 years)? > > 2. What if I use classical cryptography today, that can be broken > by a quantum computer in the short, middle or long term? > > 3. When should I switch to post-quantum cryptography for digital > signatures, asymmetric > encryption, or symmetric encryption? > > 4. Is my application worth for being attacked by someone who can use a > quantum > computer? If it is, why? (This question is already addressed in > Section 5 of the draft). > > Essentially, I think the intention of the document should not be to > convince the reader to use > or not to use post-quantum cryptography. It should rather leave it to > the reader to decide > whether or not (and if to which extent) he considers it necessary to > apply post-quantum > cryptography in his application. That is certainly my intention. > Anyway, if an organization's decision is to use post-quantum > cryptography (a decision that we > should leave open), then the organization should be able to access a > specification suitable for > implementation, timely. While CFRG may already specify documents for > PQ-safe digital signatures, CFRG seems to hesitate to specify > something for PQ-safe public > key encryption. It is (not just) my opinion, that the need for PQ-safe > public key encryption > is much higher, though less matured. And I completely want to avoid any discussion of such a specification in this document; I consider "when you want to move to post-quantum" orthogonal to "at the time you move, here are your best options". --Paul Hoffman From nobody Mon May 8 01:52: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 A45DF127775 for ; Mon, 8 May 2017 01:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUjpx-OaJQFg for ; Mon, 8 May 2017 01:52:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D800A1289C3 for ; Mon, 8 May 2017 01:52:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 97EF92018E; Mon, 8 May 2017 10:52:31 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJX9Mte9HPV3; Mon, 8 May 2017 10:52:31 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 342FA2006A; Mon, 8 May 2017 10:52:31 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Mon, 8 May 2017 10:52:31 +0200 From: "Tams, Benjamin" To: Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyt1OhpEFxGFkCkNWaQhkLfN6Hj4WzAgAWVqoCAAK9JUA== Date: Mon, 8 May 2017 08:52:30 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE132613181399299F5@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> In-Reply-To: <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: C416F902-6B7C-483D-84A3-3E38C564BC93 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 08:52:38 -0000 >> Anyway, if an organization's decision is to use post-quantum=20 >> cryptography (a decision that we >> should leave open), then the organization should be able to access a=20 >> specification suitable for >> implementation, timely. While CFRG may already specify documents for >> PQ-safe digital signatures, CFRG seems to hesitate to specify=20 >> something for PQ-safe public >> key encryption. It is (not just) my opinion, that the need for PQ-safe=20 >> public key encryption >> is much higher, though less matured. > And I completely want to avoid any discussion of such a specification in= =20 > this document; I consider "when you want to move to post-quantum"=20 > orthogonal to "at the time you move, here are your best options". I agree. Of course this should not be discussed in the document. But, I took the opportunity to emphasize the need for such a specification in my post. Best regards, Benjamin Tams From nobody Mon May 8 05:46: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 C57DB129461 for ; Mon, 8 May 2017 05:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ybqsHyUMXw1q for ; Mon, 8 May 2017 05:46:19 -0700 (PDT) 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 A7130129459 for ; Mon, 8 May 2017 05:46:19 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v48C702Z028349; Mon, 8 May 2017 13:46:18 +0100 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 : content-transfer-encoding : mime-version; s=jan2016.eng; bh=tupL+Mew9PRaXqa0m3iFLSdbIeESnetx7x02xQ1XhFk=; b=GYUDbtnZz9rsX+BW6jf4LPj6hhv3ltar/LE9UMCAg403hwk7Rojs+VvkyjFDIZpWAeRJ APX64Oi+S+GoHQz7ouihbja7dp/xKAPtG8XKN8+W/HFsZXxOIjb1SHUcfrBmaTUaLZZR FFoQeuC4NBnOfb2azsDepNyKDBoCpNk6zDeMwdEP41H6KP9ejXqxOoeoGtejVwp07BNW uMGdBl+CeyBw1fyiXoh/W0OqzC/ZYq6jQ3nY9ykOP+tbXS6UASF0UXwf5wT0kOMSFcap 7j0yHNrVs6QVGHMaQsjIjQPtgYRz3oJl4WvceEudz8QL+a8u42CcUTj/g8h2JByw2eUp cA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2aaqp8rcsk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 May 2017 13:46:18 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v48CBbBR029263; Mon, 8 May 2017 08:46:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a99tvv7sy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 May 2017 08:46:17 -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; Mon, 8 May 2017 08:46:16 -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; Mon, 8 May 2017 08:46:16 -0400 From: "Salz, Rich" To: Paul Hoffman , "Tams, Benjamin" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFym/EWb0YnqLEyGCC6sAdbti6HkSl2AgAWRToCAAI0kAA== Date: Mon, 8 May 2017 12:46:15 +0000 Message-ID: <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> In-Reply-To: <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.53] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705080069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-08_08:, , 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-1703280000 definitions=main-1705080069 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 12:46:21 -0000 > And I completely want to avoid any discussion of such a specification in = this > document; I consider "when you want to move to post-quantum" > orthogonal to "at the time you move, here are your best options". Well, it's not of course. What you do when you move depends on what is ava= ilable at that time and options are likely to improve as Science Marches Fo= rward. I also think when to move depends on what you're trying to do. The protecti= on you need for online ecommerce buying razor blades is very different from= launching missles is very different from long-term archival storage of off= icial documents. I think both of these things should at least be touched on.=20 From nobody Mon May 8 06:46: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 703B3129432 for ; Mon, 8 May 2017 06:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 LhoxUB_3N2Aq for ; Mon, 8 May 2017 06:46:40 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B8668120727 for ; Mon, 8 May 2017 06:46:40 -0700 (PDT) Received: from [10.99.99.52] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v48DkD4G044015 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 06:46:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.99.99.52] From: "Paul Hoffman" To: "Salz, Rich" Cc: "cfrg@irtf.org" Date: Mon, 08 May 2017 06:46:36 -0700 Message-ID: <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> In-Reply-To: <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 13:46:41 -0000 On 8 May 2017, at 5:46, Salz, Rich wrote: >> And I completely want to avoid any discussion of such a specification >> in this >> document; I consider "when you want to move to post-quantum" >> orthogonal to "at the time you move, here are your best options". > > Well, it's not of course. What you do when you move depends on what > is available at that time and options are likely to improve as Science > Marches Forward. Fair point. There is a subtlety in "when you want to move to post-quantum" of "there is a post-quantum solution at the time that meets your needs". My unstated assumption is that NIST and others around the world will have standardized on some solutions before the readers of this document (or a future version of it) feel the need to change. I'll reflect that better in the next draft. > I also think when to move depends on what you're trying to do. The > protection you need for online ecommerce buying razor blades is very > different from launching missles is very different from long-term > archival storage of official documents. > > I think both of these things should at least be touched on. Fully agree. --Paul Hoffman From nobody Mon May 8 06:57:16 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 08412129488 for ; Mon, 8 May 2017 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa1xI_2s3DdF for ; Mon, 8 May 2017 06:57:13 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14A0129487 for ; Mon, 8 May 2017 06:57:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C93DE201BD; Mon, 8 May 2017 15:57:09 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwZ2eKvg82Ox; Mon, 8 May 2017 15:57:08 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 0F98420079; Mon, 8 May 2017 15:57:08 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Mon, 8 May 2017 15:57:07 +0200 From: "Tams, Benjamin" To: Paul Hoffman , "Salz, Rich" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyt1OhpEFxGFkCkNWaQhkLfN6Hj4WzAgAWVqoCAANDSgIAAENwAgAAh2YA= Date: Mon, 8 May 2017 13:57:07 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE13261318139929FEC@mail-essen-01.secunet.de> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> In-Reply-To: <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.126.244] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: F297D199-B3F9-4B49-B7B1-F8CF050D67E3 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 13:57:15 -0000 > My unstated assumption is that NIST and others around=20 > the world will have standardized on some solutions before the readers of= =20 > this document (or a future version of it) feel the need to change. Do we know this? I can pretty well imagine that there may already now exist the need to protect traffic with PQ-safe solutions that cannot wait until the NIST standardization process comes with a specification in=20 2023 - 2025 according to the timeline suggested in=20 http://csrc.nist.gov/groups/ST/post-quantum-crypto/workshops.html=20 Regards Benjamin Tams _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon May 8 07:21: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 D5C4612946E for ; Mon, 8 May 2017 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeG4g0VuaG1J for ; Mon, 8 May 2017 07:20:54 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7388A1294A2 for ; Mon, 8 May 2017 07:20:54 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v48EKqtk009987; Mon, 8 May 2017 10:20:53 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyloAd9nWKoNk2AcrmqPq9I+KHkOZmAgAWiEoCAANDSgIAAEN0A///GhAA= Date: Mon, 8 May 2017 14:20:52 +0000 Message-ID: <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> In-Reply-To: <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-originating-ip: [172.25.177.148] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3577083652_1194651243" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705080076 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 14:20:58 -0000 --B_3577083652_1194651243 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 5/8/17, 9:46 AM, "Cfrg on behalf of Paul Hoffman" wrote: On 8 May 2017, at 5:46, Salz, Rich wrote: =20 >> And I completely want to avoid any discussion of such a specificatio= n=20 >> in this >> document; I consider "when you want to move to post-quantum" >> orthogonal to "at the time you move, here are your best options". > > Well, it's not of course. What you do when you move depends on what=20 > is available at that time and options are likely to improve as Scienc= e=20 > Marches Forward. =20 Fair point. There is a subtlety in "when you want to move to=20 post-quantum" of "there is a post-quantum solution at the time that=20 meets your needs".=20 Technically you both are correct, and the two issues (=E2=80=9Cwhen=E2=80=9D and =E2=80=9Cto = what=E2=80=9D) are orthogonal. In practice however they lose much without one anot= her.=20 I understand that we may have a better idea now as to =E2=80=9Cwhen=E2=80=9D over what = =E2=80=9Cthe best options=E2=80=9D are likely to be =E2=80=9Cthen=E2=80=9D (so it=E2=80=99s easier to talk= about =E2=80=9Cwhen=E2=80=9D, even though both recommendations =E2=80=93 not just =E2=80=9Cto what=E2= =80=9D but also =E2=80=9Cwhen=E2=80=9D - may change as time advances). I see the two as two parts of a single document, or as two closely related = drafts, cross-referenced, and released together. My unstated assumption is that NIST and others around=20 the world will have standardized on some solutions before the readers o= f=20 this document (or a future version of it) feel the need to change. I'll= =20 reflect that better in the next draft. Wouldn=E2=80=99t you agree that for long-term documents (those that need to survi= ve for 15+ - 20+ years from now) the =E2=80=9Cneed to change=E2=80=9D is now with a pret= ty high probability? Wouldn=E2=80=99t that break your assumption? =20 > I also think when to move depends on what you're trying to do. Yes. ;-) For some applications the need appears to be =E2=80=9Cnow=E2=80=9D.=20 --B_3577083652_1194651243 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg2J02o9QF0+o2mvf2 a+66XncgVqktC+5FXWBS4Um9HJ8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNTA4MTQyMDUyWjANBgkqhkiG9w0BAQEFAASCAQDRltYL8p7+uGE2c6m2 +4eXhviJOw+BQrDgVUqHFuglt6KkM8LqMWWMVKrQo+0fWspV6tBFiA/XHFAGz/XYnKEeLtnt 4H71DzjNmHhZdG7mzY3gHnwCbW9ZazpJdx3D4GUiu2T8l5FWK4gLL0vd3pKUiVNYQRN0CDxl v9jlcS18N945Vae1kNMrkZg+pXJq9Y0+nnH2ieuKQW+M8Cc6s6G0CLnjy5Op3noEJUffp7Jd pd0/p875AsoJHiPWKDSsRbjQIGWy5o4CfBTHnmEEXBO6uMYnv9Kn2Jzwk8nbRDjSo0A9Incl TlyTMZhZme17E376ZYH6JKrVLqg/Fa/+1An7 --B_3577083652_1194651243-- From nobody Mon May 8 07:28:31 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B70E128961 for ; Mon, 8 May 2017 07:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 vVKDS1qz1lBs for ; Mon, 8 May 2017 07:28:28 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 A1449127867 for ; Mon, 8 May 2017 07:28:28 -0700 (PDT) Received: from [169.254.253.96] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v48ES3dE045469 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 07:28:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.253.96] From: "Paul Hoffman" To: "Blumenthal, Uri - 0553 - MITLL" Cc: "cfrg@irtf.org" Date: Mon, 08 May 2017 07:28:26 -0700 Message-ID: In-Reply-To: <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 14:28:29 -0000 On 8 May 2017, at 7:20, Blumenthal, Uri - 0553 - MITLL wrote: > Wouldn’t you agree that for long-term documents (those that need to > survive for 15+ - 20+ years from now) the “need to change” is now > with a pretty high probability? No. That is, I haven't seen evidence that there will be quantum computers in 15 to 20 years from now that will be able to break classical cryptography using current key sizes. The same is true if you said "50 years". Of course, I might have missed something in the early research for the -00 draft, so if you have pointers to such calculations, that would be great. I strongly suspect that some organizations feel a strong need to start protecting such messages and are very interested in standardizing on good pqc algorithms. If those organizations have any pointers as to how they are making their judgements, that would greatly help this draft. --Paul Hoffman From nobody Mon May 8 07:34:46 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181D8129492 for ; Mon, 8 May 2017 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew3AAgASN0k8 for ; Mon, 8 May 2017 07:34:43 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38F12947B for ; Mon, 8 May 2017 07:34:43 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v48EYgpT019201; Mon, 8 May 2017 10:34:42 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyloAd9nWKoNk2AcrmqPq9I+KHkOZmAgAWiEoCAANDSgIAAEN0A///GhACAAEUsAP//vrIA Date: Mon, 8 May 2017 14:34:42 +0000 Message-ID: <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-originating-ip: [172.25.177.148] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3577084482_1952570309" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705080078 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 08 May 2017 14:34:45 -0000 --B_3577084482_1952570309 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 5/8/17, 10:28 AM, "Paul Hoffman" wrote: > Wouldn=E2=80=99t you agree that for long-term documents (those that need to= =20 > survive for 15+ - 20+ years from now) the =E2=80=9Cneed to change=E2=80=9D is now= =20 > with a pretty high probability? =20 No. That is, I haven't seen evidence that there will be quantum=20 computers in 15 to 20 years from now that will be able to break=20 classical cryptography using current key sizes. The same is true if you= =20 said "50 years".=20 First, I=E2=80=99m sure there are documents now that need a =E2=80=9Csecure life=E2=80=9D lon= ger than 20 or even 50 years. Of course, I might have missed something in the early=20 research for the -00 draft, so if you have pointers to such=20 calculations, that would be great. Alas, my crystal ball is out of order right now. But scientific progress te= nds to be not exactly predictable/calculate-able. E.g., did you expect to ta= lk about =E2=80=9Cquantum computers breaking crypto=E2=80=9D 20 years ago? I didn=E2=80=99t. =20 --B_3577084482_1952570309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg/SKY45gmnivouWH4 1MRBGXrJSE4rOZNPNkiJQbeoKGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcwNTA4MTQzNDQyWjANBgkqhkiG9w0BAQEFAASCAQBEm0rjJeQI5SiasPdH 7+5GfPa4jSNu/JzXweYyRaPeJKACXzHfokOkE0dEhWsY59VwTYwAgiutz13GBze7CYqW73XO 8y0idfH/VIJm1ROTr4eYrPSjvi8gH5yI6AtjkEuRpqXPruxYjiJNltMRaJr3p1xt20eetCWA 2G9B8m1QeFisvhEY3CyObaHSMWRAYYaO7TVEUS1mYnSEPWwJ0R26zX6sR8jPJJO01m+UPSjl DyCm6WKYoEfmb4Wh0P2Lz9mm6iuNn98nS0O5yM2K0Hd/x0cPEeGqbD1jM/wzRXWC3vbjd2L2 N8LtiwzncdzVj7Rle+YJ33VHv5K5FS68vUU0 --B_3577084482_1952570309-- From nobody Mon May 8 08:31:10 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122951294B3 for ; Mon, 8 May 2017 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN9soBNRe3Ql for ; Mon, 8 May 2017 08:31:06 -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 7E6901294C8 for ; Mon, 8 May 2017 08:31:06 -0700 (PDT) Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2017 11:31:05 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 8 May 2017 11:31:04 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: naive question: QC vs RC vs Moore-blip Thread-Index: AdLIDxLailn8AM7oS6K3HHWy2z/Eag== Date: Mon, 8 May 2017 15:31:03 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] naive question: QC vs RC vs Moore-blip 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, 08 May 2017 15:31:08 -0000 Dear CFRG, Please forgive my naivety on the matters below. =20 If quantum computers are realistic enough to warrant standards changes (now= or soon), then what about other hypothetical computers, such as: (1) computers that can do super high-precision, as in the "real computation= " model (or whatever variant of this model that can implement Shamir's algo= rithm to factor using super-large integers in a polynomial (even linear?) n= umber of integer arithmetic steps), (2) sudden (single) blips exceeding the usual Moore's law (and variants) fo= r future computing power (e.g. are sudden and new 100x faster transistor ma= terial, superconductors, photonics, less realistic than quantum computers)? I don't know the established answers, but would speculate: (a) quantum computers are deemed more realistic than each of (1) and (2), (b) model (1) is known [?] to affect all algorithms equally, so we must jus= t give up on it, (c) most justifications for 128-bit security already include a margin of er= ror for risk (2), (d) 256-bit security (and variants) are meant to deal with (2). Are these the established answers, or is there better answers?=20 As a research issue, I'd like to know more about (b), if it is correct. I'd like to know more about (a), the why of it, but am unlikely to understa= nd. Best regards, Dan Brown From nobody Mon May 8 10:49:27 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCD0126C23 for ; Mon, 8 May 2017 10:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb0JOW7Vz3tV for ; Mon, 8 May 2017 10:49:23 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09596126B6D for ; Mon, 8 May 2017 10:49:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 31DA9A1262; Mon, 8 May 2017 13:49:22 -0400 (EDT) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYd3+2c1E7vz; Mon, 8 May 2017 13:49:20 -0400 (EDT) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 7BB98A11A6; Mon, 8 May 2017 13:49:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> Date: Mon, 8 May 2017 10:49:19 -0700 Cc: "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <310534EA-BF8F-4160-881F-134DD30C70FC@oxy.edu> References: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Cfrg] naive question: QC vs RC vs Moore-blip 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, 08 May 2017 17:49:25 -0000 I=E2=80=99m not sure how much energy this whole subject is worth, = honestly. Remember that the reason the NSA started talking about = post-quantum when they did was to distract us from the Dual-EC random = number generator debacle. I have absolutely no doubt that people are pouring tons of money into QC = and making progress. I just don=E2=80=99t think we can take anything = said about the maturity of the technology at face value.=20 Full disclosure: my opinions are colored by the way JPLs SeaSat = spacecraft met an untimely death (and the ugly politics afterward). It = used off-the-shelf spy satellite components and JPL was not allowed to = know what their real performance was.=20 Given all of those uncertainties, wouldn=E2=80=99t our efforts be better = spent worrying about the other things we know we don=E2=80=99t know? = (And keep an eye out for things we don=E2=80=99t know we don=E2=80=99t = know.) (This is not intended as an attack on you Dan!! Just my opinion.) > On May 8, 2017, at 8:31 AM, Dan Brown = wrote: >=20 > Dear CFRG, >=20 > Please forgive my naivety on the matters below. >=20 > If quantum computers are realistic enough to warrant standards changes = (now or soon), then what about other hypothetical computers, such as: >=20 > (1) computers that can do super high-precision, as in the "real = computation" model (or whatever variant of this model that can implement = Shamir's algorithm to factor using super-large integers in a polynomial = (even linear?) number of integer arithmetic steps), >=20 > (2) sudden (single) blips exceeding the usual Moore's law (and = variants) for future computing power (e.g. are sudden and new 100x = faster transistor material, superconductors, photonics, less realistic = than quantum computers)? >=20 > I don't know the established answers, but would speculate: >=20 > (a) quantum computers are deemed more realistic than each of (1) and = (2), >=20 > (b) model (1) is known [?] to affect all algorithms equally, so we = must just give up on it, >=20 > (c) most justifications for 128-bit security already include a margin = of error for risk (2), >=20 > (d) 256-bit security (and variants) are meant to deal with (2). >=20 > Are these the established answers, or is there better answers?=20 >=20 > As a research issue, I'd like to know more about (b), if it is = correct. >=20 > I'd like to know more about (a), the why of it, but am unlikely to = understand. >=20 > Best regards, >=20 > Dan Brown >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg Personal email. hbhotz@oxy.edu From nobody Mon May 8 11:10: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 28DAF12896F for ; Mon, 8 May 2017 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDJeDRBiHXqo for ; Mon, 8 May 2017 11:09:57 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752AE128656 for ; Mon, 8 May 2017 11:09:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A8A15201C7; Mon, 8 May 2017 20:09:55 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VMttRSd1ZYJ; Mon, 8 May 2017 20:09:55 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 1EC1D2008B; Mon, 8 May 2017 20:09:55 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Mon, 8 May 2017 20:09:54 +0200 From: "Tams, Benjamin" To: Dan Brown , "cfrg@irtf.org" Thread-Topic: naive question: QC vs RC vs Moore-blip Thread-Index: AdLIDxLailn8AM7oS6K3HHWy2z/EagAFNQ5Q Date: Mon, 8 May 2017 18:09:54 +0000 Message-ID: <78B0B91A8FEB2E43B20BCCE1326131813992A221@mail-essen-01.secunet.de> References: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.9.76] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-g-data-mailsecurity-for-exchange-guid: F5DCF1E7-87CF-4290-82F1-7D1E52811BEB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] naive question: QC vs RC vs Moore-blip 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, 08 May 2017 18:09:59 -0000 > If quantum computers are realistic enough to warrant standards changes (n= ow or soon), then what about other hypothetical computers, such as: >=20 > (1) computers that can do super high-precision, as in the "real computati= on" model (or whatever variant of this model that can implement Shamir's > algorithm to factor using super-large integers in a polynomial (even line= ar?) number of integer arithmetic steps), >=20 > (2) sudden (single) blips exceeding the usual Moore's law (and variants) = for future computing power (e.g. are sudden and new 100x faster transistor= =20 > material, superconductors, photonics, less realistic than quantum compute= rs)? > > I don't know the established answers, but would speculate: >=20 > (a) quantum computers are deemed more realistic than each of (1) and (2), > I think (2) and partially (1) is more realistic than the close appearance o= f quantum computers=20 (but I do not know). > (b) model (1) is known [?] to affect all algorithms equally, so we must j= ust give up on it, Don't know if you are referring to the "real computation" model or Shamir's= factoring device. I consider it unlikely that mere improvements in factoring integers will im= prove on other algorithms equally. In fact, factoring integers is not even believed = to correspond to an NP-hard problem. For (1), I do not know much about its consequences f= rom the scratch. > (c) most justifications for 128-bit security already include a margin of = error for risk (2), > (d) 256-bit security (and variants) are meant to deal with (2). I hope so. :-) > Are these the established answers, or is there better answers?=20 Interested, too.=20 > As a research issue, I'd like to know more about (b), if it is correct. > >I'd like to know more about (a), the why of it, but am unlikely to underst= and. I think sudden Moore blips are quite realistic. But a few of them won't hel= p much in factoring or solving discrete log problems (though a little). Kind regards, Benjamin Tams From nobody Mon May 8 11:44:31 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59ED129576 for ; Mon, 8 May 2017 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 pnHpsPNMmrqJ for ; Mon, 8 May 2017 11:44:27 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 7E368128B51 for ; Mon, 8 May 2017 11:44:27 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id k91so56090390ioi.1 for ; Mon, 08 May 2017 11:44:27 -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=/QcOTpn+jvth3ky+i7cxnMVxSUvQWDc+1Uu9nZoRlXo=; b=ZQkCnTlxBa2DuWjwI744Fh4WPGfVZXvYb4j9kMw7ihejdDERCMDFhx5++lEwV8ApeG vUSfBXDM/C4wWoBa16vD2c/k4Xn6UFAIe+s9ImGAQ8+Uz+crqopYPyNQEgfotwdhki4z 9yak++5MnO5Y54jqjOBZXIJz/4rjx50U3vW6J24vX0Bdj6PMYQDic8sVl+sjfKXHSw17 bvu8HaX7QbQVvzd8B787Z9BLretbYYaTdP5nXi7tIwGfXrbqUnx7yRF68AcaXCUXXyJ4 OaCuho3BI7/1VeMPINVuOaXmd13KLekRUJojPXxLXN9pu0aVTtUxQSVrUAojEBCO1i1N C6cA== 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=/QcOTpn+jvth3ky+i7cxnMVxSUvQWDc+1Uu9nZoRlXo=; b=NE0LNY3v8ExpqbBiPtfJSr+VHqiFZ4eqqfaS02pLCdya3piQD7xjoLz+TN5YMi8/7S rNX9DsusBbSNIdFhlWUXG16JOpP8adrKmtaXCPjxWtSIhtLhPpIiPXEBu2/jioD0UiYo wBAj5OR2b8k5NQzQqdY9vy9s3wyH2dImiFMLOxN2bxnJpWbY6LUnPgwzW19iYwjD/Jd9 InJhBxXYuhZspBbfdu2dwhJvWbExyTFoXDtVzJ6/jQSgL+MLJncMWaJZ+6L4+4HD3iFB ZOQB7iaNjYfUNuHc4vXlfSexxRuRvX28VJ51nMsoiaJ2qlXqUlkfHcjo/oNAKLKrWVpr T7vw== X-Gm-Message-State: AODbwcB5OUZAA0nw+yZhJendVIDK0k8WVmXPTbmq4aGqyAhxJDc6xVjI cUzcPiwqWUYsIh+ANuDi3rM863WnYA== X-Received: by 10.107.128.98 with SMTP id b95mr19599840iod.25.1494269066881; Mon, 08 May 2017 11:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.212 with HTTP; Mon, 8 May 2017 11:44:26 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B13ECA@XMB116CNC.rim.net> From: Philip Lafrance Date: Mon, 8 May 2017 14:44:26 -0400 Message-ID: To: Dan Brown Cc: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113dfdaeee3847054f07a0bc Archived-At: Subject: Re: [Cfrg] naive question: QC vs RC vs Moore-blip 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, 08 May 2017 18:44:30 -0000 --001a113dfdaeee3847054f07a0bc Content-Type: text/plain; charset=UTF-8 I wanted to make a comment about the introduction of more powerful, but classical computers. There is a good thermodynamics argument to be made here. Even absurdly powerful classical devices need to actually perform the bit operations. Consider the 128 bit level of security. I'm being vague here, but I am pretty sure if even if you assume that every operation is just a bit-flip, then 2^{128} such operations would still take >1% of the Earth's annual power output. Maybe I am being slightly inaccurate, but the point is that even high powered super computers simply don't have the time or energy to say factor secure RSA moduli (try something with 256-bits of classic security!). This is one of the reasons that quantum computers are so dangerous to public key crypto, they compute in a fundamentally different way which more or less avoid the thermodynamics problem. For this reason, I believe quantum-resistant standards are more important for us to consider than contradictions to Moore's law. However, this is far from the best possible argument for quantum-resistance. -Philip Lafrance On Mon, May 8, 2017 at 11:31 AM, Dan Brown wrote: > Dear CFRG, > > Please forgive my naivety on the matters below. > > If quantum computers are realistic enough to warrant standards changes > (now or soon), then what about other hypothetical computers, such as: > > (1) computers that can do super high-precision, as in the "real > computation" model (or whatever variant of this model that can implement > Shamir's algorithm to factor using super-large integers in a polynomial > (even linear?) number of integer arithmetic steps), > > (2) sudden (single) blips exceeding the usual Moore's law (and variants) > for future computing power (e.g. are sudden and new 100x faster transistor > material, superconductors, photonics, less realistic than quantum > computers)? > > I don't know the established answers, but would speculate: > > (a) quantum computers are deemed more realistic than each of (1) and (2), > > (b) model (1) is known [?] to affect all algorithms equally, so we must > just give up on it, > > (c) most justifications for 128-bit security already include a margin of > error for risk (2), > > (d) 256-bit security (and variants) are meant to deal with (2). > > Are these the established answers, or is there better answers? > > As a research issue, I'd like to know more about (b), if it is correct. > > I'd like to know more about (a), the why of it, but am unlikely to > understand. > > Best regards, > > Dan Brown > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a113dfdaeee3847054f07a0bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wanted to make a comment about the introduction of more = powerful, but classical computers.

There is a good therm= odynamics argument to be made here. Even absurdly powerful classical device= s need to actually perform the bit operations.=C2=A0
Consider the= 128 bit level of security. I'm being vague here, but I am pretty sure = if even if you assume that every operation is just a bit-flip, then 2^{128}= such operations would still take >1% of the Earth's annual power ou= tput. Maybe I am being slightly inaccurate, but the point is that even high= powered super computers simply don't have the time or energy to say fa= ctor secure RSA moduli (try something with 256-bits of classic security!). = This is one of the reasons that quantum computers are so dangerous to publi= c key crypto, they compute in a fundamentally different way which more or l= ess avoid the thermodynamics problem.

For this rea= son, I believe quantum-resistant standards are more important for us to con= sider than contradictions to Moore's law. However, this is far from the= best possible argument for quantum-resistance.

-P= hilip Lafrance

On Mon, May 8, 2017 at 11:31 AM, Dan Brown <<= a href=3D"mailto:danibrown@blackberry.com" target=3D"_blank">danibrown@blac= kberry.com> wrote:
Dear CFR= G,

Please forgive my naivety on the matters below.

If quantum computers are realistic enough to warrant standards changes (now= or soon), then what about other hypothetical computers, such as:

(1) computers that can do super high-precision, as in the "real comput= ation" model (or whatever variant of this model that can implement Sha= mir's algorithm to factor using super-large integers in a polynomial (e= ven linear?) number of integer arithmetic steps),

(2) sudden (single) blips exceeding the usual Moore's law (and variants= ) for future computing power (e.g. are sudden and new 100x faster transisto= r material, superconductors, photonics, less realistic than quantum compute= rs)?

I don't know the established answers, but would speculate:

(a) quantum computers are deemed more realistic than each of (1) and (2),
(b) model (1) is known [?] to affect all algorithms equally, so we must jus= t give up on it,

(c) most justifications for 128-bit security already include a margin of er= ror for risk (2),

(d) 256-bit security (and variants) are meant to deal with (2).

Are these the established answers, or is there better answers?

As a research issue, I'd like to know more about (b), if it is correct.=

I'd like to know more about (a), the why of it, but am unlikely to unde= rstand.

Best regards,

Dan Brown


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

--001a113dfdaeee3847054f07a0bc-- From nobody Tue May 9 02:22:19 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D848A129B76 for ; Tue, 9 May 2017 02:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEC_maa7sIN4 for ; Tue, 9 May 2017 02:22:16 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951F2129B69 for ; Tue, 9 May 2017 02:22:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,313,1491260400"; d="scan'208";a="181618324" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 09 May 2017 10:17:09 +0100 X-IronPort-AV: E=Sophos;i="5.38,313,1491260400"; d="scan'208";a="170487425" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 09 May 2017 10:16:52 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Tue, 9 May 2017 10:16:52 +0100 From: "Dearlove, Christopher (UK)" To: "Blumenthal, Uri - 0553 - MITLL" , Paul Hoffman CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography Thread-Index: AQHSxFyyrdxv3Y4EbE29PkiMhZEf96Hj5ceAgAWiEoCAANDSgIAAEN0AgAAJkwCAAAIdAIAAAcAAgAFIm+A= Date: Tue, 9 May 2017 09:16:52 +0000 Message-ID: References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> In-Reply-To: <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 09:22:18 -0000 VGhlIE5TQSwgd2hvIHByb2JhYmx5IGhhdmUgdGhlIGxvbmdlc3QgdGltZXNjYWxlcywgc2F5ICho dHRwczovL3d3dy5pYWQuZ292L2lhZC9saWJyYXJ5L2lhLWd1aWRhbmNlL2lhLXNvbHV0aW9ucy1m b3ItY2xhc3NpZmllZC9hbGdvcml0aG0tZ3VpZGFuY2UvYXNzZXRzL3B1YmxpYy91cGxvYWQvQ05T QS1TdWl0ZS1hbmQtUXVhbnR1bS1Db21wdXRpbmctRkFRLnBkZiwgb24gcGFnZSA4KToNCg0KIkFs Z29yaXRobXMgb2Z0ZW4gcmVxdWlyZSAyMCB5ZWFycyB0byBiZSBmdWxseSBkZXBsb3llZCBvbiBO U1MuIE5TUyBlcXVpcG1lbnQgaXMgb2Z0ZW4gdXNlZCBmb3IgMzAgeWVhcnMgb3IgbW9yZS4gTmF0 aW9uYWwgc2VjdXJpdHkgaW5mb3JtYXRpb24gaW50ZWxsaWdlbmNlIHZhbHVlIGlzIG9mdGVuIDMw IHllYXJzIChzb21ldGltZXMgbW9yZSkgYWx0aG91Z2ggaXQgbWF5IHZhcnkgZGVwZW5kaW5nIG9u IGNsYXNzaWZpY2F0aW9uLCBzZW5zaXRpdml0eSwgYW5kIHN1YmplY3QuIg0KDQpbTlNTID0gTmF0 aW9uYWwgU2VjdXJpdHkgU3lzdGVtXQ0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBM YWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6IMKgKzQ0IDMzMDAgNDY3NTAwIMKg fCDCoEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93 LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xh bmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFy Y2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IENmcmcgW21haWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJl aGFsZiBPZiBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwNClNlbnQ6IDA4IE1heSAyMDE3 IDE1OjM1DQpUbzogUGF1bCBIb2ZmbWFuDQpDYzogY2ZyZ0BpcnRmLm9yZw0KU3ViamVjdDogUmU6 IFtDZnJnXSBOZXcgZHJhZnQgb24gdGhlIHRyYW5zaXRpb24gZnJvbSBjbGFzc2ljYWwgdG8gcG9z dC1xdWFudHVtIGNyeXB0b2dyYXBoeQ0KDQpPbiA1LzgvMTcsIDEwOjI4IEFNLCAiUGF1bCBIb2Zm bWFuIiA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPiB3cm90ZToNCiAgICA+IFdvdWxkbuKAmXQgeW91 IGFncmVlIHRoYXQgZm9yIGxvbmctdGVybSBkb2N1bWVudHMgKHRob3NlIHRoYXQgbmVlZCB0byAN CiAgICA+IHN1cnZpdmUgZm9yIDE1KyAtIDIwKyB5ZWFycyBmcm9tIG5vdykgdGhlIOKAnG5lZWQg dG8gY2hhbmdl4oCdIGlzIG5vdyANCiAgICA+IHdpdGggYSBwcmV0dHkgaGlnaCBwcm9iYWJpbGl0 eT8NCiAgICANCiAgICBOby4gVGhhdCBpcywgSSBoYXZlbid0IHNlZW4gZXZpZGVuY2UgdGhhdCB0 aGVyZSB3aWxsIGJlIHF1YW50dW0gDQogICAgY29tcHV0ZXJzIGluIDE1IHRvIDIwIHllYXJzIGZy b20gbm93IHRoYXQgd2lsbCBiZSBhYmxlIHRvIGJyZWFrIA0KICAgIGNsYXNzaWNhbCBjcnlwdG9n cmFwaHkgdXNpbmcgY3VycmVudCBrZXkgc2l6ZXMuIFRoZSBzYW1lIGlzIHRydWUgaWYgeW91IA0K ICAgIHNhaWQgIjUwIHllYXJzIi4gDQoNCkZpcnN0LCBJ4oCZbSBzdXJlIHRoZXJlIGFyZSBkb2N1 bWVudHMgbm93IHRoYXQgbmVlZCBhIOKAnHNlY3VyZSBsaWZl4oCdIGxvbmdlciB0aGFuIDIwIG9y IGV2ZW4gNTAgeWVhcnMuDQoNCiAgICBPZiBjb3Vyc2UsIEkgbWlnaHQgaGF2ZSBtaXNzZWQgc29t ZXRoaW5nIGluIHRoZSBlYXJseSANCiAgICByZXNlYXJjaCBmb3IgdGhlIC0wMCBkcmFmdCwgc28g aWYgeW91IGhhdmUgcG9pbnRlcnMgdG8gc3VjaCANCiAgICBjYWxjdWxhdGlvbnMsIHRoYXQgd291 bGQgYmUgZ3JlYXQuDQoNCkFsYXMsIG15IGNyeXN0YWwgYmFsbCBpcyBvdXQgb2Ygb3JkZXIgcmln aHQgbm93LiBCdXQgc2NpZW50aWZpYyBwcm9ncmVzcyB0ZW5kcyB0byBiZSBub3QgZXhhY3RseSBw cmVkaWN0YWJsZS9jYWxjdWxhdGUtYWJsZS4gRS5nLiwgZGlkIHlvdSBleHBlY3QgdG8gdGFsayBh Ym91dCDigJxxdWFudHVtIGNvbXB1dGVycyBicmVha2luZyBjcnlwdG/igJ0gMjAgeWVhcnMgYWdv PyBJIGRpZG7igJl0Lg0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBw bGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZ b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns b3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqCg== From nobody Wed May 10 11:52:14 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 9064D12EA42 for ; Wed, 10 May 2017 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.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 4J1cXUy58X4X for ; Wed, 10 May 2017 11:52:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A81512E858 for ; Wed, 10 May 2017 11:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 974653004DB for ; Wed, 10 May 2017 14:52:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yE8IZqnfEttO for ; Wed, 10 May 2017 14:52:08 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2009B3000FF; Wed, 10 May 2017 14:52:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> Date: Wed, 10 May 2017 14:52:07 -0400 Cc: IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> To: Uri Blumenthal , Paul Hoffman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 10 May 2017 18:52:12 -0000 >> Wouldn=E2=80=99t you agree that for long-term documents (those that = need to=20 >> survive for 15+ - 20+ years from now) the =E2=80=9Cneed to change=E2=80= =9D is now=20 >> with a pretty high probability? >=20 > No. That is, I haven't seen evidence that there will be quantum=20 > computers in 15 to 20 years from now that will be able to break=20 > classical cryptography using current key sizes. The same is true if = you=20 > said "50 years".=20 >=20 > First, I=E2=80=99m sure there are documents now that need a =E2=80=9Csec= ure life=E2=80=9D longer than 20 or even 50 years. Children born this year might need their healthcare records protected = from the discovery of a quantum computer before they die. Russ From nobody Wed May 10 12:35: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 CC74912EA94 for ; Wed, 10 May 2017 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIBnzDbhS9sG for ; Wed, 10 May 2017 12:35:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D252112EA8D for ; Wed, 10 May 2017 12:35:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6596ABE2E; Wed, 10 May 2017 20:35:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTxwil03DGnL; Wed, 10 May 2017 20:35:28 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB9E9BDF9; Wed, 10 May 2017 20:35:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1494444928; bh=S+nCg80PK3NZr3nQh2dJB8XzyvaaZP5cpyOSfsvmFbo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=r21nlUVCqPgqJgWKJdbFkTz8JGMkfG8ngJ85int/FHGTS05li8onqWvy9RMNSUJ4P gLvuY3a05xzI9AuT6SBdGSGdKVWsTlWNDNGWQ4FaMpHsZ9J8wC/zMWrK+U7jyBYPI2 VkCn2+Q+jOWs+BppaU+0WXxWG0tVmQbCNzjh9eeo= To: Russ Housley , Uri Blumenthal , Paul Hoffman References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> Cc: IRTF CFRG From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <76c04fcf-bdc5-54b5-a729-e4be9bf6fe66@cs.tcd.ie> Date: Wed, 10 May 2017 20:35:25 +0100 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G84jVvflG9tLAAiUHFvkMqHX40JNj8Qo7" Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 10 May 2017 19:35:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G84jVvflG9tLAAiUHFvkMqHX40JNj8Qo7 Content-Type: multipart/mixed; boundary="T7If7CDu1u2wkT0JUkNmj00O68U0sO6AP"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Uri Blumenthal , Paul Hoffman Cc: IRTF CFRG Message-ID: <76c04fcf-bdc5-54b5-a729-e4be9bf6fe66@cs.tcd.ie> Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> In-Reply-To: --T7If7CDu1u2wkT0JUkNmj00O68U0sO6AP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/05/17 19:52, Russ Housley wrote: > Children born this year might need their healthcare records protected > from the discovery of a quantum computer before they die. Genomic data from any of us is liable to remain sensitive for our grandchildren, in 100 years time. It's sensitivity may even increase the longer one waits. S. --T7If7CDu1u2wkT0JUkNmj00O68U0sO6AP-- --G84jVvflG9tLAAiUHFvkMqHX40JNj8Qo7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZE2t9AAoJEC88hzaAX42i2tkH/jps8sTNaYOkF4MdvaaJ7991 +8hPzKEA96zBrnKzj975IwtwC4udeH08rYL0vxtLKJpek4r8fhSEMM+5FKZPFVyQ 4YGkasg0VCypEkaqFlIP0Q6TJSrYTCb2CvocP86UkmUB/omVwxI2aqQSfSMuW00p NlMkAkdJmAlrv2HLKSmH70lLeCw4ZvtLMNo9e3tmuiBTumzGJjCAu24/u73e+bUA f1fRNRTazevE7u63QVe4ANn+M9jecN+KUqgW16jGDzjWvWUIiegusXG+YU06D5yk 1wC3YqU6lMzB6d82rMWDoZjNssVZPlfTCZa3REdP3vRU69qKr4x5iW5G5rpgdrU= =8EvX -----END PGP SIGNATURE----- --G84jVvflG9tLAAiUHFvkMqHX40JNj8Qo7-- From nobody Wed May 10 14:52:41 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB018129445 for ; Wed, 10 May 2017 14:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do51-lA8Dm6k for ; Wed, 10 May 2017 14:52:34 -0700 (PDT) Received: from mail-1.ca.inter.net (mail-1.ca.inter.net [208.85.220.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3391292CE for ; Wed, 10 May 2017 14:52:34 -0700 (PDT) Received: from localhost (offload-3.ca.inter.net [208.85.220.70]) by mail-1.ca.inter.net (Postfix) with ESMTP id 727142EA2B1; Wed, 10 May 2017 17:52:33 -0400 (EDT) Received: from mail-1.ca.inter.net ([208.85.220.69]) by localhost (offload-3.ca.inter.net [208.85.220.70]) (amavisd-new, port 10024) with ESMTP id 1dDwxRmys8hD; Wed, 10 May 2017 17:52:32 -0400 (EDT) Received: from [192.168.168.17] (toroon0246w-lp130-02-65-95-160-230.dsl.bell.ca [65.95.160.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: outer@interlog.com) by mail-1.ca.inter.net (Postfix) with ESMTPSA id 4D64D2EA4A2; Wed, 10 May 2017 17:52:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Richard Outerbridge In-Reply-To: <76c04fcf-bdc5-54b5-a729-e4be9bf6fe66@cs.tcd.ie> Date: Wed, 10 May 2017 17:52:31 -0400 Cc: Russ Housley , Uri Blumenthal , Paul Hoffman , IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> <76c04fcf-bdc5-54b5-a729-e4be9bf6fe66@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 10 May 2017 21:52:39 -0000 > On 2017-05-10 (130), at 15:35:25, Stephen Farrell = wrote: >=20 > On 10/05/17 19:52, Russ Housley wrote: >> Children born this year might need their healthcare records protected >> from the discovery of a quantum computer before they die. >=20 > Genomic data from any of us is liable to remain sensitive for our great- > grandchildren, in 100 years time. It's sensitivity may even increase > the longer one waits. ? __outer From nobody Wed May 10 21:02: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 2A1CB1293E0 for ; Wed, 10 May 2017 21:02:35 -0700 (PDT) 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, 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 2b8LVACEBP-M for ; Wed, 10 May 2017 21:02:32 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 C72AD1200FC for ; Wed, 10 May 2017 21:02:32 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l135so7112839ywb.2 for ; Wed, 10 May 2017 21:02:32 -0700 (PDT) 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; bh=X13SZx/hsTSJ4dSpPobBvCIf6HvU8GJj4OzHe85ZHo8=; b=Bwpp3oPsUYxqi5jntnuWzbY8g8Tjk2hKIB9lHTZDCw7/5AkQESBXYvIaq6qr0ebQNG EOHjYRUJ8sKmqA1W+dkmezFWpy5IAV48PWLyFHRHZedOilYYD3w9d1g/cwpu5ZdDpJG8 GPH0IeE7z/9RUxnMqcSpU9BTxCZVKTPrUJFsH/GRKS2TVrUwBxWdjyJCWVCx17EF0AcA d+DFhRR3ITfKHYop0Z8/S5qzC4tJFt8Svk899JNbqEdH4Y/6jWQtPUtx9rkPPbd+b1Zt PUCttaUiBdVHlfhNdEwgCk0sbStN+oU93Ho0X0umC5bPeJRIucBDFJ4dBLUIy3NEoaMk lsSg== 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; bh=X13SZx/hsTSJ4dSpPobBvCIf6HvU8GJj4OzHe85ZHo8=; b=GdmKAsf3C3dp11Y+lHLEgFFFI43UKjwLEDsIjgD3l52QlNeNEVppxbi+569IJ4o9RJ LgdTuUPBGgzF/x2rpjtIBNxCvSyBM2o5LwXraDFJQbyJFXa3CY6irrWiTE9/ZkzVdzmG cKGsKhmMcNYCOAjUKo/bVbsPaFu1686dRLGR3EsbbVr0SjUVwh4rgE7S4X4TV3YDFH2B 5p2oQZohjwYGIUENgFczoGIYYyMWEWwuR+/qZNZsESVYP/jRomVBLhHier7hNO611Z7V XeSjW6xmClaWsSDfrk9GhcWkMuwQz8PhBjTg0nO0LahywLkDeI69LfLK4tTFfFzvPeVp mDjg== X-Gm-Message-State: AODbwcAjDugfG6cnHdacC5Mc8QBiXoRFEGfNTad1L2Pm2iX5ahvN3xfd u9xB3aIxPGmioZUyuooRPzfWgt95ig== X-Received: by 10.129.71.65 with SMTP id u62mr7851998ywa.174.1494475351886; Wed, 10 May 2017 21:02:31 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.72.137 with HTTP; Wed, 10 May 2017 21:02:01 -0700 (PDT) In-Reply-To: References: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de> <9E0DFD44-3000-4E5B-BAE6-2EF74DB3EA4E@vpnc.org> <0d785b8b616846e9aa0eda962d1aade5@usma1ex-dag1mb1.msg.corp.akamai.com> <48F06B9A-7ED4-4711-901C-AA17DD690BC6@vpnc.org> <8076F68B-F7B1-487B-86ED-B6DCFE93EBF2@ll.mit.edu> <58C7D7DD-B129-4FF1-B091-9AA8FAA46607@ll.mit.edu> <76c04fcf-bdc5-54b5-a729-e4be9bf6fe66@cs.tcd.ie> From: Hugo Krawczyk Date: Thu, 11 May 2017 00:02:01 -0400 X-Google-Sender-Auth: vTO5Cx8xhtl9hd8FuFfkBVqe-Qc Message-ID: To: Stephen Farrell Cc: Russ Housley , Uri Blumenthal , Paul Hoffman , IRTF CFRG Content-Type: multipart/alternative; boundary=001a114d72b479927c054f37a87e Archived-At: Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography 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, 11 May 2017 04:02:35 -0000 --001a114d72b479927c054f37a87e Content-Type: text/plain; charset=UTF-8 I want to highlight the importance of the post-quantum work regardless of the post-quantum prospects, namely, independently of the predictions and feasibility of constructing Shor-grade quantum computers. People claim that we need to move to quantum-resistant crypto now (or in the near future) since there is information created now that needs to stay secret for 30-50 (even 100) years. My strong recommendation for such applications is to NOT use public key (PK) encryption or PK-based online key exchange to generate encryption keys for this data. Rather exchange keys offline and onion-encrypt with several symmetric ciphers and over-sized keys (twice the security parameter). This recommendation is *independent* of the prospects of quantum computation (QC) reaching the point in which it can break PK cryptosystems. It is rather based on the precarious standing of all our public key algorithms and their potential vulnerabilities to *classical* cryptanalysis. Is the probability of ECC and/or RSA being broken by mathematical cryptanalysis higher or lower than the probability of these systems being broken by QC in x years? I don't know. But I do know that while a powerful quantum computer will not be built overnight, a devastating mathematical break (of EC or RSA cryptography) could happen in the middle of the night. All you need is one bright person dreaming the right idea. So what I am saying is that we need to thank QC for drawing attention to the need to diversify our algorithms, to build our protocols with algorithm agility and negotiation, to invest serious funding in researching new public key mechanisms, particularly in the area of lattice-based cryptography (where many other benefits are likely to arise), and to make us all think about how to *really* ensure long-term secrecy. We should have done all of this without the threat of powerful quantum computers, but without it we wouldn't have had the attention and funding we now have to address these most important problems. So, thanks QC! You are already making our systems more durably secure! Now, let's not allow the speculations surrounding the feasibility and timing of QC distract us from the really important task of diversifying PK Cryptography. Keep the attention, focus and funding coming. Hugo --001a114d72b479927c054f37a87e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= I want to highlight the importance of th= e post-quantum work regardless of the post-quantum prospects, namely, indep= endently of the predictions and feasibility of constructing Shor-grade quan= tum computers.

People claim that we need to move to quantum-resistan= t crypto now (or in the near future) since there is information created now= that needs to stay secret for 30-50 (even 100) years. My strong recommenda= tion for such applications is to NOT use public key (PK) encryption or PK-b= ased online key exchange to generate encryption keys for this data. Rather = exchange keys offline and onion-encrypt with several symmetric ciphers and = over-sized keys (twice the security parameter).

This recommendation = is *independent* of the prospects of quantum computation (QC) reaching the = point in which it can break PK cryptosystems. It is rather based on the pre= carious standing of all our public key algorithms and their potential vulne= rabilities to *classical* cryptanalysis.=C2=A0

Is the probability of= ECC and/or RSA being broken by mathematical cryptanalysis higher or lower = than the probability of these systems being broken by QC in x years?=C2=A0 = I don't know. But I do know that while a powerful quantum computer will= not be built overnight, a devastating mathematical break (of EC or RSA cry= ptography) could happen in the middle of the night. All you need is one bri= ght person dreaming the right idea.=C2=A0

So what I am saying is tha= t we need to thank QC for drawing attention to the need to diversify our al= gorithms, to build our protocols with algorithm agility and negotiation, to= invest serious funding in researching new public key mechanisms, particula= rly in the area of lattice-based cryptography (where many other benefits ar= e likely to arise), and to make us all think about how to *really* ensure l= ong-term secrecy. We should have done all of this without the threat of pow= erful quantum computers, but without it we wouldn't have had the attent= ion and funding we now have to address these most important problems.

=
et's not allo= w the speculations surrounding the feasibility and timing of QC distract us= from the really important task of diversifying PK Cryptography.=C2=A0 Keep= the attention, focus and funding coming.

Hugo
--001a114d72b479927c054f37a87e-- From nobody Thu May 11 03:55: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 DF76A12EBF5 for ; Thu, 11 May 2017 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_TVD_FUZZY_SECURITIES=0.01] 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 CVkM8MG34uhh for ; Thu, 11 May 2017 03:55:03 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 ECB8912EBFD for ; Thu, 11 May 2017 03:53:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,324,1491256800"; d="scan'208,217";a="223250371" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail3-relais-sop.national.inria.fr with ESMTP; 11 May 2017 12:53:01 +0200 Date: Thu, 11 May 2017 12:53:00 +0200 (CEST) From: Sofiane Lagraa To: cfrg@irtf.org Message-ID: <1058281229.10090588.1494499980882.JavaMail.zimbra@inria.fr> In-Reply-To: <1414011006.10090387.1494499930774.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10090587_1560173357.1494499980881" X-Originating-IP: [62.28.67.222] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF53 (Linux)/8.0.9_GA_6191) Thread-Topic: Call for Papers: International Workshop on Secure Internet of Things - SIoT Thread-Index: TJwdkKYieY+DVG1ddU+y8/pamHt6wg== Archived-At: Subject: [Cfrg] Call for Papers: International Workshop on Secure Internet of Things - SIoT 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, 11 May 2017 10:55:06 -0000 ------=_Part_10090587_1560173357.1494499980881 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ======================== Apologies for any cross-posting ======================== CfP - International Workshop on Secure Internet of Things - SIoT 2017, 14 - 15 of September, Norwegian University of Science and Technology (NTNU), Oslo, Norway Workshop Description and Scope ============================== The International Workshop on Secure Internet of Things 2017 (SIoT 2017) will be held in conjunction with the European Symposium on Research in Computer Security (ESORICS 2017) in Oslo, Norway at the Norwegian University of Science and Technology (NTNU), on September 14-15 2017. The proceedings of the workshop will be submitted to IEEE Explore. SIoT is a community where interested stakeholders, from academia and industry, can present their original work on providing a secure environment for connecting systems in an Internet-specific structure. The wide spread of mobile and embedded devices, able to connect to a network and share information, requires a careful look at the security risks taken by end users. In this context, the workshop will focus on contributions related to the security of mesh and machine-to-machine networks, secure software stacks running on ubiquitous network nodes, and algorithms used to provide secure end-to-end communication between nodes. Workshop Topics =============== The focus of this workshop is to create a secure environment for connecting systems in an Internet-specific structure. These may include, but are not limited to, the following topics: * Threat Models in Internet of Things * Attack Strategies for Internet of Things * Security Architectures * Secure Mobile Applications * Secure Mobility Management * Intrusion and Malware Detection * Security in Wireless Sensor Networks * Reliable Interactions with Network Services * System and Data Integrity * Scalability and Robustness for Internet of Things * Identity Management in Internet of Things * Trustworthiness in Internet of Things * Secure Operating Systems * Privacy in Internet of Things * Adaptive Security in Internet of Things Important Dates =============== * Submission Deadline: June 25th, 2017 * Author Notification: July 29th, 2017 * Camera Ready: August 14th, 2017 * SIoT Workshop and ESORICS Conference: September 14-15th, 2017 Submission Guidelines ===================== Papers submitted for publishing must adhere to the IEEE template and should be at most 10 pages in this format, including the bibliography and well-marked appendices. The original settings of textwidth and textheight should be preserved. Accepted papers will be submitted to IEEE. Note that authors of accepted papers must guarantee that one of the authors will register and present the paper at the conference. For more details, please visit our website: http://siot-workshop.org/ ------=_Part_10090587_1560173357.1494499980881 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Apologies for any cross-posti= ng
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

CfP - International Workshop on Secure Internet of Things - SIoT= 2017, 14 - 15  of September, Norwegian University of Science and Tech= nology (NTNU), Oslo, Norway

Workshop Description and Scope
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

The International Workshop on Secure Internet of Thing= s 2017 (SIoT 2017) will be held in conjunction with the European Symposium = on Research in Computer Security (ESORICS 2017) in  Oslo, Norway at th= e  Norwegian University of Science and Technology (NTNU), on September= 14-15 2017. The proceedings of the workshop will be submitted to IEEE Expl= ore.

SIoT is a community where interested stakeholders, from academ= ia and industry, can present their original work on providing a secure envi= ronment for connecting systems in an Internet-specific structure. The wide = spread of mobile and embedded devices, able to connect to a network and sha= re information, requires a careful look at the security risks taken by end = users. In this context, the workshop will focus on contributions related to= the security of mesh and machine-to-machine networks, secure software stac= ks running on ubiquitous network nodes, and algorithms used to provide secu= re end-to-end communication between nodes.

Workshop Topics
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The focus of this workshop i= s to create a secure environment for connecting systems in an Internet-spec= ific structure. These may include, but are not limited to, the following to= pics:
* Threat Models in Internet of Things
* Attack Strategies for= Internet of Things
* Security Architectures
* Secure Mobile Applic= ations
* Secure Mobility Management
* Intrusion and Malware Detecti= on
* Security in Wireless Sensor Networks
* Reliable Interactions w= ith Network Services
* System and Data Integrity
* Scalability and = Robustness for Internet of Things
* Identity Management in Internet of = Things
* Trustworthiness in Internet of Things
* Secure Operating S= ystems
* Privacy in Internet of Things
* Adaptive Security in Inter= net of Things

Important Dates
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
* Submission Deadline: June 25th, 2017
* Author Notifi= cation: July 29th, 2017
* Camera Ready: August 14th, 2017
* SIoT Wo= rkshop and ESORICS Conference: September 14-15th, 2017

Submission Gu= idelines
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Papers submitted for publishing must adhere to the IEEE template an= d should be at most 10 pages in this format, including the bibliography and= well-marked appendices. The original settings of textwidth and textheight = should be preserved.

Accepted papers will be submitted to IEEE. Not= e that authors of accepted papers must guarantee that one of the authors wi= ll register and present the paper at the conference.

For more detai= ls, please visit our website: http://siot-workshop.org/

= ------=_Part_10090587_1560173357.1494499980881-- From nobody Thu May 11 17: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 28729129A90 for ; Thu, 11 May 2017 17:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkzE1rok1a8h for ; Thu, 11 May 2017 17:19:20 -0700 (PDT) Received: from delta.cs.cinvestav.mx (delta.cs.cinvestav.mx [148.247.102.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D93912EB78 for ; Thu, 11 May 2017 17:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 6ADC45C1400; Thu, 11 May 2017 19:14:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.cinvestav.mx Received: from delta.cs.cinvestav.mx ([127.0.0.1]) by localhost (delta.cs.cinvestav.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkf2764FV+60; Thu, 11 May 2017 19:14:09 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id 955635C1412; Thu, 11 May 2017 19:14:09 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 2DB895C1400; Thu, 11 May 2017 19:14:09 -0500 (CDT) Date: Thu, 11 May 2017 19:14:09 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: "cfrg@irtf.org" cc: =?ISO-8859-15?Q?Julio_C=E9sar_Lopez?= , Thomaz Oliveira , huseyin.hisil@yasar.edu.tr In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-141290138-861638051-1494547473=:25089" Content-ID: Archived-At: Subject: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 00:19:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---141290138-861638051-1494547473=:25089 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Dear CFRG community, We would like to draw your attention to an improved version of our IACR pre-print 2017/264 now entitled: "How to (pre-)compute a ladder" In this revised version, we present an improved differential addition formula that uses pre-computation to match the computational cost of the classical Montgomery differential addition. Accordingly, our estimates suggest that a full implementation of our pre-computable ladder proposal should outperform state-of-the-art software implementations of the X25519 and X448 functions by a 40% speedup when working in the fixed-point scenario. We would be delighted to receive feedback (including sightings of typos) from the CFRG community. With best regards, Thomaz Oliveira, Julio Lpez, Hseyin Hisil and Francisco Rodrguez-Henrquez ---141290138-861638051-1494547473=:25089-- From nobody Fri May 12 14:19: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 592CC13149B for ; Fri, 12 May 2017 14:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shiftleft.org 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 w0Ni5y8YwjNY for ; Fri, 12 May 2017 14:19:42 -0700 (PDT) Received: from astral.shiftleft.org (vpn.shiftleft.org [52.40.228.30]) (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 68E16129C01 for ; Fri, 12 May 2017 14:15:02 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.244]) (Authenticated sender: mike) by astral.shiftleft.org (Postfix) with ESMTPSA id 4161BA0061; Fri, 12 May 2017 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiftleft.org; s=sldo; t=1494623701; bh=cQmpyCZL/d8zBIuQZPEEfGDdCuNjWLmv6Y/hht9hF8A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=Rg7/T1gXAI/YfNQldTJGllRaajY/MZ/LFc32M2IdAZ42RZZD5BC26IWkK7EmbT04e 4ptOK3VbpMzlCrpkGXxFJ9PU3w66M9jDeI5W8PaW5CIhBzpGhUwI4ZwOOUb739TlqQ vPbRx3jnxMSPa8I1liY0r1y+TtMowb9qtZ7p4MHU= From: Mike Hamburg Message-Id: <65F948B0-58FB-4073-B3D1-70B6ACB6C832@shiftleft.org> Content-Type: multipart/signed; boundary="Apple-Mail=_09B506A7-1BBE-4797-A5E2-930E29C1F42E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 12 May 2017 14:15:00 -0700 In-Reply-To: Cc: "cfrg@irtf.org" , =?utf-8?Q?Julio_C=C3=A9sar_Lopez?= , Thomaz Oliveira , huseyin.hisil@yasar.edu.tr To: Francisco Rodriguez- Henriquez References: X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at astral X-Virus-Status: Clean Archived-At: Subject: Re: [Cfrg] How to (pre-)compute a ladder [revised version] X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:19:45 -0000 --Apple-Mail=_09B506A7-1BBE-4797-A5E2-930E29C1F42E Content-Type: multipart/alternative; boundary="Apple-Mail=_B2F77B8F-D792-4AF5-A27B-6FE29D28205E" --Apple-Mail=_B2F77B8F-D792-4AF5-A27B-6FE29D28205E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Francisco et al, This is a clever and useful piece of work. It=E2=80=99s a good = intermediate between just using the standard Montgomery ladder for = everything, and going to a full Edwards implementation with combs or = something. It especially seems useful where power analysis resistance = is required, because other precomputation methods usually aren=E2=80=99t = suitable. The RTL Montgomery ladder (or Joye double-add ladder) is = already known to be useful in this situation, at least with some = modification to prevent coordinates from staying the same between = iterations. Since you=E2=80=99re speeding up the RTL Montgomery ladder, = your optimization can slot right in to some implementations. You should probably compare to existing Edwards precomputation methods = in your paper, since they are the likely alternative to your technique. = In particular, I noticed that you compared against the EBACS version of = Ed448-Goldilocks. With a fixed base point, your method uses 41% less = time for the Montgomery ladder with a 25kiB table. However, the EBACS = version of Ed448-Goldilocks doesn=E2=80=99t use the Montgomery ladder = for fixed-base scalarmul. Instead it uses a combs algorithm, which uses = a 15kiB table and takes about 70% less time than the Montgomery ladder; = see https://bench.cr.yp.to/results-dh.html = . Libdecaf likewise uses = precomputed combs for fixed-base scalarmul. But your new technique is = certainly simpler. Cheers, =E2=80=94 Mike > On May 11, 2017, at 5:14 PM, Francisco Rodriguez- Henriquez = wrote: >=20 > Dear CFRG community, >=20 > We would like to draw your attention to an improved version of our = IACR pre-print 2017/264 now entitled: >=20 > "How to (pre-)compute a ladder" >=20 > In this revised version, we present an improved differential addition = formula that uses pre-computation to match the computational cost of the = classical Montgomery differential addition. >=20 > Accordingly, our estimates suggest that a full implementation of our = pre-computable ladder proposal should outperform state-of-the-art = software implementations of the X25519 and X448 functions by a 40% = speedup when working in the fixed-point scenario. >=20 > We would be delighted to receive feedback (including sightings of = typos) from the CFRG community. >=20 > With best regards, >=20 > Thomaz Oliveira, Julio L=C3=B3pez, H=C3=BCseyin Hisil and Francisco = Rodr=C3=ADguez-Henr=C3=ADquez_____________________________________________= __ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_B2F77B8F-D792-4AF5-A27B-6FE29D28205E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Francisco et al,
This is a clever and useful piece of = work.  It=E2=80=99s a good intermediate between just using the = standard Montgomery ladder for everything, and going to a full Edwards = implementation with combs or something.  It especially seems useful = where power analysis resistance is required, because other = precomputation methods usually aren=E2=80=99t suitable.  The RTL = Montgomery ladder (or Joye double-add ladder) is already known to be = useful in this situation, at least with some modification to prevent = coordinates from staying the same between iterations.  Since = you=E2=80=99re speeding up the RTL Montgomery ladder, your optimization = can slot right in to some implementations.

You should probably compare to existing = Edwards precomputation methods in your paper, since they are the likely = alternative to your technique.  In particular, I noticed that you = compared against the EBACS version of Ed448-Goldilocks.  With a = fixed base point, your method uses 41% less time for the Montgomery = ladder with a 25kiB table.  However, the EBACS version of = Ed448-Goldilocks doesn=E2=80=99t use the Montgomery ladder for = fixed-base scalarmul.  Instead it uses a combs algorithm, which = uses a 15kiB table and takes about 70% less time than the Montgomery = ladder; see https://bench.cr.yp.to/results-dh.html.  Libdecaf = likewise uses precomputed combs for fixed-base scalarmul.  But your = new technique is certainly simpler.

Cheers,
=E2=80=94 = Mike

On May 11, 2017, at 5:14 PM, = Francisco Rodriguez- Henriquez <francisco@cs.cinvestav.mx> wrote:

Dear = CFRG community,

We would like to draw your = attention to an improved version of our IACR pre-print 2017/264 now = entitled:

"How to (pre-)compute a = ladder"

In this revised version, we present = an improved differential addition formula that uses pre-computation to = match the computational cost of the classical Montgomery differential = addition.

Accordingly, our estimates = suggest that a full implementation of our pre-computable ladder proposal = should outperform state-of-the-art software implementations of the = X25519 and X448 functions by a 40% speedup when working in the = fixed-point scenario.

We would be delighted = to receive feedback (including sightings of typos) from the CFRG = community.

With best regards,

Thomaz Oliveira, Julio L=C3=B3pez, H=C3=BCseyin = Hisil and Francisco = Rodr=C3=ADguez-Henr=C3=ADquez_____________________________________________= __
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_B2F77B8F-D792-4AF5-A27B-6FE29D28205E-- --Apple-Mail=_09B506A7-1BBE-4797-A5E2-930E29C1F42E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBTswggQjoAMCAQICEHoG8xWilUOAofL9SgMaeoswDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMjYwMDAwMDBaFw0xODAx MjYyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEm1pa2VAc2hpZnRsZWZ0Lm9yZzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOqqrw9EcWDB6nWwQF8w/33lSrEiXPSbH22lmGGuue8OypB8 /XQ1yZH3/d1sXaLcnjrbO0Fw72W73rKEFBNaGFvtp+BiG91zW2St/Mp5WYIazZMcNs5C0eBA1snw WabMu/eBZFrXdWw5Cy9Or+Mr88RHzttmFjoSHdR5Q5E+6GwgBl3kKujTGUcAipqSi8UTCtZ6qIX/ irxM/JjnJvpEamnynQYW3EKiwPqIddDpPAJY+yyrNEsB037xdvKotYWQuUS+6v0xQA73lpoINThz 7E96+nhf5963oJBIt1YsZMWSUcirY/1+0lPMAorKsd1eyptx/vNIKmwZ9vCX9yNTWm8CAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQK9wxnKZ+9 OrHhpPb8QtuMi0ZrozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIESbWlrZUBzaGlmdGxlZnQub3JnMA0GCSqGSIb3DQEBCwUA A4IBAQBET2Co7GkRwEsnbMblehKCYLs90rtVmXwVfDK03C+9conMJ9Eh4fhKhFRqDOldSvt9ry9V sA1Qlp11t6w8ueo9duGJuV7vhtvOu4s0+FRNs1Dse8wOV917t0tpR+n3pb261krNvcRgUU0Ebv4E wiI22yLZ/bz+BywGy1btReabhSo7cOEkG4P2nI10rrhfZNK81P8vr3thpi+UBsE9+tCrzySYgE4b CIIceEyWp9qtLkZ6q/3yIPmp9aSRfwbdDdvetLiiaeJGV0IFeXMrjkz/7UIWFtZWPO0ZxkH7t/S0 yHEHK0AldsTOtEuVl1wqshwRKg+IfE1VBYZotX/gpHptMYIDwzCCA78CAQEwgbAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQegbzFaKVQ4Ch8v1KAxp6izAJBgUr DgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1 MTIyMTE1MDBaMCMGCSqGSIb3DQEJBDEWBBSqbkIcFN3Nte4LJN6xFOk3PRXjqDCBwQYJKwYBBAGC NxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09N T0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEHoG 8xWilUOAofL9SgMaeoswgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEHoG8xWilUOAofL9SgMaeoswDQYJKoZIhvcNAQEBBQAE ggEAHcnq3C+y6KlCAbAPCUb/EuPv6Muz6EeJ5nwTLVDUcYalTG1Yt1MuADGDEwzWVaukkclgmi78 SlWZHXwBuDsxf23wqfmSEibZFt400dIsUAKT2LOFIh6BZTeCht1Q6S1vNxFGWDAiSQlv5Dijko/P ntES7hRBoXSR9myGG9gMpGRpjVxCXpdmGHmQxp46qnsp1gQG6VHMdl/cQx2RLI9pxgYm1pSimHhu eJbEQeK2f382oLwAl0b7nNGIELEDsE+5wLWGIfCD1oGagNqm+890dkuVQivkrIloQlHdRUeGDsrB E/v3JaqHZVLMFPBYdaFNP/2q/T4G/q6kajtKjFliSQAAAAAAAA== --Apple-Mail=_09B506A7-1BBE-4797-A5E2-930E29C1F42E-- From nobody Mon May 15 04:28: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 B7384129B9E for ; Mon, 15 May 2017 04:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] 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 NABqBogpuLIS for ; Mon, 15 May 2017 04:28:09 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30061.outbound.protection.outlook.com [40.107.3.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357C1129BC7 for ; Mon, 15 May 2017 04:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UikiwsNR7pbFChkBuAdVkwacz7kcTxHzVYou/qjpNUg=; b=gQBHsmVEKqTrbbJSG1gLUAVBeFPhp1GpGthvUGSnzB1gIYWZobJjOzTVz7JFft2FK3kSb3UwqNh3zJfznQRHq971mOcbll2HSMEShDRKFa/hGo5ZybzU5441rfFclzkD0cWvmWLk+z/8gKPpDpeRUluyv1clRl3zJOR614JZClk= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 15 May 2017 11:24:33 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::c9f:2e79:f27a:4855]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::c9f:2e79:f27a:4855%14]) with mapi id 15.01.1084.027; Mon, 15 May 2017 11:24:32 +0000 From: "Paterson, Kenny" To: "Paterson, Kenny" , "cfrg@irtf.org" Thread-Topic: Research Group Last Call: draft-nir-cfrg-rfc7539bis Thread-Index: AQHSvz7oBYW24CQD50KN6G/kOpU85qH1bZwA Date: Mon, 15 May 2017 11:24:32 +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: rhul.ac.uk; dkim=none (message not signed) header.d=none;rhul.ac.uk; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.52.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:13CmRr+tu/6YatPj3XPalWoHQBVb9hexyKzsmUVjFWr+tuH798ez6WPO9fAjibbIoRoJhqttXPpvnwWktwVZOM8U2V0u0T+o49c1caa9WxNZcho/MdgcNsxZdtU9GcnGFWQjPFq+vbMmonwggogTuKDgceup1+D0WVlxn8VcwZfXvZ4Xy6/Ar7VScOnU17kYqsSxTf5XcANj3wyuGWVKlPLIPbg3VLORbzAbGGIuoIw9UG9oTlc1jd1DuUc4tqP/XHUms4xN/Nx/R2NjaHh4JMp2QqA1L+vvVifqpgg64RPP1BUa0E07hlvJydbsFc78y9kQdRpGsN8vI4WasGiaEg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(24454002)(6506006)(6436002)(8936002)(6486002)(4326008)(2906002)(2950100002)(6116002)(42882006)(5660300001)(102836003)(7736002)(68736007)(66066001)(39060400002)(81166006)(3660700001)(3846002)(8676002)(50986999)(3280700002)(305945005)(76176999)(54356999)(86362001)(2900100001)(99286003)(83506001)(74482002)(230783001)(229853002)(54906002)(53546009)(53936002)(2501003)(5250100002)(4001350100001)(189998001)(38730400002)(478600001)(6306002)(6512007)(25786009)(68196006)(36756003)(6246003)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 5d8dd2f5-6a4c-4266-b1c5-08d49b84f590 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1907; x-forefront-prvs: 0308EE423E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 11:24:32.2408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: Re: [Cfrg] Research Group Last Call: draft-nir-cfrg-rfc7539bis 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, 15 May 2017 11:28:12 -0000 RGVhciBBbGwsDQoNClJHTEMgaGFzIGNvbmNsdWRlZC4gV2UgcmVjZWl2ZWQgdHdvIHBvc2l0aXZl IGNvbW1lbnRzICh0aGFua3MgUnVzcyBhbmQNClN0ZXBoZW4pLiBXZSBhbHNvIHJlY2VpdmVkIGRl dGFpbGVkIHJldmlld3MgZnJvbSB0aGUgY3J5cHRvIHBhbmVsIGVhcmxpZXINCmluIHRoZSBwcm9j ZXNzLg0KDQpTbyB3ZSB3aWxsIHByb2NlZWQgd2l0aCBwdWJsaWNhdGlvbi4NCg0KUmVnYXJkcw0K DQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMpLg0KDQpPbiAyNy8wNC8yMDE3IDExOjEzLCAiUGF0ZXJz b24sIEtlbm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQoNCj5EZWFyIENG UkcsDQo+DQo+VGhpcyBtZXNzYWdlIHN0YXJ0cyAyIHdlZWtzIFJHTEMgb24gZHJhZnQtbmlyLWNm cmctcmZjNzUzOWJpcyAoIkNoYUNoYTIwDQo+YW5kIFBvbHkxMzA1IGZvciBJRVRGIFByb3RvY29s cyIpLCB3aGljaCB3aWxsIGVuZCBvbiBUaHVyc2RheSAxMXRoIE1heS4NCj5UaGUgZHJhZnQgaXMg YXZhaWxhYmxlIGhlcmU6DQo+DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbmlyLWNmcmctcmZjNzUzOWJpcy8NCj4NCj4NCj5QbGVhc2UgcHJvdmlkZSB5b3VyIHJldmll dyBjb21tZW50cywgYXMgd2VsbCBhcyBzdGF0ZW1lbnQgb2Ygc3VwcG9ydCAob3INCj5ub3QpIGlu IHJlcGx5IHRvIHRoaXMgbWVzc2FnZSBvciBkaXJlY3RseSB0byBDRlJHIGNoYWlycy4NCj4NCj5U aGFua3MsDQo+DQo+QWxleGV5IGFuZCBLZW5ueQ0KPg0KPg0KDQo= From nobody Mon May 15 04:38: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 3608312E85B; Mon, 15 May 2017 04:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001] 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 kRiNFA7OtSpK; Mon, 15 May 2017 04:38:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20060.outbound.protection.outlook.com [40.107.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE86412E04A; Mon, 15 May 2017 04:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2ZQAbx26CMEZ8Ltz92LcH1iEFgPsff71bnYk20hAJ+E=; b=agNB5UbRZ+77LIi2RzlW2deGRUiI1/cTeNifVuUbuvAMEUsXoILGf1ic3lDOFvxYqeJcnZRbg9K+V0u6QJrTJ+MWccZnIzo7HHyUHlPOVufehRrX71KTQZaTXs9r0VGHCE2qIkS82dOC8ETYjkhTJyksXmfiEd3Fam/Z62uuY7c= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 15 May 2017 11:34:06 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::c9f:2e79:f27a:4855]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::c9f:2e79:f27a:4855%14]) with mapi id 15.01.1084.027; Mon, 15 May 2017 11:34:06 +0000 From: "Paterson, Kenny" To: "irsg@irtf.org" CC: Alexey Melnikov , "draft-nir-cfrg-rfc7539bis.authors@ietf.org" , "cfrg@irtf.org" , "irtf-chair@irtf.org" Thread-Topic: ISRG review: draft-nir-cfrg-rfc7539bis Thread-Index: AQHSzW8o9TX6nISAC0CK/vrpUxNOaw== Date: Mon, 15 May 2017 11:34:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [78.146.52.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:xAOTsonApGc5guFOigxP03uaMHIacB0Cf8UMTVb+q3OBsx5uDq4CmpDPwNtAmN8heLK06ZskIpJ+2mETQE7kqFMlrAz2GTI1iCu/z1872hzWcW6nvEbfpu3biw/0jjHcDD5a46hxp55tkJ0VuuLjCYzumwwyTX+Vmlo1Wzrr+VkhKjgG0tZfHEJdGmVLmv6ylyLYJcRikcaSQCFKwOsvQIgKxeUkkxPTvWeFUbb3IKpklY4gqYx7t8nXKGTiMgwwmvZGVN/n+81OK7lUL0pxjSoBPL8Bo13LY1JKRZy9nRYIVpvZjcuyuBiJ6iIW0I5bvFFcJoQWxVA/y/J15GZdjw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39850400002)(39400400002)(39450400003)(39840400002)(24454002)(2501003)(5250100002)(50986999)(305945005)(3280700002)(7736002)(54356999)(3660700001)(5660300001)(2906002)(74482002)(99286003)(53546009)(6306002)(6512007)(6486002)(6506006)(5640700003)(54906002)(25786009)(6436002)(38730400002)(4326008)(6246003)(230783001)(110136004)(53936002)(478600001)(2351001)(81166006)(102836003)(6116002)(86362001)(3846002)(8676002)(1730700003)(229853002)(8936002)(4001350100001)(2900100001)(72206003)(66066001)(189998001)(36756003)(42882006)(6916009)(83506001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 22af6b6f-ebf0-45e4-d74c-08d49b864b83 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1906; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906; x-forefront-prvs: 0308EE423E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4F6E0BCF79D18C43B2C3E5A86B406E4F@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 11:34:06.0155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: Subject: Re: [Cfrg] ISRG review: draft-nir-cfrg-rfc7539bis 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, 15 May 2017 11:38:41 -0000 RGVhciBJU1JHLA0KDQpUaGUgQ0ZSRyBjaGFpcnMgcmVxdWVzdCBhbiBJU1JHIHJldmlldyBvZiB0 aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KDQpDaGFDaGEyMCBhbmQgUG9seTEzMDUgZm9yIElFVEYg UHJvdG9jb2xzDQpkcmFmdC1uaXItY2ZyZy1yZmM3NTM5YmlzLTAxDQoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbmlyLWNmcmctcmZjNzUzOWJpcy0wMQ0KDQoN ClRoZSBkb2N1bWVudCBoYXMgdW5kZXJnb25lIFJHIHJldmlldywgd2l0aCByZXZpZXdzIGJlaW5n IGNhcnJpZWQgb3V0IGJ5IDINCm1lbWJlcnMgb2YgdGhlIENGUkcgY3J5cHRvIHBhbmVsIGFuZCBv bmUgZnVydGhlciBkZXRhaWxlZCByZXZpZXc6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvY2ZyZy9jdXJyZW50L21zZzA4OTE0Lmh0bWwNCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jZnJnL2N1cnJlbnQvbXNnMDg5MDAuaHRtbA0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NmcmcvY3VycmVudC9tc2cwODg5MS5o dG1sDQoNCg0KVGhhbmtzLA0KDQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQoNCg0KDQpPbiAxNS8w NS8yMDE3IDEyOjI0LCAiUGF0ZXJzb24sIEtlbm55IiA8S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51 az4gd3JvdGU6DQoNCj5EZWFyIEFsbCwNCj4NCj5SR0xDIGhhcyBjb25jbHVkZWQuIFdlIHJlY2Vp dmVkIHR3byBwb3NpdGl2ZSBjb21tZW50cyAodGhhbmtzIFJ1c3MgYW5kDQo+U3RlcGhlbikuIFdl IGFsc28gcmVjZWl2ZWQgZGV0YWlsZWQgcmV2aWV3cyBmcm9tIHRoZSBjcnlwdG8gcGFuZWwgZWFy bGllcg0KPmluIHRoZSBwcm9jZXNzLg0KPg0KPlNvIHdlIHdpbGwgcHJvY2VlZCB3aXRoIHB1Ymxp Y2F0aW9uLg0KPg0KPlJlZ2FyZHMNCj4NCj5LZW5ueSAoZm9yIHRoZSBjaGFpcnMpLg0KPg0KPk9u IDI3LzA0LzIwMTcgMTE6MTMsICJQYXRlcnNvbiwgS2VubnkiIDxLZW5ueS5QYXRlcnNvbkByaHVs LmFjLnVrPiB3cm90ZToNCj4NCj4+RGVhciBDRlJHLA0KPj4NCj4+VGhpcyBtZXNzYWdlIHN0YXJ0 cyAyIHdlZWtzIFJHTEMgb24gZHJhZnQtbmlyLWNmcmctcmZjNzUzOWJpcyAoIkNoYUNoYTIwDQo+ PmFuZCBQb2x5MTMwNSBmb3IgSUVURiBQcm90b2NvbHMiKSwgd2hpY2ggd2lsbCBlbmQgb24gVGh1 cnNkYXkgMTF0aCBNYXkuDQo+PlRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCj4+DQo+Pmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW5pci1jZnJnLXJmYzc1MzliaXMv DQo+Pg0KPj4NCj4+UGxlYXNlIHByb3ZpZGUgeW91ciByZXZpZXcgY29tbWVudHMsIGFzIHdlbGwg YXMgc3RhdGVtZW50IG9mIHN1cHBvcnQgKG9yDQo+Pm5vdCkgaW4gcmVwbHkgdG8gdGhpcyBtZXNz YWdlIG9yIGRpcmVjdGx5IHRvIENGUkcgY2hhaXJzLg0KPj4NCj4+VGhhbmtzLA0KPj4NCj4+QWxl eGV5IGFuZCBLZW5ueQ0KPj4NCg0K From nobody Tue May 16 10:40:15 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4ED129B74 for ; Tue, 16 May 2017 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppvv62jdrmEV for ; Tue, 16 May 2017 10:40:11 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E5312EC16 for ; Tue, 16 May 2017 10:35:35 -0700 (PDT) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2017 13:35:34 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0319.002; Tue, 16 May 2017 13:35:34 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQ== Date: Tue, 16 May 2017 17:35:33 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:40:13 -0000 Hi all, I'm considering writing an I-D on doing ECC over the field of size 8^91+5 (=3D2^273+5), because it: - is written in just 6 symbols (=3Dlow Kolmogorov complexity, heuristically= minimizing threat of NOBUS-trapdoor), - has easy and fast inversion, Legendre symbols, and square roots, - has efficient arithmetic using at most five 64-bit words (use base 2^55), - is at least 2^(256-epsilon), - is (probably) prime, so not an extension field (has no subfields for desc= ent-type attacks on ECDLP). Other fields can improve on some of these properties, but might worsen the = others. For ECC with this field, I am also considering the special curve 2y^2=3Dx^3+x, because it: - is written in just 10 symbols (similar gains to 6-symbol field), - has Montgomery form (and easily converts to Weierstrass), - has efficient endomorphism (so it is a GLV curve), - is similar to curves already suggested by Miller in 1985 (well-aged), - is similar to sect256k1 already used in bitcoin (incentivized), - has an small enough cofactor 72 (over field size 8^91+5), - avoids the main ECDLP attacks: Pohlig-Hellman, Menezes-Okamoto-Vanstone, = etc., - is similar to the special curves of Koblitz-Menezes [ia.cr/2008/390, Sec = 11.1, Example 5] resisting a speculative attack. The motivation for this special curve largely matches the motivation for th= e special field. The curve's risks are at least: - CM (endomorphism) makes it potentially weak (after 32 years of being safe= ) (note exactly opposing Koblitz-Menezes rationale),=20 - its small coefficients are weak for some unpublished reason (continuing t= rend of weak small-coefficients, y^2=3Dx^3 (singular), supersingular, etc. = being weak), - weak twist order (so, it requires a static ECDH Montgomery ladder to use = public key validation),=20 - weak Cheon resistance (but this is an attack with many queries, much comp= utation, and faulty or no KDF). - den Boer or Maurer-Wolf reductions are not tight as possible, so perhaps = it has a big gap between DHP and DLP Other curves (over this field) can reduce these risks, but may also lose so= me of the benefits. Overall, E(GF(8^91+5)):2y^2=3Dx^3+x might offer competitive efficiency with= fairly reasonable security (for 128-bit symmetric keys). It is only an inc= remental change over other standard ECC curves, not anything too radical. = =20 I'd be happy to hear what CFRG thinks, or if the CFRG would welcome such an= I-D as a CFRG work item. I hope to have this topic presented briefly at a= n upcoming CFRG meeting. Best regards, Dan Brown From nobody Tue May 16 21:28:46 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5317F12F547 for ; Tue, 16 May 2017 21:28:45 -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, 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=sbcglobal.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 8vvQAd5Jlm13 for ; Tue, 16 May 2017 21:28:43 -0700 (PDT) Received: from nm18-vm1.access.bullet.mail.gq1.yahoo.com (nm18-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.16]) (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 548A312EBBA for ; Tue, 16 May 2017 21:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1494995129; bh=bEHzVgvpVKXM4oNVZ7A/G8D7oU5aXI5b2LTq8DJ38PY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Q3OKpsulm0tgVuvj1BQViyoo7l59t2LPqRnwKnLdsKCN2chlMSzO4ZY4Fn1WVJxoEnOmmbVzl9YSqLLEsvyIA1UiuUeQX/DRSuXjbXyjgUMG7p7LsmhMqJwKds+Ci8Py4Qg8ENImz+8BxnsEnmxhdi7W9FR5T7Knk3P2+TWjfP/04xX1/ELuZXT5edgEpNlG+BCQAqzbkfxV4Q5mMsKdciuIw8AChxfhtAyxztjNrj+F6zEerrwWQ9CN29IV+f+FDmR4nOYGgSOKwidsSzIb2ANGVZw2HzjG99k9aTXR1CLMb7cvB0WwZviD0u34aA+/yzltKMNDh0sPOc8IaJAQXQ== Received: from [216.39.60.171] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 May 2017 04:25:29 -0000 Received: from [98.138.104.100] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 May 2017 04:25:29 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 17 May 2017 04:25:29 -0000 X-Yahoo-Newman-Id: 810081.19752.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 77rw7hcVM1nOiCxqyj1Lvuh63.Yoehh2jg1TA7t.8eXPUll VEcYLYCHM9IcNjY0RKGWWzFU_hzY2.H2cHskBbuM62q0S2XBbOvSqBXoN1fi lH2RKk2sP4rdyJhvgbjS5AovPmebydp1BJwtEWVQT9rc8RNTTTtljiBeIdkU DX9pXnSs2.9Xk1GKbdvMQNyewMML39NvCah.kqNyKKEwDPmrAp43xiAgdg2S ITVINRk41n4aSJ5StbipgsqxLUOhDP5TytRVl6Xdc7KqS0RmCeUb3mwaiRo9 NqOCye2cJx6Nddat_IuJrnGNTSMVOPNA.ZDrHiD2N77OP09lvfse2LNT1Z6z 0LtoovGaGEQN9vAYpPs.QFD2Yz4v9u2fcj0cXn67YCQtBzAkc..xszLBUhK4 r6th9Q7sIh3n8R.qxBDP7jE6KK9EfoVLYpM.4KyMnILaRB3MYyud5Tmf2yKs 8pWKKLeUEhaFLom5FykNaJpR0zQy3Y8ahMB6nsVpeO18CO4pf8E.URJ3xIXK k6pqnGz3umVHthh407QLebFh5IS1GvuJoqkEJ.9rxlwkzpSqfWEBgU7yg.Wd TlT1WUiw- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- To: Dan Brown , "cfrg@irtf.org" References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> From: David Jacobson Message-ID: <73cec152-916a-a29f-0daa-dba70c43a7ba@sbcglobal.net> Date: Tue, 16 May 2017 21:25:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 04:28:45 -0000 8^91+5 is provably prime. In Mathematica I loaded the PrimalityProving module, and checked whether 8^91+5 was prime, and got True, along with a "Certificate" that is about 2 pages long. I don't know the math of certificates, but if anyone in interested I can post the certificate. --David On 5/16/17 10:35 AM, Dan Brown wrote: > Hi all, > > I'm considering writing an I-D on doing ECC over the field of size > 8^91+5 (=2^273+5), > because it: > - is written in just 6 symbols (=low Kolmogorov complexity, heuristically minimizing threat of NOBUS-trapdoor), > - has easy and fast inversion, Legendre symbols, and square roots, > - has efficient arithmetic using at most five 64-bit words (use base 2^55), > - is at least 2^(256-epsilon), > - is (probably) prime, so not an extension field (has no subfields for descent-type attacks on ECDLP). > Other fields can improve on some of these properties, but might worsen the others. > > For ECC with this field, I am also considering the special curve > 2y^2=x^3+x, > because it: > - is written in just 10 symbols (similar gains to 6-symbol field), > - has Montgomery form (and easily converts to Weierstrass), > - has efficient endomorphism (so it is a GLV curve), > - is similar to curves already suggested by Miller in 1985 (well-aged), > - is similar to sect256k1 already used in bitcoin (incentivized), > - has an small enough cofactor 72 (over field size 8^91+5), > - avoids the main ECDLP attacks: Pohlig-Hellman, Menezes-Okamoto-Vanstone, etc., > - is similar to the special curves of Koblitz-Menezes [ia.cr/2008/390, Sec 11.1, Example 5] resisting a speculative attack. > The motivation for this special curve largely matches the motivation for the special field. > > The curve's risks are at least: > - CM (endomorphism) makes it potentially weak (after 32 years of being safe) (note exactly opposing Koblitz-Menezes rationale), > - its small coefficients are weak for some unpublished reason (continuing trend of weak small-coefficients, y^2=x^3 (singular), supersingular, etc. being weak), > - weak twist order (so, it requires a static ECDH Montgomery ladder to use public key validation), > - weak Cheon resistance (but this is an attack with many queries, much computation, and faulty or no KDF). > - den Boer or Maurer-Wolf reductions are not tight as possible, so perhaps it has a big gap between DHP and DLP > Other curves (over this field) can reduce these risks, but may also lose some of the benefits. > > Overall, E(GF(8^91+5)):2y^2=x^3+x might offer competitive efficiency with fairly reasonable security (for 128-bit symmetric keys). It is only an incremental change over other standard ECC curves, not anything too radical. > > I'd be happy to hear what CFRG thinks, or if the CFRG would welcome such an I-D as a CFRG work item. I hope to have this topic presented briefly at an upcoming CFRG meeting. > > Best regards, > > Dan Brown > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Thu May 18 12:20: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 ADF9C129B64 for ; Thu, 18 May 2017 12:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxSk-JRoVwky for ; Thu, 18 May 2017 12:20:55 -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 C4AA5128DF3 for ; Thu, 18 May 2017 12:14:57 -0700 (PDT) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2017 15:14:56 -0400 Received: from XCT197YKF.rim.net (10.2.25.5) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 18 May 2017 15:14:56 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT197YKF.rim.net ([fe80::459a:3e96:7706:5ba1%12]) with mapi id 14.03.0319.002; Thu, 18 May 2017 15:14:56 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: ECC mod 8^91+5 Thread-Index: AdLNjx77PpyZT1/ZSIWijHcZu9CKCQCeRPzA Date: Thu, 18 May 2017 19:14:55 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B18C25@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B181DA@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] ECC mod 8^91+5 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:20:58 -0000 Clarifying a few things over my previous message: - 8^91+5 has fast modular reduction mainly due its being close to a power o= f 2 (in contrast to 7^98-2). - 8^91+5 is a little further than I first thought from the specifics of Kob= litz-Menezes Example 5, because the conductor seems to have several more pr= ime factors, rather than the single prime in the KM construction - sorry if= I gave the wrong impression. Perhaps portions of the KM example 5 argumen= t might yet apply to 2y^2=3Dx^3+x/GF(8^91+5). - 8^91+5 as a field size might be a little awkward. For ECDH, we take adva= ntage of the endomorphism (x,y)->(-x,iy), to drop a sign bit from x. This = fits x into 34 bytes. This is larger than the usual 128-bit secure ECC cur= ves, which can use 32 bytes, so they require extra data to send and store. = The byte length is not a multiple of 4, let alone power of two, but I am n= ot sure how much trouble that would be. =20 From nobody Tue May 23 08:56: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 6467B127078; Tue, 23 May 2017 08:56:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149555500538.9096.6681134188251904816@ietfa.amsl.com> Date: Tue, 23 May 2017 08:56:45 -0700 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-05.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 15:56:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum of the IETF. Title : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption Authors : Shay Gueron Adam Langley Yehuda Lindell Filename : draft-irtf-cfrg-gcmsiv-05.txt Pages : 28 Date : 2017-05-23 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-05 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-gcmsiv-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 23 09:01: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 6D9DD129BA2 for ; Tue, 23 May 2017 09:01:37 -0700 (PDT) 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, 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 HMW1aRYVn2uR for ; Tue, 23 May 2017 09:01:35 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E827129AEA for ; Tue, 23 May 2017 09:01:35 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k91so100497766ioi.1 for ; Tue, 23 May 2017 09:01:35 -0700 (PDT) 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; bh=MxhytgCW9sVJY/2O2UMHHcXi1JhzXlgZ060o57NhDLQ=; b=Wrw/4c9IhbvmYJCj24yHptI1zp+aUddH8oB+kxmK7xGqyeGWF3ayyF07sFpjTA+4mi fudJ/BeJNS9UvqvfkApeiFrk5FyH0WeHjoDdPxGRNwxsGsOJsmVeOEQx/ep5e1eeWUSb zfiUDnvb7UX16kQhZ5L9MACaP3ZZhs7beVPWdoWXF/TkQ2x88+oGTsEDbG/VN66qX34q sTMOa6QnqIid9u3hXgI51+ub2/oadDhBVar2+GdwTsNo3XhaPgIGmknWc6hDu61nbPHG enznTXschYoWX8PsEAW2/soviQ2FNdf4pZTVc2lRKuWvFPGZ1TzwUpOwyZVp37Dj+p3Y OZtg== 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; bh=MxhytgCW9sVJY/2O2UMHHcXi1JhzXlgZ060o57NhDLQ=; b=PL2eJUN591P6WlwkbI6sBaPtCcNUOH+sXU22p1xtH5CkuQaQ+H3PaUAe3jhKDN7+DP cd7+4XvPRAIeAfjfPMI81rqf9pJ2Jo48B4Op7tGev/AQJ2/Unbt8+fvH6xkzULurC5JZ Xt7i4mXFanSvlTVjCWtv3nR3lzxwCMtLKrjiXLrx+nWofcaxlUfgkeMiBM6n6uaHIB+A 54ODzESycpBZZbaLrbEKv+KSgCFo3BgjjwSX2NIXhg+wBkraTyN3WnuL0rmmfIkllmDF OyCvST+/W5AYGylLI1bECVDpgXzP5ZpXd5iysurccNIdtpJgiOr7PnBf4WiX51kA7tpX aqYg== X-Gm-Message-State: AODbwcCgVlXWjfJX4Rq6AOWHCFKIs/VkSJ3lc76zdndIF3T1MaSB+5qg xJ6Iq+qmlouojvZYYehvMgVZvro2DRmKRDg= X-Received: by 10.107.22.131 with SMTP id 125mr33003428iow.117.1495555294569; Tue, 23 May 2017 09:01:34 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.0.151 with HTTP; Tue, 23 May 2017 09:01:33 -0700 (PDT) In-Reply-To: <149555500538.9096.6681134188251904816@ietfa.amsl.com> References: <149555500538.9096.6681134188251904816@ietfa.amsl.com> From: Adam Langley Date: Tue, 23 May 2017 09:01:33 -0700 X-Google-Sender-Auth: yPvzOH9mYI9LmDiNYUVS4dDaay8 Message-ID: To: cfrg@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05a27c132af10550331a47" Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-05.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:01:37 -0000 --94eb2c05a27c132af10550331a47 Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 8:56 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Crypto Forum of the IETF. > > Title : AES-GCM-SIV: Nonce Misuse-Resistant > Authenticated Encryption > Authors : Shay Gueron > Adam Langley > Yehuda Lindell > Filename : draft-irtf-cfrg-gcmsiv-05.txt > Pages : 28 > Date : 2017-05-23 > Dear CFRG, The updates in this version are minor: some intermediate values in the test vectors were incorrect and have been fixed. Also, a couple of test vectors have been added that test the behaviour of counter wraparound, at the suggestion of Bleichenbacher. We would also like to note that AES-GCM-SIV is now included in BoringSSL and Google is in the process of deploying it for encrypting source-address tokens in QUIC. Cheers AGL --94eb2c05a27c132af10550331a47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 23, 2017 at 8:56 AM, <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Shay= Gueron
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Yehuda Lindell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-irt= f-cfrg-gcmsiv-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 28
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-23

Dear CFRG,

The updates in this version are minor: some intermediate values in= the test vectors were incorrect and have been fixed. Also, a couple of tes= t vectors have been added that test the behaviour of counter wraparound, at= the suggestion of Bleichenbacher.

We would also l= ike to note that AES-GCM-SIV is now included in BoringSSL and Google is in = the process of deploying it for encrypting source-address tokens in QUIC.


Cheers

AGL= =C2=A0
--94eb2c05a27c132af10550331a47--