From nobody Sat Apr 1 07:35:01 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED4F129489 for ; Sat, 1 Apr 2017 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0SArDgm_SB0 for ; Sat, 1 Apr 2017 07:34:57 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id A2DF9128C81 for ; Sat, 1 Apr 2017 07:34:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-223-24-57-67.revip6.asianet.co.th; To: cfrg@irtf.org References: From: Peter Dettman Message-ID: <467245bb-374c-c157-d134-1ca4d1b7057e@bouncycastle.org> Date: Sat, 1 Apr 2017 21:34:42 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [Cfrg] A note on how to (pre-)compute a ladder X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 14:35:00 -0000 Hi Francisco, Some more feedback: - Typo: Alg. 5 line 12 has an X_R1 that should be U_R1. - Typo: the Magma code (Appendix B) refers to "Sec. 6.2 of RFC7748", but the Curve25519 test vectors are from 6.1. - I've now implemented Alg. 5 in my RFC 7748 code (Java). I measure a 16% speedup for Curve25519 ECDH (i.e. 1 fixed + 1 variable) and 19% for Curve448. Only about 100 lines of extra code per curve. - My Curve448 implementation uses unsigned digits; subtraction is slower than addition. The 2 subtractions involving A, B at lines 11-12 of Alg. 5 can be replaced by additions if the u_Pi coordinates are (pre-)negated. Or instead of negating u_Pi, init Z_R1 and Z_R2 to -1, then negate Z_R1 prior to the final doublings (line 16). It gives a little over 1% further speedup here. Regards, Pete Dettman On 30/03/2017 8:00 AM, Francisco Rodriguez- Henriquez wrote: > Dear CFRG community, > > We would like to draw your attention to our IACR pre-print entitled, > > "A note on how to (pre-)compute a ladder > Improving the performance of X25519 and X448" > > https://eprint.iacr.org/2017/264.pdf. > > For the point multiplication computation Q = kP, this note describes a > right-to-left version of the Montgomery ladder, which is amenable for > pre-computing multiples of the base point P. By requiring very modest > memory resources and a small implementation effort, it obtains noticeable > performance improvements with respect to the RFC 7748 classical ladder > procedure. > > We stress that our proposal fully complies with the RFC 7748 > specification, in the sense that given any arbitrary secret keys of > Alice and Bob, our ladder generates exactly the same public keys that an > implementation of the RFC 7748 would output. > > As a way of illustration, in Appendix B of our note, we include a magma > script, which given Alice and Bob private keys of RFC7748 Sec. 6.2, it > computes the same public keys as specified in that document. > > We would be delighted to receive feedback (including sightings of typos) > from the CFRG community. > > With best regards, > > Thomaz Oliveira, Julio L髉ez and Francisco Rodr韌uez-Henr韖uez > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Sat Apr 1 14:58:33 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ED912947B for ; Sat, 1 Apr 2017 14:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Td1UP-xKDDSf for ; Sat, 1 Apr 2017 14:58:30 -0700 (PDT) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A3112947A for ; Sat, 1 Apr 2017 14:58:29 -0700 (PDT) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v31LwJ0H047296 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 1 Apr 2017 21:58:20 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v31LwPTF035931 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 1 Apr 2017 21:58:25 GMT Received: from host80-120-dynamic.49-79-r.retail.telecomitalia.it (host80-120-dynamic.49-79-r.retail.telecomitalia.it [79.49.120.80]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Sat, 01 Apr 2017 23:58:25 +0200 Date: Sat, 01 Apr 2017 23:58:25 +0200 Message-ID: <20170401235825.Horde.MFqM0mpa1h_fZnlpIxtfvd0@webmail.math.unipd.it> From: riccardo.lazzeretti@math.unipd.it To: cfrg@irtf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC--Metrics: server5.math.unipd.it 1480; Body=8 Fuz1=8 Fuz2=8 X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.78 Archived-At: Subject: [Cfrg] [CfP] Workshop on Trusted Computing in Distributed and Hybrid Systems X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 21:58:32 -0000 We apologize if you receive multiple copies of this CFP Workshop on Trusted Computing in Distributed and Hybrid Systems Co-located with the IEEE International Conference on Smart Computing (SMARTCOMP 2017) http://www.wnlabs.com/news/ATC_2017_workshop.php The two fundamental components of Trusted Computing, the asymmetric PKI framework and RSA IFC cryptography, are operating beyond their limitations and are no longer sufficient. "In August, 2015, NSA announced that it planned to transition in the not distant future to a new cipher suite that is resistant to quantum attacks." wikipedia Dynamic distributed key and hybrid systems overcome these limitations. THE TOPICS OF THIS WORKSHOP INCLUDE BUT ARE NOT LIMITED TO THE FOLLOWING 路 distributed frameworks for trusted computing and trusted cyber 路 PKI and distributed combined hybrid frameworks and security controls 路 security, identity and data provenance in distributed and hybrid systems 路 secure handshakes for distributed trusted computing 路 secure cryptographic key distribution and scalability for trusted computing and trusted cyber 路 side channel resistance in trusted computing and trusted cyber 路 next generation cryptography for trusted computing and trusted cyber 路 secure cryptographic key distribution and scalability for trusted computing and trusted cyber 路 trusted computing key creation for restricted resource environments i.e. IoT COMMITTEE 路 Chair: Andre Brisson - Whitenoise Laboratories Canada Inc. 路 Co-Chair: Dr. Mihai Sima - University of Victoria, British Columbia ECE Labs 路 Program Committee Chair: Layton Perrin - Sequor Systems Inc. 路 Program Committee member: Dr. Issa Traore - University of Victoria, British Columbia ECE Labs 路 Program Committee member: Laurie Perrin - Sequor Systems Inc. 路 Program Committee member: Albert Meyburgh - British Columbia Institute of Technology 路 Program Committee member: Edouard Kujawski - MIT, Lawrence Berkeley National Labs 路 Program Committee member: Sam Greenblatt, former CTO HP, Dell SUBMISSION Workshop papers are limited to 6 pages following the IEEE proceedings format, and are to be submitted as PDF via the ATC 2017 submission site: ATC 2017 submission Select CyberTrust track after logging in. Deadlines 路 Paper Submission - April 10, 2017 路 Acceptance Notification - May 10, 2017 路 Camera-Ready Submission - June 10, 2017 From nobody Mon Apr 3 18:11:43 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1021293F4 for ; Mon, 3 Apr 2017 18:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 r9IPkIl0VpL8 for ; Mon, 3 Apr 2017 18:11:39 -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 EA1FB1252BA for ; Mon, 3 Apr 2017 18:11:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id E7E825C206F; Mon, 3 Apr 2017 20:11:23 -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 f7s5x4uBQW5K; Mon, 3 Apr 2017 20:11:22 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id 69CE05C2098; Mon, 3 Apr 2017 20:11:22 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 04EDE5C206F; Mon, 3 Apr 2017 20:11:22 -0500 (CDT) Date: Mon, 3 Apr 2017 20:11:22 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: Peter Dettman cc: cfrg@irtf.org 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-2003453357-1491268282=:14799" Archived-At: Subject: Re: [Cfrg] A note on how to (pre-)compute a ladder 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, 04 Apr 2017 01:11:42 -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-2003453357-1491268282=:14799 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Hi Peter, Thank you very much for your feedback! Please see below for our interlined comments. Cheers, The authors On Fri, 31 Mar 2017, Peter Dettman wrote: > Hi Francisco, > > Seems like a nice performance win for key generation with very little > extra effort over the variable-point ladder in RFC 7748. Thanks! > Would it be worth briefly addressing safe-error attacks? Yes, indeed. A preliminary analysis could go along the following lines. C safe-error attacks: The addition in [Alg. 4, Stp. 8] is not a dummy operation, but it is required for performing further R1 = R0 + R1 additions. Moreover, given that in the X25519 and X448 functions the most significant bit of the scalar k is always set k_(n-1) = 1, the last iteration of [Alg. 4] performs the addition R1 = R0 + R1 (with R2 = R0 - R1). As a result, a computational fault induced at any iteration in [Stp. 8] would produce an incorrect point Q. M safe-error attacks: let M0 and M1 be memory addresses. The "cswap" function guarantees that every iteration of [Alg. 4] performs the operation M0 <- R0 + M0 (with M1 = R0 - M0), where (M0, M1) contains (R1, R2) if k = 1 and (R2, R1) otherwise. Then, the attacker is only able to modify the blocks of M0, which is not sufficient to deduce the bits of the scalar k. Most probably, for hardware implementations other countermeasures should be taken, but they are similar to the ones applied on the classical Montgomery ladder. On the other hand, as pointed out in previous messages in this forum, the "cswap" function does not protect against every side-channel threat. Furthermore, as far as we know, the practical implications of safe-error attacks over the "cswap" function have not been studied yet. > At first glance Algorithm 4 appears to not involve R2 in the final > result, although it's made clear later in Algorithm 5 that both R1 and > R2 are used in every addition due to the choice of addition formula. You are right, the R2 is the difference R0 - R1. > Remark 2 at the end of 5.1 presents this as a minor performance > optimization, but fails to point out that it is needed to protect > against safe-error attacks. Using the improvements suggested by Peter Montgomery in his '87 paper, we have the following formulas: U3 <- Z2*((U1+Z1) + A*(U1-Z1))^2 U3 <- U2*((U1+Z1) - A*(U1-Z1))^2 with A = (U0+Z0) and Z0 = 1/(u-1), U0 = x*Z0. /* all operations pre-computed */ Here, the coordinates of R2 are used too. Consequently, the advantage of the formulas listed in Remark 2 is actually the savings of two field additions. > Regards, > Pete Dettman Thanks for the comments! > On 30/03/2017 8:00 AM, Francisco Rodriguez- Henriquez wrote: >> Dear CFRG community, >> >> We would like to draw your attention to our IACR pre-print entitled, >> >> "A note on how to (pre-)compute a ladder >> Improving the performance of X25519 and X448" >> >> https://eprint.iacr.org/2017/264.pdf. >> >> For the point multiplication computation Q = kP, this note describes a >> right-to-left version of the Montgomery ladder, which is amenable for >> pre-computing multiples of the base point P. By requiring very modest >> memory resources and a small implementation effort, it obtains noticeable >> performance improvements with respect to the RFC 7748 classical ladder >> procedure. >> >> We stress that our proposal fully complies with the RFC 7748 >> specification, in the sense that given any arbitrary secret keys of >> Alice and Bob, our ladder generates exactly the same public keys that an >> implementation of the RFC 7748 would output. >> >> As a way of illustration, in Appendix B of our note, we include a magma >> script, which given Alice and Bob private keys of RFC7748 Sec. 6.2, it >> computes the same public keys as specified in that document. >> >> We would be delighted to receive feedback (including sightings of typos) >> from the CFRG community. >> >> With best regards, >> >> Thomaz Oliveira, Julio L髉ez and Francisco Rodr韌uez-Henr韖uez >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > ---141290138-2003453357-1491268282=:14799-- From nobody Mon Apr 3 18:14:40 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16721274D2 for ; Mon, 3 Apr 2017 18:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 2gnjtOMPcCGY for ; Mon, 3 Apr 2017 18:14:37 -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 DB2E412702E for ; Mon, 3 Apr 2017 18:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id 571735C206F; Mon, 3 Apr 2017 20:14:23 -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 6bNkYDzyKtcr; Mon, 3 Apr 2017 20:14:22 -0500 (CDT) Received: by delta.cs.cinvestav.mx (Postfix, from userid 1507) id EAA155C2087; Mon, 3 Apr 2017 20:14:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by delta.cs.cinvestav.mx (Postfix) with ESMTP id DD76A5C206F; Mon, 3 Apr 2017 20:14:21 -0500 (CDT) Date: Mon, 3 Apr 2017 20:14:21 -0500 (CDT) From: Francisco Rodriguez- Henriquez To: Peter Dettman cc: cfrg@irtf.org In-Reply-To: <467245bb-374c-c157-d134-1ca4d1b7057e@bouncycastle.org> Message-ID: References: <467245bb-374c-c157-d134-1ca4d1b7057e@bouncycastle.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-141290138-908383680-1491268461=:14799" Archived-At: Subject: Re: [Cfrg] A note on how to (pre-)compute a ladder 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, 04 Apr 2017 01:14:39 -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-908383680-1491268461=:14799 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 1 Apr 2017, Peter Dettman wrote: > Hi Francisco, > Some more feedback: > > - Typo: Alg. 5 line 12 has an X_R1 that should be U_R1. > - Typo: the Magma code (Appendix B) refers to "Sec. 6.2 of RFC7748", but > the Curve25519 test vectors are from 6.1. Thanks, corrections done! > - I've now implemented Alg. 5 in my RFC 7748 code (Java). I measure a > 16% speedup for Curve25519 ECDH (i.e. 1 fixed + 1 variable) and 19% for > Curve448. Only about 100 lines of extra code per curve. That is great news!, the improvements are within the range of our estimations :) > - My Curve448 implementation uses unsigned digits; subtraction is slower > than addition. The 2 subtractions involving A, B at lines 11-12 of Alg. > 5 can be replaced by additions if the u_Pi coordinates are > (pre-)negated. Or instead of negating u_Pi, init Z_R1 and Z_R2 to -1, > then negate Z_R1 prior to the final doublings (line 16). It gives a > little over 1% further speedup here. We've checked your suggestion, and indeed your trick looks quite interesting. We think that the best option would be to pre-compute the u coordinates as -uPi, because this would involve no extra programming effort. Thanks again for your feedback. Cheers! The authors > Regards, > Pete Dettman > > On 30/03/2017 8:00 AM, Francisco Rodriguez- Henriquez wrote: >> Dear CFRG community, >> >> We would like to draw your attention to our IACR pre-print entitled, >> >> "A note on how to (pre-)compute a ladder >> Improving the performance of X25519 and X448" >> >> https://eprint.iacr.org/2017/264.pdf. >> >> For the point multiplication computation Q = kP, this note describes a >> right-to-left version of the Montgomery ladder, which is amenable for >> pre-computing multiples of the base point P. By requiring very modest >> memory resources and a small implementation effort, it obtains noticeable >> performance improvements with respect to the RFC 7748 classical ladder >> procedure. >> >> We stress that our proposal fully complies with the RFC 7748 >> specification, in the sense that given any arbitrary secret keys of >> Alice and Bob, our ladder generates exactly the same public keys that an >> implementation of the RFC 7748 would output. >> >> As a way of illustration, in Appendix B of our note, we include a magma >> script, which given Alice and Bob private keys of RFC7748 Sec. 6.2, it >> computes the same public keys as specified in that document. >> >> We would be delighted to receive feedback (including sightings of typos) >> from the CFRG community. >> >> With best regards, >> >> Thomaz Oliveira, Julio L髉ez and Francisco Rodr韌uez-Henr韖uez >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > ---141290138-908383680-1491268461=:14799-- From nobody Tue Apr 4 02:41:09 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FD1128792 for ; Tue, 4 Apr 2017 02:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEbxS-oY2U23 for ; Tue, 4 Apr 2017 02:40:52 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D499E12955B for ; Tue, 4 Apr 2017 02:40:44 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id i124so51758051ybc.3 for ; Tue, 04 Apr 2017 02:40:44 -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=q8v1w5YzoIR/3vLF3fvmxQ6wJVsHxYrp6j8PDc8JTDA=; b=phSU1iqeJAycojAP5NTl8cwML9kcMszuYF8mvT2kxxYkBroDlS/a/Y1nP4OYMCrNCp SPPZK8n7pY33WNxJg32Xa+Lk5jhpZAt2YtOo39b6SYvhgH8ZVSJnt5amrFTplWYU7DvD Ew8i0HU4mFBw2Jo6SdS5Vz/6hvQx07DxbEG2gUs/Urxwh7DDQGjzj1ogL1EXv+Bn6bB9 hcUfKeSXfLQPcfz2HiihzBLznNER2fC7DKXv8jr3ERWbYoIIOFcdF2KXPvKbZfrFnT14 dF/kKw/k7+mOk1+VlKOCLYAArk9hxlRLBtm5Z9VNG3w+09OdR+MTTEVJFDnURFRIakPy opYQ== 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=q8v1w5YzoIR/3vLF3fvmxQ6wJVsHxYrp6j8PDc8JTDA=; b=HR6UeIGDmQNZis+WDrWxa1b3RA54YORBhuIytLTo/eReZdM5HT95YGhaMMi4weNY23 ja1l26PccWSchgeN4w7VCOFZgi4392BMSg5BqTqhKgoqxx19EK3heKVnK2IQf0S64qd5 uiu7+FUQLbwIlBwhLlylxjVfBLK8ey0jswh9wiO/34+cdq2BEFi5rP/YPbI2EoYSN4pV Bl1yrZQpsgMdq587nYX8u6QAwxKUGJptzHVQiQ375MSMZGHv5WdpeO6k/UFRQxaDJ+t/ giinxUVs41McEXdWVKKej3ynbPel3gArQvG3901ohtggXIt8HZghS0DZ6ENLYrLxWBv3 fJ8A== X-Gm-Message-State: AFeK/H00unxZdd22+EAzSLk1utYrs4np63ZoEV8mV8hc6uH1PCZ33jcbhiFSZ8uQ3H2nNfgk8hJ7k9rtH/VWSg== X-Received: by 10.37.80.208 with SMTP id e199mr12726869ybb.165.1491298843959; Tue, 04 Apr 2017 02:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.67.5 with HTTP; Tue, 4 Apr 2017 02:40:28 -0700 (PDT) In-Reply-To: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> References: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> From: Dmitry Khovratovich Date: Tue, 4 Apr 2017 11:40:28 +0200 Message-ID: To: Oleg Andreev Cc: cfrg@irtf.org Content-Type: multipart/alternative; boundary=001a113ea146d92ba0054c54113a Archived-At: Subject: Re: [Cfrg] Questions regarding BIP32-Ed25519 (was: Interest in an "Ed25519-HD" standard?) 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, 04 Apr 2017 09:41:00 -0000 --001a113ea146d92ba0054c54113a Content-Type: text/plain; charset=UTF-8 Hi Oleg, thank you for the questions! On Fri, Mar 31, 2017 at 8:06 PM, Oleg Andreev wrote: > Dmitry, > > Thanks for your with Jason paper on adopting BIP32 to Ed25519 and critique > of ChainKD, very appreciated. I have a few questions about it: > > 1. Why do you impose requirements on the master secret to yield 3rd high > bit to be zero, while you can simply set it to zero along with other 5 > bits. In two places you mention that you reject non-compliant master > secret, but in Security section (F) you say "we set 6 bits", which is what > seems to be the intention all along. > Our idea was to reject as few master secrets as possible, so we decided to clear only one extra bit, thus rejecting half of master keys. By setting 6 bits I mean that we set three highest and three lowest bits. > > 2. You choose 2^20 as a max depth level therefore leaving 2^230 bits for > the derived key. In your paper you round this down to whole number of bytes > (28 bytes -> 2^224) while it's actually possible to slightly increase > collision-resistance by taking 29 bytes instead and clearing top 2 bits. > Have you considered that, and if yes, is there any issues with that? > Apart from clearing one more bit, the idea to take 28 bytes instead of 29 is to cut a 32-bit word, which could simplify some implementations. I agree it is a minor issue. > > 3. What was the rationale for 2^20 as a depth limit? I myself don't have a > good framework to decide which limit is the best, so I'm wondering if you > have? :) > The use cases we have seen did not require hierarchy deeper than a few dozen levels. I think 2^20 is a safe bound as long as every new level has some real-world meaning (extra wallet, extra connection, etc.), and thus it seems unlikely that this set will be ever exhausted by any user. > > 4. You effectively make xprv to be 96-byte string (32 bytes for the > scalar, 32 bytes for the "prefix" used in nonce generation and 32 byte > chain code), and use two HMAC calls to derive new chain code separately > from the privkey. Have you considered expanding the 64-byte privkey (as > defined by NaCl library) from the scalar itself? In my recent tweak to > ChainKD scheme [1] I'm doing that and to stay fully compatible with EdDSA > requirement that prefix originally has 256 bits of entropy, add only one > secret byte ("pepper") that eats 8 bits from the chain code (which we call > "salt"). This allows us to keep both xprv and xpub 64 bytes long and avoid > double-HMAC when deriving public keys - single hash call produces a key > component and another salt value. > We just tried to mimic the original BIP32 key derivation as much as possible. I am not sure I entirely understands the rationale behind your manipulation with bytes of private key after you add up the hash output. Also, could you elaborate on the notions of EdDSA public and private keys, which seem to complement public and private keys you derive in the scheme? Best regards, Dmitry > > Thank you! > > [1] Updated ChainKD: https://github.com/chain/chain/blob/chainkd-dh/docs/ > protocol/specifications/chainkd.md > > > > > Being a co-author of [5], I am ready to contribute to such a document. I > > will present our own proposal at > > http://prosecco.gforge.inria.fr/ieee-blockchain2016/ in Paris just > before > > the CFRG meeting at the same place next day. It would be great if we come > > up with some proposal to discuss it already there. > > > > The most recent version is > > https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA It has > some > > critique of [6], hopefully not too offensive:) > > > > Our motivation in [5] was to generate private keys satisfying the > > Curve25519 requirements too so that the code can be reused, even if in > the > > signature setting some attacks would not apply. But it would be great to > > have comments from the community as well. > > > > Best regards, > > Dmitry > > > > On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker < > phill@hallambaker.com > > > wrote: > > > > > You can do hierarchical key derivation in Montgomery without the need > for > > > an add. > > > > > > Say your master key is x. To generate a key for site 'example.com' we > > > take > > > > > > xs = (x + H('example.com')) mod q > > > > > > Where q is the sub group order. > > > > > > In fact that isn't really using any EC relevant operation at all. > Perhaps > > > I am not understanding the full requirements for the scheme. > > > > > > > > > I don't follow the argument about small subgroups in the referenced > post. > > > With Curve25519 and Ed25519 we have chosen the curve cofactor and the > > > generator point. So there is only one group that our point can > possibly be > > > in regardless of whether our private key is (x mod q) or (x mod q + > nq). We > > > are going to arrive at the same set of points regardless. > > > > > > > > > I do very much prefer the Edwards curves though because we can combine > two > > > keypairs by simply adding the corresponding public and private keys. > That > > > allows us to do the co-generation trick I showed a while back. > > > > > > We can also split the key, give one part to a recryption service and > > > encrypt the other half under the public key of the recipient. This > allows > > > us to support group messaging through proxy re-encryption. > > > > > > Some applications of that are encumbered (possibly) under a soon to > expire > > > patent. > > > > > > > > > > > > On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker < > > > phill@hallambaker.com> wrote: > > > > > >> I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. > I > > >> think EdCurve Crypto is a good plan. > > >> > > >> Or we could do it on the Montgomery Curves and give the algorithm for > > >> point addition. > > >> > > >> On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri > wrote: > > >> > > >>> Hierarchical key derivation (also sometimes described as "semiprivate > > >>> keys" or "key blinding") is an increasingly popular technique for > > >>> generating unlinkable child keys from master public and private keys. > > >>> > > >>> The Tor Project has been exploring such an approach as the basis for > > >>> their next-generation hidden services design for several years > now[1], > > >>> during which time it has received security proofs[2]. Their latest > > >>> design[3] allegedly includes feedback from Dan Bernstein. > > >>> > > >>> Application of hierarchical key derivation is perhaps most notable in > > >>> the cryptocurrency space, where Bitcoin's BIP32[4] provided a means > for > > >>> unlinkable single-use signature keys for the secp256k1 elliptic > curve. > > >>> There are several designs for applying the ideas from BIP32 to > Ed25519, > > >>> including ones from Evernym[5] and Chain[6] (where I am an employee). > > >>> > > >>> The designs in [3], [5], and [6] are all highly similar and > accomplish > > >>> the same goals. Personally I would love to see a single standard > design for > > >>> producing Ed25519 signatures from hierarchically derived keys, > notably one > > >>> which produces signatures that can be verified by any off-the-shelf > RFC > > >>> 8032-compatible Ed25519 implementation. > > >>> > > >>> There's already been some discussion of this on the moderncrypto.org > > >>> curves list: > > >>> > > >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html > > >>> > > >>> I'd be curious to know if anyone else would be interested in > > >>> collaborating on a draft for such a standard, which can be a > synthesis of > > >>> the existing work in this space. > > >>> > > >>> [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep > > >>> tember/004026.html > > >>> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf > > >>> [3]: https://gitweb.torproject.org/torspec.git/tree/proposal > > >>> s/224-rend-spec-ng.txt#n1979 > > >>> [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > > >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- > > >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey > > >>> s-Ed25519.pdf > > >>> [6]: https://chain.com/docs/protocol/specifications/chainkd > > >>> > > >>> -- > > >>> Tony Arcieri > > >>> > > >>> _______________________________________________ > > >>> Cfrg mailing list > > >>> Cfrg@irtf.org > > >>> https://www.irtf.org/mailman/listinfo/cfrg > > >>> > > >>> > > >> > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@irtf.org > > > https://www.irtf.org/mailman/listinfo/cfrg > > > > > > > > > > > > -- > > Best regards, > > Dmitry Khovratovich > -- Best regards, Dmitry Khovratovich --001a113ea146d92ba0054c54113a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Oleg,

thank you for the questions!

On Fri, Mar 3= 1, 2017 at 8:06 PM, Oleg Andreev <oleganza@gmail.com> wrote= :
Dmitry,

Thanks for your with Jason paper on adopting BIP32 to Ed25519 and critique = of ChainKD, very appreciated. I have a few questions about it:

1. Why do you impose requirements on the master secret to yield 3rd high bi= t to be zero, while you can simply set it to zero along with other 5 bits. = In two places you mention that you reject non-compliant master secret, but = in Security section (F) you say "we set 6 bits", which is what se= ems to be the intention all along.

Our = idea was to reject as few master secrets as possible, so we decided to clea= r only one extra bit, thus rejecting half of master keys. By setting 6 bits= I mean that we set three highest and three lowest bits.
=C2=A0

2. You choose 2^20 as a max depth level therefore leaving 2^230 bits for th= e derived key. In your paper you round this down to whole number of bytes (= 28 bytes -> 2^224) while it's actually possible to slightly increase= collision-resistance by taking 29 bytes instead and clearing top 2 bits. H= ave you considered that, and if yes, is there any issues with that?

Apart from clearing one more bit, the idea to = take 28 bytes instead of 29 is to cut a 32-bit word, which could simplify s= ome implementations. I agree it is a minor issue.
=C2=A0

3. What was the rationale for 2^20 as a depth limit? I myself don't hav= e a good framework to decide which limit is the best, so I'm wondering = if you have? :)

The use cases we have s= een did not require hierarchy deeper than a few dozen levels. I think 2^20 = is a safe bound as long as every new level has some real-world meaning (ext= ra wallet, extra connection, etc.), and thus it seems unlikely that this se= t will be ever exhausted by any user.
=C2=A0

4. You effectively make xprv to be 96-byte string (32 bytes for the scalar,= 32 bytes for the "prefix" used in nonce generation and 32 byte c= hain code), and use two HMAC calls to derive new chain code separately from= the privkey. Have you considered expanding the 64-byte privkey (as defined= by NaCl library) from the scalar itself? In my recent tweak to ChainKD sch= eme [1] I'm doing that and to stay fully compatible with EdDSA requirem= ent that prefix originally has 256 bits of entropy, add only one secret byt= e ("pepper") that eats 8 bits from the chain code (which we call = "salt"). This allows us to keep both xprv and xpub 64 bytes long = and avoid double-HMAC when deriving public keys - single hash call produces= a key component and another salt value.

We just tried to mimic the original BIP32 key derivation as much as possi= ble. I am not sure I entirely understands the rationale behind your manipul= ation with bytes of private key after you add up the hash output. Also, cou= ld you elaborate on the notions of EdDSA public and private keys, which see= m to complement public and private keys you derive in the scheme?

Best regards,
Dmitry

=C2= =A0

Thank you!

[1] Updated ChainKD: https://github.com/chain/chain/blob/chainkd-dh/docs/protoc= ol/specifications/chainkd.md



> Being a co-author of [5], I am ready to contribute to such a document.= I
> will present our own proposal at
> http://prosecco.gforge.inria.fr/ieee= -blockchain2016/ in Paris=C2=A0 just before
> the CFRG meeting at the same place next day. It would be great if we c= ome
> up with some proposal to discuss it already there.
>
> The most recent version is
> https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA It has some
> critique of [6], hopefully not too offensive:)
>
> Our motivation in [5] was to generate private keys satisfying the
> Curve25519 requirements too so that the code can be reused, even if in= the
> signature setting some attacks would not apply. But it would be great = to
> have comments from the community as well.
>
> Best regards,
> Dmitry
>
> On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker <phill@hallambaker.com
> > wrote:
>
> > You can do hierarchical key derivation in Montgomery without the = need for
> > an add.
> >
> > Say your master key is x. To generate a key for site 'example.com' we
> > take
> >
> > xs =3D (x + H('example.com')) mod q
> >
> > Where q is the sub group order.
> >
> > In fact that isn't really using any EC relevant operation at = all. Perhaps
> > I am not understanding the full requirements for the scheme.
> >
> >
> > I don't follow the argument about small subgroups in the refe= renced post.
> > With Curve25519 and Ed25519 we have chosen the curve cofactor and= the
> > generator point. So there is only one group that our point can po= ssibly be
> > in regardless of whether our private key is (x mod q) or (x mod q= + nq). We
> > are going to arrive at the same set of points regardless.
> >
> >
> > I do very much prefer the Edwards curves though because we can co= mbine two
> > keypairs by simply adding the corresponding public and private ke= ys. That
> > allows us to do the co-generation trick I showed a while back. > >
> > We can also split the key, give one part to a recryption service = and
> > encrypt the other half under the public key of the recipient. Thi= s allows
> > us to support group messaging through proxy re-encryption.
> >
> > Some applications of that are encumbered (possibly) under a soon = to expire
> > patent.
> >
> >
> >
> > On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker <
> > phill@hallambaker.com> wrote:
> >
> >> I have just implemented Proxy Re-Encryption under Ed-25519 an= d Ed448. I
> >> think EdCurve Crypto is a good plan.
> >>
> >> Or we could do it on the Montgomery Curves and give the algor= ithm for
> >> point addition.
> >>
> >> On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri <bascule@gmail.com> wrote:
> >>
> >>> Hierarchical key derivation (also sometimes described as = "semiprivate
> >>> keys" or "key blinding") is an increasingl= y popular technique for
> >>> generating unlinkable child keys from master public and p= rivate keys.
> >>>
> >>> The Tor Project has been exploring such an approach as th= e basis for
> >>> their next-generation hidden services design for several = years now[1],
> >>> during which time it has received security proofs[2]. The= ir latest
> >>> design[3] allegedly includes feedback from Dan Bernstein.=
> >>>
> >>> Application of hierarchical key derivation is perhaps mos= t notable in
> >>> the cryptocurrency space, where Bitcoin's BIP32[4] pr= ovided a means for
> >>> unlinkable single-use signature keys for the secp256k1 el= liptic curve.
> >>> There are several designs for applying the ideas from BIP= 32 to Ed25519,
> >>> including ones from Evernym[5] and Chain[6] (where I am a= n employee).
> >>>
> >>> The designs in [3], [5], and [6] are all highly similar a= nd accomplish
> >>> the same goals. Personally I would love to see a single s= tandard design for
> >>> producing Ed25519 signatures from hierarchically derived = keys, notably one
> >>> which produces signatures that can be verified by any off= -the-shelf RFC
> >>> 8032-compatible Ed25519 implementation.
> >>>
> >>> There's already been some discussion of this on the <= a href=3D"http://moderncrypto.org" rel=3D"noreferrer" target=3D"_blank">mod= erncrypto.org
> >>> curves list:
> >>>
> >>> https://moderncrypto.= org/mail-archive/curves/2017/000858.html
> >>>
> >>> I'd be curious to know if anyone else would be intere= sted in
> >>> collaborating on a draft for such a standard, which can b= e a synthesis of
> >>> the existing work in this space.
> >>>
> >>> [1]: https://lists.torproje= ct.org/pipermail/tor-dev/2012-Sep
> >>> tember/004026.html
> >>> [2]: https://www-users.cs.umn.= edu/~hopper/basic-proof.pdf
> >>> [3]: https://gitweb.torproj= ect.org/torspec.git/tree/proposal
> >>> s/224-rend-spec-ng.txt#n1979
> >>> [4]: https://github.= com/bitcoin/bips/blob/master/bip-0032.mediawiki
> >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of-
> >>> trust-fall2016/blob/master/topics-and-advance-readin= gs/HDKey
> >>> s-Ed25519.pdf
> >>> [6]: https://chain.com/docs/= protocol/specifications/chainkd
> >>>
> >>> --
> >>> Tony Arcieri
> >>>
> >>> _______________________________________________
> >>> Cfrg mailing list
> >>> Cfrg@irtf.org
> >>> https://www.irtf.org/mailman/listin= fo/cfrg
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg<= /a>
> >
> >
>
>
> --
> Best regards,
> Dmitry Khovratovich



--
Be= st regards,
Dmitry Khovratovich
--001a113ea146d92ba0054c54113a-- From nobody Tue Apr 4 17:24: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 578FC129453 for ; Tue, 4 Apr 2017 17:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGrTxFGhOnTs for ; Tue, 4 Apr 2017 17:24:35 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7C5124D6C for ; Tue, 4 Apr 2017 17:24:35 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id s16so25657470pfs.0 for ; Tue, 04 Apr 2017 17:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZVcbDrl0K4G/D9hopYDgB4mRpWLQWCdHjl5FMb4dGXQ=; b=Id7oVOQvaVA1oXsdYKddWJTi/4zae26dJyAqkoLSFMUhVfULOmR47EWgXwVc+TLZCN eJ+m5sRX7hiAmlNPt9PR790ETdYMPMf85wuwC/UFWBgas/QwNh4jO+anJtFWxBPDAktJ k4iNcwWd2FAS33n1PcyhTtUdNQSXV8iBD+ZijAHG+PT4eVsVOPBYZIRIifEg2iX6+2mp UZ9gqhRuYmUQbAotVjhejOELwOLFBb5wEzrw5YAEfpMCDSekfYQl1E+2qJrm65mfPCBo BVfFxnWitESHiUlmAUz76MlI25dPM6rjR1PUbB8f2dwdOH2chUidMkgL1ndlHi3C3+sE gaWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZVcbDrl0K4G/D9hopYDgB4mRpWLQWCdHjl5FMb4dGXQ=; b=DpyVB5Umu+7SGLfqeKiWtQxPvcHMDiJ9WE12bAcm5y0dTwrDLuINDFUNdQdt/TtRED /6FJJLL6Nsun4Dll2GITfqN/ccnO/oeLBH9R0UBdu0acmB/cfhJP8EfhosZCcSM0BGXe j3pa2wCYDlKhmDgfEqeqjx1Pleq8NWw4z8ycfi+lBpKPrk8h9bfmM7Xgqv+Au+fUatZn e7KHcvDqd1gzGSqxkSs6QsLfRC6EnCIdFR7e56+ScSMTNnZn7UcxACRjZkWxBzNgw1Yx sFETVfDN9vzQ24IhiP82Foeq5+4A5SsHPtBNRzyxr37KVQkq6KWL9EquiQI63urWbmz3 qQIg== X-Gm-Message-State: AFeK/H2aMiu05lSZPrF9oIvqq1WfO9KwEcvq0l+5yPQw3CGJ92LUma8J1/uUAoqF3pNI9g== X-Received: by 10.98.58.7 with SMTP id h7mr12965752pfa.27.1491351875199; Tue, 04 Apr 2017 17:24:35 -0700 (PDT) Received: from [192.168.1.126] ([52.119.113.96]) by smtp.gmail.com with ESMTPSA id t66sm33736552pfk.53.2017.04.04.17.24.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 17:24:34 -0700 (PDT) From: Oleg Andreev Message-Id: <3544CA01-C73D-462D-A046-C2800D02756C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDD7CD70-E5BC-4EAA-91B7-57C0D2EEC161" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 4 Apr 2017 17:24:32 -0700 In-Reply-To: Cc: cfrg@irtf.org To: Dmitry Khovratovich References: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Questions regarding BIP32-Ed25519 (was: Interest in an "Ed25519-HD" standard?) 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, 05 Apr 2017 00:24:38 -0000 --Apple-Mail=_FDD7CD70-E5BC-4EAA-91B7-57C0D2EEC161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the detailed reply. > 1. Why do you impose requirements on the master secret to yield 3rd = high bit to be zero, while you can simply set it to zero along with = other 5 bits. In two places you mention that you reject non-compliant = master secret, but in Security section (F) you say "we set 6 bits", = which is what seems to be the intention all along. >=20 > Our idea was to reject as few master secrets as possible, so we = decided to clear only one extra bit, thus rejecting half of master keys. = By setting 6 bits I mean that we set three highest and three lowest = bits. I probably did not phrase my question clearly in the first place. I = meant, why don't you reject _none_ of the master secrets by simply = setting 6 bits as required? If the third highest bit happen to be not = zero, instead of rejecting the master secret, simply set it to zero? = What'd be wrong with that? > 2. You choose 2^20 as a max depth level therefore leaving 2^230 bits = for the derived key. In your paper you round this down to whole number = of bytes (28 bytes -> 2^224) while it's actually possible to slightly = increase collision-resistance by taking 29 bytes instead and clearing = top 2 bits. Have you considered that, and if yes, is there any issues = with that? >=20 > Apart from clearing one more bit, the idea to take 28 bytes instead of = 29 is to cut a 32-bit word, which could simplify some implementations. I = agree it is a minor issue. Oh, it's 32-bit aligned then, I see. Thanks! > =20 > 3. What was the rationale for 2^20 as a depth limit? I myself don't = have a good framework to decide which limit is the best, so I'm = wondering if you have? :) >=20 > The use cases we have seen did not require hierarchy deeper than a few = dozen levels. I think 2^20 is a safe bound as long as every new level = has some real-world meaning (extra wallet, extra connection, etc.), and = thus it seems unlikely that this set will be ever exhausted by any user. I thought along the same lines, but I can imagine an immense scope for = bikeshedding around that number (unfortunately). The 2^20 depth seems = fine by me, but there are over 9000 opinions waiting to enter that = territory and I'd love to figure out a good story defending any = particular decision to avoid wasting a lot of time on it :-)=20 > 4. You effectively make xprv to be 96-byte string (32 bytes for the = scalar, 32 bytes for the "prefix" used in nonce generation and 32 byte = chain code), and use two HMAC calls to derive new chain code separately = from the privkey. Have you considered expanding the 64-byte privkey (as = defined by NaCl library) from the scalar itself? In my recent tweak to = ChainKD scheme [1] I'm doing that and to stay fully compatible with = EdDSA requirement that prefix originally has 256 bits of entropy, add = only one secret byte ("pepper") that eats 8 bits from the chain code = (which we call "salt"). This allows us to keep both xprv and xpub 64 = bytes long and avoid double-HMAC when deriving public keys - single hash = call produces a key component and another salt value. >=20 > We just tried to mimic the original BIP32 key derivation as much as = possible. I am not sure I entirely understands the rationale behind your = manipulation with bytes of private key after you add up the hash output. = Also, could you elaborate on the notions of EdDSA public and private = keys, which seem to complement public and private keys you derive in the = scheme? The main problem I see is that extended private key in BIP32-Ed25519 = paper becomes pretty long - 96 bytes (also not symmetrical with xpub = which is 64-byte). It has 32 bytes for the scalar, 32 bytes for the = secret "prefix" (from where the nonce is derived) and 32 bytes for the = chain code. In EdDSA both the scalar and the "prefix" are derived from a = 256-bit secret, so my suggestion is to derive the "prefix" from the = scalar, but since the scalar only has 250 bits of entropy, we can throw = in extra 6 bits by using a "pepper" byte to be 100% safe :-) In other = words, the full 64-byte "private key" as expected by NaCl has shape: = so we do not explode the size of xprv = to carry additional 32 bytes. =20 I justify that decision by RFC6979 behavior which is effectively doing = the same: the source of entropy for the nonce is the signing key = (32-byte), not the 32-byte key + some additional secret 32 bytes of = entropy. In EdDSA it's the same - both are derived from a master 32-byte = buffer (which, of course, we cannot use because of need for linear = non-hardened derivation). I'm curious is there a concern regarding such = space optimization? --Apple-Mail=_FDD7CD70-E5BC-4EAA-91B7-57C0D2EEC161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for the detailed reply.

1. Why do you impose = requirements on the master secret to yield 3rd high bit to be zero, = while you can simply set it to zero along with other 5 bits. In two = places you mention that you reject non-compliant master secret, but in = Security section (F) you say "we set 6 bits", which is what seems to be = the intention all along.

Our idea was to reject as few master = secrets as possible, so we decided to clear only one extra bit, thus = rejecting half of master keys. By setting 6 bits I mean that we set = three highest and three lowest = bits.

I probably did not phrase my question clearly in = the first place. I meant, why don't you reject _none_ of the master = secrets by simply setting 6 bits as required? If the third highest bit = happen to be not zero, instead of rejecting the master secret, simply = set it to zero? What'd be wrong with that?

2. You = choose 2^20 as a max depth level therefore leaving 2^230 bits for the = derived key. In your paper you round this down to whole number of bytes = (28 bytes -> 2^224) while it's actually possible to slightly increase = collision-resistance by taking 29 bytes instead and clearing top 2 bits. = Have you considered that, and if yes, is there any issues with that?

Apart from clearing one more bit, the idea to take 28 bytes = instead of 29 is to cut a 32-bit word, which could simplify some = implementations. I agree it is a minor = issue.

Oh, it's 32-bit aligned then, I see. = Thanks!

 
3. What = was the rationale for 2^20 as a depth limit? I myself don't have a good = framework to decide which limit is the best, so I'm wondering if you = have? :)

The use cases we have seen did not = require hierarchy deeper than a few dozen levels. I think 2^20 is a safe = bound as long as every new level has some real-world meaning (extra = wallet, extra connection, etc.), and thus it seems unlikely that this = set will be ever exhausted by any = user.

I thought along the same lines, but I can imagine = an immense scope for bikeshedding around that number (unfortunately). = The 2^20 depth seems fine by me, but there are over 9000 opinions = waiting to enter that territory and I'd love to figure out a good story = defending any particular decision to avoid wasting a lot of time on it = :-) 


4. You = effectively make xprv to be 96-byte string (32 bytes for the scalar, 32 = bytes for the "prefix" used in nonce generation and 32 byte chain code), = and use two HMAC calls to derive new chain code separately from the = privkey. Have you considered expanding the 64-byte privkey (as defined = by NaCl library) from the scalar itself? In my recent tweak to ChainKD = scheme [1] I'm doing that and to stay fully compatible with EdDSA = requirement that prefix originally has 256 bits of entropy, add only one = secret byte ("pepper") that eats 8 bits from the chain code (which we = call "salt"). This allows us to keep both xprv and xpub 64 bytes long = and avoid double-HMAC when deriving public keys - single hash call = produces a key component and another salt value.

We just tried to mimic the original BIP32 key derivation as = much as possible. I am not sure I entirely understands the rationale = behind your manipulation with bytes of private key after you add up the = hash output. Also, could you elaborate on the notions of EdDSA public = and private keys, which seem to complement public and private keys you = derive in the scheme?

The main problem I see is that extended private = key in BIP32-Ed25519 paper becomes pretty long - 96 bytes (also not = symmetrical with xpub which is 64-byte). It has 32 bytes for the scalar, = 32 bytes for the secret "prefix" (from where the nonce is derived) and = 32 bytes for the chain code. In EdDSA both the scalar and the "prefix" = are derived from a 256-bit secret, so my suggestion is to derive the = "prefix" from the scalar, but since the scalar only has 250 bits of = entropy, we can throw in extra 6 bits by using a "pepper" byte to be = 100% safe :-) In other words, the full 64-byte "private key" as expected = by NaCl has shape: <scalar><Hash(scalar || pepper)> so we do = not explode the size of xprv to carry additional 32 = bytes.
 
I justify that decision by RFC6979 = behavior which is effectively doing the same: the source of entropy for = the nonce is the signing key (32-byte), not the 32-byte key + some = additional secret 32 bytes of entropy. In EdDSA it's the same - both are = derived from a master 32-byte buffer (which, of course, we cannot use = because of need for linear non-hardened derivation). I'm curious is = there a concern regarding such space optimization?

= --Apple-Mail=_FDD7CD70-E5BC-4EAA-91B7-57C0D2EEC161-- From nobody Wed Apr 5 12:39:12 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D8712948B for ; Wed, 5 Apr 2017 12:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, 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 RQg_7MHHVXl1 for ; Wed, 5 Apr 2017 12:39:08 -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 42B9D1242F5 for ; Wed, 5 Apr 2017 12:39:08 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2017 15:39:06 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Apr 2017 15:39:06 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Wed, 5 Apr 2017 15:39:05 -0400 From: Dan Brown To: "cfrg@irtf.org" Thread-Topic: Prime 630*(427!+1)+1 for classic DH? Thread-Index: AdKuRDlyn/lIDT1CSziTnc33dxF2iA== Date: Wed, 5 Apr 2017 19:39:04 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@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.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 05 Apr 2017 19:39:11 -0000 Hi All, Is the prime p=3D630*(427!+1)+1 vulnerable to the SNFS, or some variant of = SNFS? I think not, but I could easily be very wrong. If not, then the prime p=3D630*(427!+1)+1 seems to have some potential adva= ntages (listed below) for use in finite field (classic) Diffie-Hellman key = agreement. I am not sure of these, so please let me know if you agree or n= ot. 1. Its given expression uses 14 just characters, with standard math notatio= n, so it has a relatively compact representation, ensuring (arguably) it wa= s NOT the result of an exhaustive search of random primes for some obscure = weaknesses (as in Gordon's attack), since presumably such a search would re= sult in a more complicated expression. 2. Its given expression is not just a simple polynomial evaluation, due to = the factorial, thereby avoiding a known class of primes to which SNFS is kn= own to apply. (Most expressions (that I can think of) for large DH primes = that use fewer than 14 characters, such as Mersenne primes, are already kno= wn to be relatively weak under the SNFS, as I understand it.) 3. It seems (heuristically) that, in general, factorials (see *) are not ea= sily expressed as polynomials, which weakly and conjecturally suggests that= the known forms of SNFS might not apply to p. Of course, vulnerability to= SNFS should nonetheless be tested, just like for any other DH prime. (* a= heuristic reason: a generic ability to find modularly-efficient polynomial= expressions for factorials would lead to an efficient factoring algorithm,= though, of course, 427 factorial may be an exception to this conjectured r= ule.) 4. The cofactor 630 is small. Though not 2, as in a "safe" prime, 630 is s= till small enough (either to use as a cofactor exponent, or to let a few fi= xed bits out of a 3000 to leak.)=20 5. The cofactor 630 is small as possible, for the choice 427!+1 of large pr= ime factor of p-1. (Again, a choice aimed to rule out any tricks.) Also, 6= 30 is a slightly smaller than what one would expect on average. 6. The bit length of p is at least 3072 bits, corresponding to 128-bit secu= rity, with modest margin for error (against improvements in GNFS, etc.) (V= arying this conditions, allows for other similar expressions for primes, bu= t not too many.) 7. The large prime order subgroup has order q =3D 427!+1, with the property= that q-1 is very smooth (compared to average). This property of q-1 shoul= d make den Boer's reduction between the DHP and DLP nearly optimal. =20 8. Questionably: the special form of p might enable mild speed-ups (compare= d to random primes) in modular reduction.=20 9. Beyond just its compact expression, as measured in its 14-character coun= t, there _seem_ to be very few primes that share all of the benefits above = (e.g. near-optimal den Boer reductions), so its specialness is even greater= than its compactness suggests. This specialness further ensures resistanc= e to malicious-search attacks (like Gordon's). (This advantage overlaps wi= th advantages 2 and 5). I'm not saying that classic DH is preferable to alternatives ECDH (or QR cr= ypto), it is not. But classic DH has a role in a high-end systems that can= afford to apply multiple layers of security (in an effort to protect again= st a major catastrophe of one algorithm failing). =20 Some IETF protocols currently allow several classic DH primes. Some are der= ived from pi, or e, which is an example of a strategy often called nothing-= up-my-sleeve (NUMS). These extant NUMS DH primes resist known attacks, but= I'm wondering if p=3D630*(427!+1)+1 seems to have some mild advantages ove= r these, mainly stronger security arguments (including an arguably better N= UMS-type argument), as listed above. =20 Again, my main proviso for p=3D630*(427!+1)+1 is that I have not tried to r= un some kind of SNFS on p. I truly have very limited understanding of the = NFS, so maybe I am missing something obvious, such as the factorial enablin= g the SNFS (or some new of variant of SNFS). Despite this risk, I still tho= ught special prime was at least worth further consideration. =20 Best regards, Dan Brown=20 Certicom, BlackBerry PS The situation for ECDH is a little different from FFDH, because of Gordo= n's attack, which involves a hidden weakness of known kind, i.e. a trapdoor= . Therefore, in FFDH the imperative to use some form of NUMS to exclude a = trapdoor is a greater than in ECDH. For ECDH, the main risk seems to be a= totally new attack, which, in my opinion, increases the relative imperativ= e to choose a pseudorandom curve (as I've argued previously on the CFRG lis= t). Obviously p=3D630*(427!+1)+1 is not pseudorandom. (Choosing a pseudor= andom classic DH prime weakens the NUMS-type arguments against trapdoors (b= ecause the prime would be less compact), and likely weakens the effectivene= ss of the den Boer reduction.) From nobody Wed Apr 5 13:32: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 8AEA2129498 for ; Wed, 5 Apr 2017 13:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtJPNZ1ZOZZN for ; Wed, 5 Apr 2017 13:32:26 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FCE1293F2 for ; Wed, 5 Apr 2017 13:32:26 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 685AB117E06A; Wed, 5 Apr 2017 13:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=h1cGreUWXHGyOL+iEWs7462TUqI=; b=F1t60IExaNRJ2w 4KHjWMDjtEwPfNAc9KX7A6eX40/ohT/dHBIjI/UsKeQJnZiO8Z7/mvLmVJLhYar1 cNAnpehuJ76BQeHL26GNxDG7Ub7aqiiPuDJwcYrn7/+AkY7tdkCn64cREgP4a/AC UetlurQ1ih7776edGvECB4q3Dtzw4= Received: from [10.119.72.230] (unknown [173.245.83.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPSA id 2A204117E065; Wed, 5 Apr 2017 13:32:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Greg Rose In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> Date: Wed, 5 Apr 2017 13:32:25 -0700 Cc: Greg Rose , "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 05 Apr 2017 20:32:29 -0000 > On Apr 5, 2017, at 12:39 , Dan Brown wrote: > [snip]... for the choice 427!+1 of large prime factor of p-1. [snip] >=20 Since a surprisingly large number of people think that N!+1 must be = prime (referring back to the proof that there are an infinite number of = primes) I checked. It is. Not that I ever doubted you, Dan... Greg.= From nobody Wed Apr 5 14:20: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 7AB25128B88 for ; Wed, 5 Apr 2017 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6pjtG0DQhRT for ; Wed, 5 Apr 2017 14:20:31 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700131294AB for ; Wed, 5 Apr 2017 14:20:27 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g2so15731883pge.3 for ; Wed, 05 Apr 2017 14:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Kqnl+hwOJjrZq9oqiIaV51MbODLIasYwN177795XYP0=; b=DoTVDZga7Aa8Eg9E7QozEMCWm3dqm1nAU4HwPsiV1RLr7ObOh1j1y9DVwmkdimiW98 9DpoeYCbKu9YQfAnvU+qpeAPL6n1W6ai1g4F9hMfJUiE7g7UfOm4UhZBDmQ9ZAsLTQG8 TOD7iAMmZXvBhkP/dZ8Q2d9JrDzGZ6L0mHG0NhZ05nBbAN4R8TDm52SathMMylHUh1rM 9H0Vpc+isK0u2IG5W01h5MyX+Gco6EAivll/BRSVkmtOQj3hw9qPsQyehSk3qgndFVlo aROOIs00hi2eyaQM0Pf+rcyn5JL2OyeYJKne3IbTUZc9scsj1YgU4f7KucTEnl9/r8Wt MaIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Kqnl+hwOJjrZq9oqiIaV51MbODLIasYwN177795XYP0=; b=FNfIbubB4krLS+OAi0c4OQcndQby6LQ5mndtlX2fqNRfDozGRPis8d5mGt5UsHRxZp klir0y4WR472Tw0xwd9ZMXmImxh4JBN2Lti8dbe7rdr3VIou+AhZQMtSqV8sQfA7VE3O QInCTJirFjUT1oix43LNtqazxpygT66JBRAcdMWtNGd5RxB1uVa3+rO0pHPT4YK82T2n cLIJZ6xjx6JhYvfnJ/sYMw3PVHujnXc7HBgut5N9NJA3E5i5/lLXy7A7NBbnqiS32GZl BSZM70vrG1vK7UQ0HitGJPUQeWdKF5TM8Pn+M0dIBMG9fqqOfnx19Wh/eFbQsoffIvXy 3KTg== X-Gm-Message-State: AFeK/H2yw2VKkTWDeevfdKeEP8TPdzaO19A52TQfNo7lVLoMLz9zXVVnMklRjN1xPlATOw== X-Received: by 10.84.163.75 with SMTP id n11mr38206858plg.186.1491427226677; Wed, 05 Apr 2017 14:20:26 -0700 (PDT) Received: from [192.168.1.126] ([52.119.113.96]) by smtp.gmail.com with ESMTPSA id d1sm39194661pfk.20.2017.04.05.14.20.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:20:26 -0700 (PDT) From: Oleg Andreev Message-Id: <1D27C89D-2196-44F6-B3DD-67C961B35442@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_10420D0E-E717-49E3-B0E4-CE5E7251C242" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Apr 2017 14:20:24 -0700 In-Reply-To: Cc: cfrg@irtf.org To: Dmitry Khovratovich References: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cfrg] Questions regarding BIP32-Ed25519 (was: Interest in an "Ed25519-HD" standard?) 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, 05 Apr 2017 21:20:35 -0000 --Apple-Mail=_10420D0E-E717-49E3-B0E4-CE5E7251C242 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A quick follow-up: I have simplified our spec a little to pack = additional bits on entropy to the private key part (instead of borrowing = one byte from the chain code), and renamed "salt" / "chain code" to a = "derivation key" because it enables derivation and proofs of linkage. = I've also clarified what EdDSA public and private keys are in the = glossary. Curious if that's more easy to follow now. = https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specification= s/chainkd.md > On 4 Apr 2017, at 02:40, Dmitry Khovratovich = wrote: >=20 > Hi Oleg, >=20 > thank you for the questions! >=20 > On Fri, Mar 31, 2017 at 8:06 PM, Oleg Andreev > wrote: > Dmitry, >=20 > Thanks for your with Jason paper on adopting BIP32 to Ed25519 and = critique of ChainKD, very appreciated. I have a few questions about it: >=20 > 1. Why do you impose requirements on the master secret to yield 3rd = high bit to be zero, while you can simply set it to zero along with = other 5 bits. In two places you mention that you reject non-compliant = master secret, but in Security section (F) you say "we set 6 bits", = which is what seems to be the intention all along. >=20 > Our idea was to reject as few master secrets as possible, so we = decided to clear only one extra bit, thus rejecting half of master keys. = By setting 6 bits I mean that we set three highest and three lowest = bits. > =20 >=20 > 2. You choose 2^20 as a max depth level therefore leaving 2^230 bits = for the derived key. In your paper you round this down to whole number = of bytes (28 bytes -> 2^224) while it's actually possible to slightly = increase collision-resistance by taking 29 bytes instead and clearing = top 2 bits. Have you considered that, and if yes, is there any issues = with that? >=20 > Apart from clearing one more bit, the idea to take 28 bytes instead of = 29 is to cut a 32-bit word, which could simplify some implementations. I = agree it is a minor issue. > =20 >=20 > 3. What was the rationale for 2^20 as a depth limit? I myself don't = have a good framework to decide which limit is the best, so I'm = wondering if you have? :) >=20 > The use cases we have seen did not require hierarchy deeper than a few = dozen levels. I think 2^20 is a safe bound as long as every new level = has some real-world meaning (extra wallet, extra connection, etc.), and = thus it seems unlikely that this set will be ever exhausted by any user. > =20 >=20 > 4. You effectively make xprv to be 96-byte string (32 bytes for the = scalar, 32 bytes for the "prefix" used in nonce generation and 32 byte = chain code), and use two HMAC calls to derive new chain code separately = from the privkey. Have you considered expanding the 64-byte privkey (as = defined by NaCl library) from the scalar itself? In my recent tweak to = ChainKD scheme [1] I'm doing that and to stay fully compatible with = EdDSA requirement that prefix originally has 256 bits of entropy, add = only one secret byte ("pepper") that eats 8 bits from the chain code = (which we call "salt"). This allows us to keep both xprv and xpub 64 = bytes long and avoid double-HMAC when deriving public keys - single hash = call produces a key component and another salt value. >=20 > We just tried to mimic the original BIP32 key derivation as much as = possible. I am not sure I entirely understands the rationale behind your = manipulation with bytes of private key after you add up the hash output. = Also, could you elaborate on the notions of EdDSA public and private = keys, which seem to complement public and private keys you derive in the = scheme? >=20 > Best regards, > Dmitry >=20 > =20 >=20 > Thank you! >=20 > [1] Updated ChainKD: = https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specification= s/chainkd.md = >=20 >=20 >=20 > > Being a co-author of [5], I am ready to contribute to such a = document. I > > will present our own proposal at > > http://prosecco.gforge.inria.fr/ieee-blockchain2016/ = in Paris just = before > > the CFRG meeting at the same place next day. It would be great if we = come > > up with some proposal to discuss it already there. > > > > The most recent version is > > https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA = It has = some > > critique of [6], hopefully not too offensive:) > > > > Our motivation in [5] was to generate private keys satisfying the > > Curve25519 requirements too so that the code can be reused, even if = in the > > signature setting some attacks would not apply. But it would be = great to > > have comments from the community as well. > > > > Best regards, > > Dmitry > > > > On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker = > > > wrote: > > > > > You can do hierarchical key derivation in Montgomery without the = need for > > > an add. > > > > > > Say your master key is x. To generate a key for site 'example.com = ' we > > > take > > > > > > xs =3D (x + H('example.com ')) mod q > > > > > > Where q is the sub group order. > > > > > > In fact that isn't really using any EC relevant operation at all. = Perhaps > > > I am not understanding the full requirements for the scheme. > > > > > > > > > I don't follow the argument about small subgroups in the = referenced post. > > > With Curve25519 and Ed25519 we have chosen the curve cofactor and = the > > > generator point. So there is only one group that our point can = possibly be > > > in regardless of whether our private key is (x mod q) or (x mod q = + nq). We > > > are going to arrive at the same set of points regardless. > > > > > > > > > I do very much prefer the Edwards curves though because we can = combine two > > > keypairs by simply adding the corresponding public and private = keys. That > > > allows us to do the co-generation trick I showed a while back. > > > > > > We can also split the key, give one part to a recryption service = and > > > encrypt the other half under the public key of the recipient. This = allows > > > us to support group messaging through proxy re-encryption. > > > > > > Some applications of that are encumbered (possibly) under a soon = to expire > > > patent. > > > > > > > > > > > > On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker < > > > phill@hallambaker.com > wrote: > > > > > >> I have just implemented Proxy Re-Encryption under Ed-25519 and = Ed448. I > > >> think EdCurve Crypto is a good plan. > > >> > > >> Or we could do it on the Montgomery Curves and give the algorithm = for > > >> point addition. > > >> > > >> On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri > wrote: > > >> > > >>> Hierarchical key derivation (also sometimes described as = "semiprivate > > >>> keys" or "key blinding") is an increasingly popular technique = for > > >>> generating unlinkable child keys from master public and private = keys. > > >>> > > >>> The Tor Project has been exploring such an approach as the basis = for > > >>> their next-generation hidden services design for several years = now[1], > > >>> during which time it has received security proofs[2]. Their = latest > > >>> design[3] allegedly includes feedback from Dan Bernstein. > > >>> > > >>> Application of hierarchical key derivation is perhaps most = notable in > > >>> the cryptocurrency space, where Bitcoin's BIP32[4] provided a = means for > > >>> unlinkable single-use signature keys for the secp256k1 elliptic = curve. > > >>> There are several designs for applying the ideas from BIP32 to = Ed25519, > > >>> including ones from Evernym[5] and Chain[6] (where I am an = employee). > > >>> > > >>> The designs in [3], [5], and [6] are all highly similar and = accomplish > > >>> the same goals. Personally I would love to see a single standard = design for > > >>> producing Ed25519 signatures from hierarchically derived keys, = notably one > > >>> which produces signatures that can be verified by any = off-the-shelf RFC > > >>> 8032-compatible Ed25519 implementation. > > >>> > > >>> There's already been some discussion of this on the = moderncrypto.org > > >>> curves list: > > >>> > > >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html = > > >>> > > >>> I'd be curious to know if anyone else would be interested in > > >>> collaborating on a draft for such a standard, which can be a = synthesis of > > >>> the existing work in this space. > > >>> > > >>> [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep = > > >>> tember/004026.html > > >>> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf = > > >>> [3]: https://gitweb.torproject.org/torspec.git/tree/proposal = > > >>> s/224-rend-spec-ng.txt#n1979 > > >>> [4]: = https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki = > > >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- = > > >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey > > >>> s-Ed25519.pdf > > >>> [6]: https://chain.com/docs/protocol/specifications/chainkd = > > >>> > > >>> -- > > >>> Tony Arcieri > > >>> > > >>> _______________________________________________ > > >>> Cfrg mailing list > > >>> Cfrg@irtf.org > > >>> https://www.irtf.org/mailman/listinfo/cfrg = > > >>> > > >>> > > >> > > > > > > _______________________________________________ > > > Cfrg mailing list > > > Cfrg@irtf.org > > > https://www.irtf.org/mailman/listinfo/cfrg = > > > > > > > > > > > > -- > > Best regards, > > Dmitry Khovratovich >=20 >=20 >=20 > --=20 > Best regards, > Dmitry Khovratovich --Apple-Mail=_10420D0E-E717-49E3-B0E4-CE5E7251C242 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
A quick follow-up: I have simplified our spec = a little to pack additional bits on entropy to the private key part = (instead of borrowing one byte from the chain code), and renamed "salt" = / "chain code" to a "derivation key" because it enables derivation and = proofs of linkage. I've also clarified what EdDSA public and private = keys are in the glossary. Curious if that's more easy to follow = now.

https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/sp= ecifications/chainkd.md

On 4 Apr 2017, at 02:40, Dmitry = Khovratovich <khovratovich@gmail.com> wrote:

Hi Oleg,

thank you for the questions!

On Fri, = Mar 31, 2017 at 8:06 PM, Oleg Andreev <oleganza@gmail.com> wrote:
Dmitry,

Thanks for your with Jason paper on adopting = BIP32 to Ed25519 and critique of ChainKD, very appreciated. I have a few = questions about it:

1. Why do you impose = requirements on the master secret to yield 3rd high bit to be zero, = while you can simply set it to zero along with other 5 bits. In two = places you mention that you reject non-compliant master secret, but in = Security section (F) you say "we set 6 bits", which is what seems to be = the intention all along.

Our idea was to reject as few master = secrets as possible, so we decided to clear only one extra bit, thus = rejecting half of master keys. By setting 6 bits I mean that we set = three highest and three lowest bits.
 

2. You choose 2^20 as a max depth level therefore leaving = 2^230 bits for the derived key. In your paper you round this down to = whole number of bytes (28 bytes -> 2^224) while it's actually = possible to slightly increase collision-resistance by taking 29 bytes = instead and clearing top 2 bits. Have you considered that, and if yes, = is there any issues with that?

Apart from clearing one = more bit, the idea to take 28 bytes instead of 29 is to cut a 32-bit = word, which could simplify some implementations. I agree it is a minor = issue.
 

3. What was the rationale for 2^20 as = a depth limit? I myself don't have a good framework to decide which = limit is the best, so I'm wondering if you have? :)

The use cases we have seen did not require hierarchy deeper = than a few dozen levels. I think 2^20 is a safe bound as long as every = new level has some real-world meaning (extra wallet, extra connection, = etc.), and thus it seems unlikely that this set will be ever exhausted = by any user.
 

4. You = effectively make xprv to be 96-byte string (32 bytes for the scalar, 32 = bytes for the "prefix" used in nonce generation and 32 byte chain code), = and use two HMAC calls to derive new chain code separately from the = privkey. Have you considered expanding the 64-byte privkey (as defined = by NaCl library) from the scalar itself? In my recent tweak to ChainKD = scheme [1] I'm doing that and to stay fully compatible with EdDSA = requirement that prefix originally has 256 bits of entropy, add only one = secret byte ("pepper") that eats 8 bits from the chain code (which we = call "salt"). This allows us to keep both xprv and xpub 64 bytes long = and avoid double-HMAC when deriving public keys - single hash call = produces a key component and another salt value.

We just tried to mimic the original BIP32 key derivation as = much as possible. I am not sure I entirely understands the rationale = behind your manipulation with bytes of private key after you add up the = hash output. Also, could you elaborate on the notions of EdDSA public = and private keys, which seem to complement public and private keys you = derive in the scheme?

Best regards,
Dmitry

 

Thank you!

[1] Updated ChainKD: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md



> Being a = co-author of [5], I am ready to contribute to such a document. I
> will present our own proposal at
> http://prosecco.gforge.inria.fr/ieee-blockchain2016/ in Paris  just = before
> the CFRG meeting at the same place next day. = It would be great if we come
> up with some proposal to = discuss it already there.
>
> The most = recent version is
> https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA It has some
> critique of [6], hopefully not too offensive:)
>
> Our motivation in [5] was to generate = private keys satisfying the
> Curve25519 requirements = too so that the code can be reused, even if in the
> = signature setting some attacks would not apply. But it would be great = to
> have comments from the community as well.
>
> Best regards,
> = Dmitry
>
> On Wed, Mar 22, 2017 at = 5:00 AM, Phillip Hallam-Baker <phill@hallambaker.com
> > wrote:
>
> > You can do hierarchical key = derivation in Montgomery without the need for
> > an = add.
> >
> > Say your master key = is x. To generate a key for site 'example.com' we
> > take
> >
> = > xs =3D (x + H('example.com')) mod q
> = >
> > Where q is the sub group order.
> >
> > In fact that isn't really = using any EC relevant operation at all. Perhaps
> > = I am not understanding the full requirements for the scheme.
> >
> >
> > I = don't follow the argument about small subgroups in the referenced = post.
> > With Curve25519 and Ed25519 we have chosen = the curve cofactor and the
> > generator point. So = there is only one group that our point can possibly be
> = > in regardless of whether our private key is (x mod q) or (x mod q + = nq). We
> > are going to arrive at the same set of = points regardless.
> >
> >
> > I do very much prefer the Edwards curves though = because we can combine two
> > keypairs by simply = adding the corresponding public and private keys. That
> = > allows us to do the co-generation trick I showed a while back.
> >
> > We can also split the key, = give one part to a recryption service and
> > = encrypt the other half under the public key of the recipient. This = allows
> > us to support group messaging through = proxy re-encryption.
> >
> > = Some applications of that are encumbered (possibly) under a soon to = expire
> > patent.
> >
> >
> >
> > On = Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker <
>= > phill@hallambaker.com> wrote:
> = >
> >> I have just implemented Proxy = Re-Encryption under Ed-25519 and Ed448. I
> >> = think EdCurve Crypto is a good plan.
> >>
> >> Or we could do it on the Montgomery Curves and = give the algorithm for
> >> point addition.
> >>
> >> On Tue, Mar 21, = 2017 at 3:42 PM, Tony Arcieri <bascule@gmail.com> wrote:
> = >>
> >>> Hierarchical key derivation = (also sometimes described as "semiprivate
> = >>> keys" or "key blinding") is an increasingly popular = technique for
> >>> generating unlinkable = child keys from master public and private keys.
> = >>>
> >>> The Tor Project has been = exploring such an approach as the basis for
> = >>> their next-generation hidden services design for several = years now[1],
> >>> during which time it has = received security proofs[2]. Their latest
> = >>> design[3] allegedly includes feedback from Dan = Bernstein.
> >>>
> = >>> Application of hierarchical key derivation is perhaps most = notable in
> >>> the cryptocurrency space, = where Bitcoin's BIP32[4] provided a means for
> = >>> unlinkable single-use signature keys for the secp256k1 = elliptic curve.
> >>> There are several = designs for applying the ideas from BIP32 to Ed25519,
> = >>> including ones from Evernym[5] and Chain[6] (where I am an = employee).
> >>>
> = >>> The designs in [3], [5], and [6] are all highly similar and = accomplish
> >>> the same goals. Personally I = would love to see a single standard design for
> = >>> producing Ed25519 signatures from hierarchically derived = keys, notably one
> >>> which produces = signatures that can be verified by any off-the-shelf RFC
> >>> 8032-compatible Ed25519 implementation.
> >>>
> >>> There's = already been some discussion of this on the moderncrypto.org
> >>> curves = list:
> >>>
> = >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html
> >>>
> >>> I'd be = curious to know if anyone else would be interested in
> = >>> collaborating on a draft for such a standard, which can be = a synthesis of
> >>> the existing work in this = space.
> >>>
> >>> = [1]: https://lists.torproject.org/pipermail/tor-dev/2012-Sep
> = >>> tember/004026.html
> >>> = [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf
> >>> = [3]: https://gitweb.torproject.org/torspec.git/tree/proposal
> >>> = s/224-rend-spec-ng.txt#n1979
> >>> [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
> >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of-
> >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey
> >>> s-Ed25519.pdf
> = >>> [6]: https://chain.com/docs/protocol/specifications/chainkd
> >>>
> >>> --
> >>> Tony Arcieri
> = >>>
> >>> = _______________________________________________
> >>> Cfrg mailing list
> = >>> Cfrg@irtf.org
> >>> https://www.irtf.org/mailman/listinfo/cfrg
> >>>
> >>>
> >>
> >
> > = _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> >
> = >
>
>
> --
>= Best regards,
> Dmitry Khovratovich



-- 
Best regards,
Dmitry = Khovratovich

= --Apple-Mail=_10420D0E-E717-49E3-B0E4-CE5E7251C242-- From nobody Wed Apr 5 16:20: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 6CB791293DA for ; Wed, 5 Apr 2017 16:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A09l4lh3EOL for ; Wed, 5 Apr 2017 16:20:27 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7423B128C84 for ; Wed, 5 Apr 2017 16:20:27 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 09319117E06C; Wed, 5 Apr 2017 16:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=SbgeEKEGZ7tG13W6F1GbyZtZfc0=; b=LI4Uyq3TaI9rTS W+m3d1cYsaSjZpYAzlYbbZM+IVcKhBh/z17xriSIhhtdHM64pOf1YRRoanl4K2EL 5btWqkN7NJL/V3F6Y5Ew18QRalSY52OKnPVDoSWpdpbOHrSJZYkLGd13RNCjBr5h Pb64GjMRH2AoV0sc5+FDXybvIsydk= Received: from [10.119.72.230] (unknown [173.245.83.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPSA id C61C4117E065; Wed, 5 Apr 2017 16:20:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Greg Rose In-Reply-To: Date: Wed, 5 Apr 2017 16:20:26 -0700 Cc: Dan Brown , "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> To: Greg Rose X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 05 Apr 2017 23:20:29 -0000 On Apr 5, 2017, at 13:32 , Greg Rose wrote: >=20 >=20 >> On Apr 5, 2017, at 12:39 , Dan Brown = wrote: >> [snip]... for the choice 427!+1 of large prime factor of p-1. [snip] >>=20 >=20 > Since a surprisingly large number of people think that N!+1 must be = prime (referring back to the proof that there are an infinite number of = primes) I checked. It is. Not that I ever doubted you, Dan... A number of people responded off-list asking why I said this, and/or how = I checked primality. Quoting: https://primes.utm.edu/notes/proofs/infinite/euclids.html > Theorem. > There are infinitely many primes. > Proof. > Suppose that p1=3D2 < p2 =3D 3 < ... < pr are all of the primes. Let P = =3D p1p2...pr+1 and let p be a prime dividing P; then p can not be any = of p1, p2, ..., pr, otherwise p would divide the difference = P-p1p2...pr=3D1, which is impossible. So this prime p is still another = prime, and p1, p2, ..., pr would not be all of the primes. > It is a common mistake to think that this proof says the product = p1p2...pr+1 is prime. The proof actually only uses the fact that there = is a prime dividing this product. I calculated 427!+1 using bc, edited it to remove continuation lines, = and pasted the result into https://www.alpertron.com.ar/ECM.HTM. If it = had been composite, it might have taken a long time when asked to factor = it, but it takes very little time to come back and say that it's prime = (that is, it is its only non-trivial factor). However, I then proceeded with the obvious experiment to check the = original number: (quoting Dan's original mail) > Is the prime p=3D630*(427!+1)+1 vulnerable to the SNFS, or some = variant of SNFS? I think not, but I could easily be very wrong. Somewhat to my dismay, it did NOT immediately pronounce the number to be = prime. 20 minutes later it's still trying to factor it. I don't have = anything to hand that will just check primality... perhaps someone else = should check it. (Or I will try harder when I have something better than = my laptop, which will be a while). It's also possible I made some sort = of transcription error, and if so I apologize. Someone who has = Mathematica or Maple lying around? Greg.= From nobody Wed Apr 5 16:25:44 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6D126FB3 for ; Wed, 5 Apr 2017 16:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP9OkSMrNZIc for ; Wed, 5 Apr 2017 16:25:40 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622D0126D85 for ; Wed, 5 Apr 2017 16:25:40 -0700 (PDT) Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id DFB68117E06A; Wed, 5 Apr 2017 16:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=VxqhPZEG18C1jlpgVI0ODxv0HxM=; b=vJxOfTESzVr72R t5uCQADYBnC5Zx3y5ezTg1eEzLiIqq29j4ttseHVlKjCNHoTVoERulK6ATvRnCFP CDzjTwrZNhuSyRnF40qgPeZqB7Ozc27j7wyZNhQwsPbwKYylx2eSPhl4O5Xe6d7K sbiQG7GeXnfD6/rJ/zA/oPtYqkyUY= Received: from [10.119.72.230] (unknown [173.245.83.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPSA id A714C117E065; Wed, 5 Apr 2017 16:25:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Greg Rose In-Reply-To: <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> Date: Wed, 5 Apr 2017 16:25:38 -0700 Cc: Dan Brown , "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9B83EE0E-E5DC-451B-9D3B-D5576DA71CC1@seer-grog.net> References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> To: Greg Rose X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 05 Apr 2017 23:25:42 -0000 OK, I apologize... the program (which I didn't write) kept stale state = lying around. When I restarted it, it said: 1 830998 721485 262949 894836 702451 036961 346345 183758 057314 969605 = 832210 766165 484702 660527 749681 669753 293173 634175 291671 053884 = 438775 722488 816078 101720 141886 540180 229728 708756 676904 267800 = 678375 988109 211903 639383 849998 133815 812655 789179 917782 318753 = 560669 025779 190769 237162 496508 423323 724885 434846 784602 021522 = 663931 265719 264163 422908 174749 084948 418025 158073 086974 407112 = 952072 014257 210539 064732 122044 449074 000638 203336 247808 232800 = 652739 257418 300964 286406 604674 828535 227832 036133 240428 107251 = 355410 159614 879003 579690 248976 997943 069280 372792 089146 955523 = 612918 267331 616675 492696 740809 033257 982724 038666 839691 447355 = 159466 625504 307450 674480 068371 423101 067410 940809 499585 043794 = 510375 720619 282353 170149 104988 150297 750261 797134 258461 975343 = 104442 292481 380023 690803 048872 074527 925875 984122 186106 029245 = 281730 797546 168103 284672 654245 481350 717852 877532 157706 240000 = 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 = 000000 000000 000000 000000 000000 000000 000631 (943 digits) is prime ... back to your normally scheduled program. Greg. Phone/Signal: +1 619 890 8236=20 GPG/PGP: 1081A37C 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > On Apr 5, 2017, at 16:20 , Greg Rose wrote: >=20 > On Apr 5, 2017, at 13:32 , Greg Rose wrote: >>=20 >>=20 >>> On Apr 5, 2017, at 12:39 , Dan Brown = wrote: >>> [snip]... for the choice 427!+1 of large prime factor of p-1. [snip] >>>=20 >>=20 >> Since a surprisingly large number of people think that N!+1 must be = prime (referring back to the proof that there are an infinite number of = primes) I checked. It is. Not that I ever doubted you, Dan... >=20 > A number of people responded off-list asking why I said this, and/or = how I checked primality. >=20 > Quoting: https://primes.utm.edu/notes/proofs/infinite/euclids.html >> Theorem. >> There are infinitely many primes. >> Proof. >> Suppose that p1=3D2 < p2 =3D 3 < ... < pr are all of the primes. Let = P =3D p1p2...pr+1 and let p be a prime dividing P; then p can not be any = of p1, p2, ..., pr, otherwise p would divide the difference = P-p1p2...pr=3D1, which is impossible. So this prime p is still another = prime, and p1, p2, ..., pr would not be all of the primes. >> It is a common mistake to think that this proof says the product = p1p2...pr+1 is prime. The proof actually only uses the fact that there = is a prime dividing this product. >=20 > I calculated 427!+1 using bc, edited it to remove continuation lines, = and pasted the result into https://www.alpertron.com.ar/ECM.HTM. If it = had been composite, it might have taken a long time when asked to factor = it, but it takes very little time to come back and say that it's prime = (that is, it is its only non-trivial factor). >=20 > However, I then proceeded with the obvious experiment to check the = original number: (quoting Dan's original mail) >> Is the prime p=3D630*(427!+1)+1 vulnerable to the SNFS, or some = variant of SNFS? I think not, but I could easily be very wrong. >=20 > Somewhat to my dismay, it did NOT immediately pronounce the number to = be prime. 20 minutes later it's still trying to factor it. I don't have = anything to hand that will just check primality... perhaps someone else = should check it. (Or I will try harder when I have something better than = my laptop, which will be a while). It's also possible I made some sort = of transcription error, and if so I apologize. Someone who has = Mathematica or Maple lying around? >=20 > Greg. From nobody Wed Apr 5 18:34:01 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4625A126D85 for ; Wed, 5 Apr 2017 18:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 91mcx5GS9VJM for ; Wed, 5 Apr 2017 18:33:58 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0106.outbound.protection.outlook.com [104.47.33.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D06D124BE8 for ; Wed, 5 Apr 2017 18:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JkojmmhTHq64xZWtT6VP1zu1hS6MinspsbCTY3MZXDM=; b=LYHR84aeg4N2Q6Tj8Fphv7yg2GTEj/x+Ez3sW77ystiCzL1/2gy9gfEtvmsEHWtIqdCRy4JasTHnhAdLYMkQEWgLEiIm8SlBG+2JVf65hdEV7g6cWzGnOFr4rraDyS7BoaPpN3fJ9znZ5eIgNr5T4wQrdHGuTXz66WwLPWILtq8= Received: from SN2PR0501MB846.namprd05.prod.outlook.com (10.160.14.144) by SN2PR0501MB847.namprd05.prod.outlook.com (10.160.14.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 01:33:56 +0000 Received: from SN2PR0501MB846.namprd05.prod.outlook.com ([10.160.14.144]) by SN2PR0501MB846.namprd05.prod.outlook.com ([10.160.14.144]) with mapi id 15.01.1019.015; Thu, 6 Apr 2017 01:33:56 +0000 From: Travis Finkenauer To: Greg Rose CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Prime 630*(427!+1)+1 for classic DH? Thread-Index: AdKuRDlyn/lIDT1CSziTnc33dxF2iAAB4K6AAAXeMAAABKlJAA== Date: Thu, 6 Apr 2017 01:33:56 +0000 Message-ID: <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> In-Reply-To: <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: seer-grog.net; dkim=none (message not signed) header.d=none;seer-grog.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; SN2PR0501MB847; 7:9waoPR7/WmCkLAh0p1W/ogy2FpF9vdoKbZdr6/cbJBo+f3I1L2K6zIxx5mjMNetlgAXytj7h+Ivttim5sVyIayBnjTTaHE0uAprTUd//l1Eb+usuNzXlavh45sGDamuSQviTJd//8vNeyN1Jz2LLYEmNvZdVbPATOGIXD7wORCfLq+fP2SJ285u+RnSlPWTUrzzeqiM778HtJQ0qEPeLTGpKs68BIR0H2SCDUSAbxQN3nM5JobpYUGplansaIIPVRKjSfxQdOMif2qwwFPL7mk7XldmAosdgPjPBEbzo6fznAMTMXYrkXCyhsyQ4gL9HM4W/wXQTmUnpqNUPw70iqQ== x-ms-office365-filtering-correlation-id: a21c9b3a-b081-406b-6d81-08d47c8cfe17 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR0501MB847; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(6072148); SRVR:SN2PR0501MB847; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB847; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(102836003)(3846002)(6116002)(189998001)(122556002)(33656002)(2950100002)(6916009)(36756003)(50986999)(54356999)(4326008)(76176999)(229853002)(2906002)(25786009)(6512007)(6306002)(3280700002)(81166006)(2900100001)(8676002)(5660300001)(66066001)(110136004)(7736002)(53936002)(6506006)(8936002)(86362001)(83716003)(6436002)(6246003)(6486002)(3660700001)(82746002)(77096006)(305945005)(99286003)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB847; H:SN2PR0501MB846.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <54FE7B9A7FC03B49ADA512082B0295CF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 01:33:56.5225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB847 Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 06 Apr 2017 01:34:00 -0000 I verified the primality of q =3D 427!+1 and p =3D 630*(427!+1)+1 in a pyth= on shell: >>> import math, sympy >>> q =3D math.factorial(427) + 1 >>> q 290634717696073484110291540071593168467673838691755129360254894001708915156= 302009607579314550754490979941932585979532362609329479760129536206622244743= 895266703131541072488397502825504504125096700302164981563491767272351215204= 631732981320437073122067583998534799549602620384654559505624578854698733575= 026020835828454629114747329325251579113972247313188408636049674932065755112= 783978528908261023662539783841799404414005206452815755145762057823239143599= 179132575846354941784194937658945303199938869683107887341107459990963377836= 951125261421511684590201163748678649634403303021152060749847407434871658310= 342772480238778960424520645773241762074192212826904696038697541329479463378= 151296849064283833380595279650338771184440530651498776584346035506476674424= 138813956488251447966048576070679639809134312397346773437181822436621881409= 132088524800000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000001L >>> p =3D 630 * q + 1 >>> p 183099872148526294989483670245103696134634518375805731496960583221076616548= 470266052774968166975329317363417529167105388443877572248881607810172014188= 654018022972870875667690426780067837598810921190363938384999813381581265578= 917991778231875356066902577919076923716249650842332372488543484678460202152= 266393126571926416342290817474908494841802515807308697440711295207201425721= 053906473212204444907400063820333624780823280065273925741830096428640660467= 482853522783203613324042810725135541015961487900357969024897699794306928037= 279208914695552361291826733161667549269674080903325798272403866683969144735= 515946662550430745067448006837142310106741094080949958504379451037572061928= 235317014910498815029775026179713425846197534310444229248138002369080304887= 207452792587598412218610602924528173079754616810328467265424548135071785287= 753215770624000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000631L >>> sympy.ntheory.isprime(q) True >>> sympy.ntheory.isprime(p) True -Travis > On Apr 5, 2017, at 4:20 PM, Greg Rose wrote: >=20 >=20 > Somewhat to my dismay, it did NOT immediately pronounce the number to be = prime. 20 minutes later it's still trying to factor it. I don't have anythi= ng to hand that will just check primality... perhaps someone else should ch= eck it. (Or I will try harder when I have something better than my laptop, = which will be a while). It's also possible I made some sort of transcriptio= n error, and if so I apologize. Someone who has Mathematica or Maple lying = around? >=20 > Greg. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Wed Apr 5 18:54:23 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4B126D85 for ; Wed, 5 Apr 2017 18:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.703 X-Spam-Level: X-Spam-Status: No, score=-3.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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=junipernetworks.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 6BTfli737KxC for ; Wed, 5 Apr 2017 18:54:19 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0110.outbound.protection.outlook.com [104.47.34.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8F4124BE8 for ; Wed, 5 Apr 2017 18:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F5fCC0lhgi/4UFnafaiTAD2H4ZbW7MNfw3AHiyVa8kQ=; b=FwztNyqQzzNgRywYSphh39mI2SZW+r3bs1A4fxydJj7NgwJokDTmNXdK0ol7uIcuk1vAnZ10uwBv9J/C+/105wHTBsQKd/xBkbG7d+iUtbws4Vi/31EqJBaFzq/fBI1wP1skRUb93llMaFizRnfZyFsd8RkMVCngjvkC7BEr3VU= Received: from SN2PR0501MB846.namprd05.prod.outlook.com (10.160.14.144) by SN2PR0501MB847.namprd05.prod.outlook.com (10.160.14.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 01:54:18 +0000 Received: from SN2PR0501MB846.namprd05.prod.outlook.com ([10.160.14.144]) by SN2PR0501MB846.namprd05.prod.outlook.com ([10.160.14.144]) with mapi id 15.01.1019.015; Thu, 6 Apr 2017 01:54:18 +0000 From: Travis Finkenauer To: Greg Rose CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Prime 630*(427!+1)+1 for classic DH? Thread-Index: AdKuRDlyn/lIDT1CSziTnc33dxF2iAAB4K6AAAXeMAAABKlJAP//kFmA Date: Thu, 6 Apr 2017 01:54:18 +0000 Message-ID: <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> In-Reply-To: <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: seer-grog.net; dkim=none (message not signed) header.d=none;seer-grog.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; SN2PR0501MB847; 7:KktUCFE2LKQKma2qH6JfnJI2Jx7LZ1LF+8CPX1mQUaxeaoX7zgcZ4RRZvq2GFFp4jhonRMMEtNj470R3T5fNHz2zk+uVKP3jVxI6dZR5RWBzZgI6xtPJkf2H7Yi01wO9s516RjccoAx0UQA8Z0FwFb/0xbs5g1zIWd69pW3p7U0tY1k2PeMIH7RAeo9RcOqx8WrkOK0ZMW0KCrDKNFqP8ws5UBpaNcfFWAmj5WEda+XyVE5cgnHKNRQl/6NJ9V78v3yCo9w8mSZbg9jQ5Y3c2ifULiWQb6NquRTq+j+yc8NuNI9UFh0YMRyjOUn4OMvEjKqYyuZAfaEnxiG+wca52w== x-ms-office365-filtering-correlation-id: 6e798528-acef-4e3c-34f7-08d47c8fd643 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR0501MB847; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:SN2PR0501MB847; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB847; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39840400002)(39860400002)(39410400002)(24454002)(377454003)(7736002)(110136004)(5660300001)(66066001)(3280700002)(6306002)(81166006)(6512007)(8676002)(2900100001)(3660700001)(6486002)(38730400002)(83506001)(99286003)(82746002)(305945005)(77096006)(53936002)(83716003)(6436002)(6246003)(8936002)(86362001)(6506006)(4001350100001)(33656002)(6916009)(2950100002)(3846002)(6116002)(189998001)(102836003)(122556002)(229853002)(93886004)(25786009)(2906002)(36756003)(53546009)(76176999)(4326008)(50986999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB847; H:SN2PR0501MB846.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 01:54:18.1517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB847 Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 06 Apr 2017 01:54:22 -0000 SSBqdXN0IHJlYWxpemVkIHRoZSAnPj4+JyBvZiB0aGUgcHl0aG9uIHNoZWxsIG1pZ2h0IGJlIHJl bmRlcmVkIGFzIGEgdHJpcGxlIGJsb2NrcXVvdGU7IGhlcmUgaXMgdGhlIHB5dGhvbiBzZXNzaW9u IHdpdGggJz4+PicgcmVwbGFjZWQgd2l0aCAnJSc6DQoNCiUgaW1wb3J0IG1hdGgsIHN5bXB5DQol IHEgPSBtYXRoLmZhY3RvcmlhbCg0MjcpICsgMQ0KJSBxDQoyOTA2MzQ3MTc2OTYwNzM0ODQxMTAy OTE1NDAwNzE1OTMxNjg0Njc2NzM4Mzg2OTE3NTUxMjkzNjAyNTQ4OTQwMDE3MDg5MTUxNTYzMDIw MDk2MDc1NzkzMTQ1NTA3NTQ0OTA5Nzk5NDE5MzI1ODU5Nzk1MzIzNjI2MDkzMjk0Nzk3NjAxMjk1 MzYyMDY2MjIyNDQ3NDM4OTUyNjY3MDMxMzE1NDEwNzI0ODgzOTc1MDI4MjU1MDQ1MDQxMjUwOTY3 MDAzMDIxNjQ5ODE1NjM0OTE3NjcyNzIzNTEyMTUyMDQ2MzE3MzI5ODEzMjA0MzcwNzMxMjIwNjc1 ODM5OTg1MzQ3OTk1NDk2MDI2MjAzODQ2NTQ1NTk1MDU2MjQ1Nzg4NTQ2OTg3MzM1NzUwMjYwMjA4 MzU4Mjg0NTQ2MjkxMTQ3NDczMjkzMjUyNTE1NzkxMTM5NzIyNDczMTMxODg0MDg2MzYwNDk2NzQ5 MzIwNjU3NTUxMTI3ODM5Nzg1Mjg5MDgyNjEwMjM2NjI1Mzk3ODM4NDE3OTk0MDQ0MTQwMDUyMDY0 NTI4MTU3NTUxNDU3NjIwNTc4MjMyMzkxNDM1OTkxNzkxMzI1NzU4NDYzNTQ5NDE3ODQxOTQ5Mzc2 NTg5NDUzMDMxOTk5Mzg4Njk2ODMxMDc4ODczNDExMDc0NTk5OTA5NjMzNzc4MzY5NTExMjUyNjE0 MjE1MTE2ODQ1OTAyMDExNjM3NDg2Nzg2NDk2MzQ0MDMzMDMwMjExNTIwNjA3NDk4NDc0MDc0MzQ4 NzE2NTgzMTAzNDI3NzI0ODAyMzg3Nzg5NjA0MjQ1MjA2NDU3NzMyNDE3NjIwNzQxOTIyMTI4MjY5 MDQ2OTYwMzg2OTc1NDEzMjk0Nzk0NjMzNzgxNTEyOTY4NDkwNjQyODM4MzMzODA1OTUyNzk2NTAz Mzg3NzExODQ0NDA1MzA2NTE0OTg3NzY1ODQzNDYwMzU1MDY0NzY2NzQ0MjQxMzg4MTM5NTY0ODgy NTE0NDc5NjYwNDg1NzYwNzA2Nzk2Mzk4MDkxMzQzMTIzOTczNDY3NzM0MzcxODE4MjI0MzY2MjE4 ODE0MDkxMzIwODg1MjQ4MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAxTA0KJSBwID0gNjMwICogcSArIDENCiUgcA0KMTgzMDk5ODcyMTQ4NTI2Mjk0OTg5NDgz NjcwMjQ1MTAzNjk2MTM0NjM0NTE4Mzc1ODA1NzMxNDk2OTYwNTgzMjIxMDc2NjE2NTQ4NDcwMjY2 MDUyNzc0OTY4MTY2OTc1MzI5MzE3MzYzNDE3NTI5MTY3MTA1Mzg4NDQzODc3NTcyMjQ4ODgxNjA3 ODEwMTcyMDE0MTg4NjU0MDE4MDIyOTcyODcwODc1NjY3NjkwNDI2NzgwMDY3ODM3NTk4ODEwOTIx MTkwMzYzOTM4Mzg0OTk5ODEzMzgxNTgxMjY1NTc4OTE3OTkxNzc4MjMxODc1MzU2MDY2OTAyNTc3 OTE5MDc2OTIzNzE2MjQ5NjUwODQyMzMyMzcyNDg4NTQzNDg0Njc4NDYwMjAyMTUyMjY2MzkzMTI2 NTcxOTI2NDE2MzQyMjkwODE3NDc0OTA4NDk0ODQxODAyNTE1ODA3MzA4Njk3NDQwNzExMjk1MjA3 MjAxNDI1NzIxMDUzOTA2NDczMjEyMjA0NDQ0OTA3NDAwMDYzODIwMzMzNjI0NzgwODIzMjgwMDY1 MjczOTI1NzQxODMwMDk2NDI4NjQwNjYwNDY3NDgyODUzNTIyNzgzMjAzNjEzMzI0MDQyODEwNzI1 MTM1NTQxMDE1OTYxNDg3OTAwMzU3OTY5MDI0ODk3Njk5Nzk0MzA2OTI4MDM3Mjc5MjA4OTE0Njk1 NTUyMzYxMjkxODI2NzMzMTYxNjY3NTQ5MjY5Njc0MDgwOTAzMzI1Nzk4MjcyNDAzODY2NjgzOTY5 MTQ0NzM1NTE1OTQ2NjYyNTUwNDMwNzQ1MDY3NDQ4MDA2ODM3MTQyMzEwMTA2NzQxMDk0MDgwOTQ5 OTU4NTA0Mzc5NDUxMDM3NTcyMDYxOTI4MjM1MzE3MDE0OTEwNDk4ODE1MDI5Nzc1MDI2MTc5NzEz NDI1ODQ2MTk3NTM0MzEwNDQ0MjI5MjQ4MTM4MDAyMzY5MDgwMzA0ODg3MjA3NDUyNzkyNTg3NTk4 NDEyMjE4NjEwNjAyOTI0NTI4MTczMDc5NzU0NjE2ODEwMzI4NDY3MjY1NDI0NTQ4MTM1MDcxNzg1 Mjg3NzUzMjE1NzcwNjI0MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDYzMUwNCiUgc3ltcHkubnRoZW9yeS5pc3ByaW1lKHEpDQpUcnVlDQolIHN5bXB5Lm50aGVv cnkuaXNwcmltZShwKQ0KVHJ1ZQ0KDQotVHJhdmlzDQoNCg0KT24gNC81LzE3LCA2OjMzIFBNLCAi Q2ZyZyBvbiBiZWhhbGYgb2YgVHJhdmlzIEZpbmtlbmF1ZXIiIDxjZnJnLWJvdW5jZXNAaXJ0Zi5v cmcgb24gYmVoYWxmIG9mIHRtZmlua0BqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCiAgICBJIHZlcmlm aWVkIHRoZSBwcmltYWxpdHkgb2YgcSA9IDQyNyErMSBhbmQgcCA9IDYzMCooNDI3ISsxKSsxIGlu IGEgcHl0aG9uIHNoZWxsOg0KICAgIA0KICAgID4+PiBpbXBvcnQgbWF0aCwgc3ltcHkNCiAgICA+ Pj4gcSA9IG1hdGguZmFjdG9yaWFsKDQyNykgKyAxDQogICAgPj4+IHENCiAgICAyOTA2MzQ3MTc2 OTYwNzM0ODQxMTAyOTE1NDAwNzE1OTMxNjg0Njc2NzM4Mzg2OTE3NTUxMjkzNjAyNTQ4OTQwMDE3 MDg5MTUxNTYzMDIwMDk2MDc1NzkzMTQ1NTA3NTQ0OTA5Nzk5NDE5MzI1ODU5Nzk1MzIzNjI2MDkz Mjk0Nzk3NjAxMjk1MzYyMDY2MjIyNDQ3NDM4OTUyNjY3MDMxMzE1NDEwNzI0ODgzOTc1MDI4MjU1 MDQ1MDQxMjUwOTY3MDAzMDIxNjQ5ODE1NjM0OTE3NjcyNzIzNTEyMTUyMDQ2MzE3MzI5ODEzMjA0 MzcwNzMxMjIwNjc1ODM5OTg1MzQ3OTk1NDk2MDI2MjAzODQ2NTQ1NTk1MDU2MjQ1Nzg4NTQ2OTg3 MzM1NzUwMjYwMjA4MzU4Mjg0NTQ2MjkxMTQ3NDczMjkzMjUyNTE1NzkxMTM5NzIyNDczMTMxODg0 MDg2MzYwNDk2NzQ5MzIwNjU3NTUxMTI3ODM5Nzg1Mjg5MDgyNjEwMjM2NjI1Mzk3ODM4NDE3OTk0 MDQ0MTQwMDUyMDY0NTI4MTU3NTUxNDU3NjIwNTc4MjMyMzkxNDM1OTkxNzkxMzI1NzU4NDYzNTQ5 NDE3ODQxOTQ5Mzc2NTg5NDUzMDMxOTk5Mzg4Njk2ODMxMDc4ODczNDExMDc0NTk5OTA5NjMzNzc4 MzY5NTExMjUyNjE0MjE1MTE2ODQ1OTAyMDExNjM3NDg2Nzg2NDk2MzQ0MDMzMDMwMjExNTIwNjA3 NDk4NDc0MDc0MzQ4NzE2NTgzMTAzNDI3NzI0ODAyMzg3Nzg5NjA0MjQ1MjA2NDU3NzMyNDE3NjIw NzQxOTIyMTI4MjY5MDQ2OTYwMzg2OTc1NDEzMjk0Nzk0NjMzNzgxNTEyOTY4NDkwNjQyODM4MzMz ODA1OTUyNzk2NTAzMzg3NzExODQ0NDA1MzA2NTE0OTg3NzY1ODQzNDYwMzU1MDY0NzY2NzQ0MjQx Mzg4MTM5NTY0ODgyNTE0NDc5NjYwNDg1NzYwNzA2Nzk2Mzk4MDkxMzQzMTIzOTczNDY3NzM0Mzcx ODE4MjI0MzY2MjE4ODE0MDkxMzIwODg1MjQ4MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAxTA0KICAgID4+PiBwID0gNjMwICogcSArIDENCiAgICA+Pj4gcA0K ICAgIDE4MzA5OTg3MjE0ODUyNjI5NDk4OTQ4MzY3MDI0NTEwMzY5NjEzNDYzNDUxODM3NTgwNTcz MTQ5Njk2MDU4MzIyMTA3NjYxNjU0ODQ3MDI2NjA1Mjc3NDk2ODE2Njk3NTMyOTMxNzM2MzQxNzUy OTE2NzEwNTM4ODQ0Mzg3NzU3MjI0ODg4MTYwNzgxMDE3MjAxNDE4ODY1NDAxODAyMjk3Mjg3MDg3 NTY2NzY5MDQyNjc4MDA2NzgzNzU5ODgxMDkyMTE5MDM2MzkzODM4NDk5OTgxMzM4MTU4MTI2NTU3 ODkxNzk5MTc3ODIzMTg3NTM1NjA2NjkwMjU3NzkxOTA3NjkyMzcxNjI0OTY1MDg0MjMzMjM3MjQ4 ODU0MzQ4NDY3ODQ2MDIwMjE1MjI2NjM5MzEyNjU3MTkyNjQxNjM0MjI5MDgxNzQ3NDkwODQ5NDg0 MTgwMjUxNTgwNzMwODY5NzQ0MDcxMTI5NTIwNzIwMTQyNTcyMTA1MzkwNjQ3MzIxMjIwNDQ0NDkw NzQwMDA2MzgyMDMzMzYyNDc4MDgyMzI4MDA2NTI3MzkyNTc0MTgzMDA5NjQyODY0MDY2MDQ2NzQ4 Mjg1MzUyMjc4MzIwMzYxMzMyNDA0MjgxMDcyNTEzNTU0MTAxNTk2MTQ4NzkwMDM1Nzk2OTAyNDg5 NzY5OTc5NDMwNjkyODAzNzI3OTIwODkxNDY5NTU1MjM2MTI5MTgyNjczMzE2MTY2NzU0OTI2OTY3 NDA4MDkwMzMyNTc5ODI3MjQwMzg2NjY4Mzk2OTE0NDczNTUxNTk0NjY2MjU1MDQzMDc0NTA2NzQ0 ODAwNjgzNzE0MjMxMDEwNjc0MTA5NDA4MDk0OTk1ODUwNDM3OTQ1MTAzNzU3MjA2MTkyODIzNTMx NzAxNDkxMDQ5ODgxNTAyOTc3NTAyNjE3OTcxMzQyNTg0NjE5NzUzNDMxMDQ0NDIyOTI0ODEzODAw MjM2OTA4MDMwNDg4NzIwNzQ1Mjc5MjU4NzU5ODQxMjIxODYxMDYwMjkyNDUyODE3MzA3OTc1NDYx NjgxMDMyODQ2NzI2NTQyNDU0ODEzNTA3MTc4NTI4Nzc1MzIxNTc3MDYyNDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA2MzFMDQogICAgPj4+IHN5bXB5Lm50aGVv cnkuaXNwcmltZShxKQ0KICAgIFRydWUNCiAgICA+Pj4gc3ltcHkubnRoZW9yeS5pc3ByaW1lKHAp DQogICAgVHJ1ZQ0KICAgIA0KICAgIC1UcmF2aXMNCiAgICANCiAgICA+IE9uIEFwciA1LCAyMDE3 LCBhdCA0OjIwIFBNLCBHcmVnIFJvc2UgPGdnckBzZWVyLWdyb2cubmV0PiB3cm90ZToNCiAgICA+ IA0KICAgID4gDQogICAgPiBTb21ld2hhdCB0byBteSBkaXNtYXksIGl0IGRpZCBOT1QgaW1tZWRp YXRlbHkgcHJvbm91bmNlIHRoZSBudW1iZXIgdG8gYmUgcHJpbWUuIDIwIG1pbnV0ZXMgbGF0ZXIg aXQncyBzdGlsbCB0cnlpbmcgdG8gZmFjdG9yIGl0LiBJIGRvbid0IGhhdmUgYW55dGhpbmcgdG8g aGFuZCB0aGF0IHdpbGwganVzdCBjaGVjayBwcmltYWxpdHkuLi4gcGVyaGFwcyBzb21lb25lIGVs c2Ugc2hvdWxkIGNoZWNrIGl0LiAoT3IgSSB3aWxsIHRyeSBoYXJkZXIgd2hlbiBJIGhhdmUgc29t ZXRoaW5nIGJldHRlciB0aGFuIG15IGxhcHRvcCwgd2hpY2ggd2lsbCBiZSBhIHdoaWxlKS4gSXQn cyBhbHNvIHBvc3NpYmxlIEkgbWFkZSBzb21lIHNvcnQgb2YgdHJhbnNjcmlwdGlvbiBlcnJvciwg YW5kIGlmIHNvIEkgYXBvbG9naXplLiBTb21lb25lIHdobyBoYXMgTWF0aGVtYXRpY2Egb3IgTWFw bGUgbHlpbmcgYXJvdW5kPw0KICAgID4gDQogICAgPiBHcmVnLg0KICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IENmcmcgbWFpbGluZyBs aXN0DQogICAgPiBDZnJnQGlydGYub3JnDQogICAgPiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NmcmcNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgIENmcmcgbWFpbGluZyBsaXN0DQogICAgQ2ZyZ0BpcnRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KICAg IA0KDQo= From nobody Wed Apr 5 20:37: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 EE0971201F2 for ; Wed, 5 Apr 2017 20:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JECIBG3Vsu_v for ; Wed, 5 Apr 2017 20:37:13 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 A4707124D37 for ; Wed, 5 Apr 2017 20:37:13 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 79so5336342pgf.0 for ; Wed, 05 Apr 2017 20:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PYkAHIw/Wq68teAk6SnzCvdsot6C7YvaixxgGkDvYk4=; b=ecqg5MwY2/f7TQ8sHIQxGL//egg73hR68VjgUbnCaDLYjPnUEcIbzd+PDLlPQ9BJLc rbXysTyQLCHRnzq2V+pZ+qrtzAYPj7NGMfi1Le5zcvg7tSlknDIjNJ/871hPMiaL0jvD jhRYNoAu2mTaIsuK4Fwj2D0tqL53zDc2oQFlzxGl83go/884LcAkpb1qTPpz3pPSA6lh YfOf3kjgWFGOPRKJV4hgJTcvYLnHht4H4SNNuNzuS2VgkYTgGnQZh/YtvPD3Fl9OB0tb KXTQYq+wuHIAlL9jPssxRL4zG3mZXIRjBRnAxEP0qnZhQ0bD4MwTqGkCgBT0o07M/rPy I5/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PYkAHIw/Wq68teAk6SnzCvdsot6C7YvaixxgGkDvYk4=; b=emXVlR4feTVquDOIc+f9sRHrocENaJoRR+hVMxKqc61X8tQ8iY5c5/zvffrKYB4/se mOyzlS0ACwxZIn23OUPSnOLk0UMpSBrpjEujVuMyecJJe4jsjN6feADhVIS0qJXc/EtA trVURMM9G9KFmJc8N95l+sDH+Tm6+9ljN4JmRUyP+Y9WyyrMJfjlbkqG3N74c59FMCWK RxlQjH9+S0seyPVKd9dtibuym185OiuftTy3jRVZkMQ5mf3J0ylVKDB9R5v+eO+CQ86l zUtCaW0yxmnBViG1WSfI8cF8DWm9ieU7fI4AWFjVUMaQ2IeECNfuwVlUjLyUsDm62le+ 53bw== X-Gm-Message-State: AFeK/H0yikJ0pUh3id8Re9jtC3Z7Ozp8/efPT8jUAUUk647lrenqGv5PqDIUEHW9wsdYCw== X-Received: by 10.84.192.129 with SMTP id c1mr40686600pld.181.1491449833250; Wed, 05 Apr 2017 20:37:13 -0700 (PDT) Received: from ?IPv6:2601:1c2:4f03:b950:d5dc:97f4:cdf3:d6dc? ([2601:1c2:4f03:b950:d5dc:97f4:cdf3:d6dc]) by smtp.gmail.com with ESMTPSA id a77sm378683pfl.91.2017.04.05.20.37.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 20:37:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Anna (Amy) Johnston" X-Mailer: iPad Mail (14E277) In-Reply-To: <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> Date: Wed, 5 Apr 2017 20:37:11 -0700 Cc: Greg Rose , "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> To: Travis Finkenauer Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 06 Apr 2017 03:37:15 -0000 With a prime like this (and with the knowledge that q is prime), a better wa= y (non-probabilistic) is to use Pocklington's theorem. Two exponentiations w= ith the right base and you've proved primality. q can also be checked for p= rimality with Pocklington's, but it takes a larger number of much smaller ex= ponentiations. The SNFS reduces the computation cost of the sieve, but as larger base field= s become the norm (at least 2048 bits), the linear algebra, not the sieve wi= ll be the problem (see iacr e-print 2017/067, page 8, as well as other discr= ete logarithm records in the past -- all shift work away from the linear alg= ebra to the sieve). This means that back doors are not as big a concern. If sieving attacks are the main concern, then regularly changing the primes= used would be a bigger boost to security. Fixed primes, uses everywhere, m= ean that the huge cost of the sieve and solving the system of equations have= an even bigger payoff. Changing primes regularly minimizes an attackers ga= in from any possible sieve attack -- SNFS, more general, or other index calc= ulus attacks which may be developed.=20 Pocklington's theorem is not only an efficient test for this prime, but is a= way to efficiently (if q is at least 1/2 the bits, then 2 exponentiations) t= est primality, but also quickly verify primality AND produces an element of o= rder q (the same two exponentiations). =20 A. Johnston Sent from my iPad > On Apr 5, 2017, at 18:54, Travis Finkenauer wrote: >=20 > sympy.ntheory.isprime From nobody Thu Apr 6 07:26: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 D873A129526 for ; Thu, 6 Apr 2017 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, 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 s0pZdg0ofVd1 for ; Thu, 6 Apr 2017 07:26:41 -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 92985129512 for ; Thu, 6 Apr 2017 07:26:31 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2017 10:26:31 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Apr 2017 10:26:30 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 10:26:29 -0400 From: Dan Brown To: "Anna (Amy) Johnston" CC: "cfrg@irtf.org" Thread-Topic: [Cfrg] Prime 630*(427!+1)+1 for classic DH? Thread-Index: AdKuRDlyn/lIDT1CSziTnc33dxF2iAAKQnOAAAXeLwAABKmVAAAAthgAAAOX2YAADNTDcA== Date: Thu, 6 Apr 2017 14:26:28 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501B0AC3A@XMB116CNC.rim.net> References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 06 Apr 2017 14:26:44 -0000 Good points! Responses inline below (between <<< >>> sorry if that's awkwa= rd.) -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Anna (Amy) Johnston With a prime like this (and with the knowledge that q is prime), a better w= ay (non-probabilistic) is to use Pocklington's theorem. Two exponentiation= s with the right base and you've proved primality. q can also be checked f= or primality with Pocklington's, but it takes a larger number of much small= er exponentiations. <<< Sounds right. Primality proofs are good checks before deployment. I felt = they were not needed to tentatively discuss the merits. >>> The SNFS reduces the computation cost of the sieve, but as larger base fiel= ds become the norm (at least 2048 bits), the linear algebra, not the sieve = will be the problem (see iacr e-print 2017/067, page 8, as well as other di= screte logarithm records in the past -- all shift work away from the linear= algebra to the sieve). This means that back doors are not as big a concer= n. <<<=20 I was extrapolating (too much?) from Fried et al. ia.cr/2016/961, especiall= y this from the Section 6.3 Lessons: "Both from this perspective, and from our more modern one, dismissing the risk of trapdoored primes in real usage appears to have been a mistake,= as the apparent difficulties encountered by the trapdoor designer in 1992 turn= out to be easily circumvented." My extrapolation is that for even for very large keysizes, let's not dismis= s the possibility of a trapdoor, so let's use some kind of additional count= ermeasure. I'm not alone in this, since other fixed DH prime in IETF RFCs = are derived from pi, etc. I agree that it may, in the end, be overly cautio= us, but it seems to have little cost.=20 >>> If sieving attacks are the main concern, then regularly changing the prime= s used would be a bigger boost to security. Fixed primes, uses everywhere,= mean that the huge cost of the sieve and solving the system of equations h= ave an even bigger payoff. Changing primes regularly minimizes an attacker= s gain from any possible sieve attack -- SNFS, more general, or other index= calculus attacks which may be developed.=20 <<<=20 Yes, you're essentially right about variable primes. I totally forgot to co= mpare to them. Prime 630*(427!+1)+1 should only be compared to other fixed= DH primes. At the moment, I don't remember the usual tradeoffs between fix= ed and variable classic DH primes ..., but I recall that some like fixed DH= primes.=20 Hmm, I think variable DH primes compare less favorably to 630*(427!+1)+1 on= the issue of the den Boer reduction. I rather like the original den Boer = reduction between DHP and DLP, and nearly optimizing it forces one to a spe= cial prime, which might as well (???) be fixed. I do realize that there ar= e reasonable alternatives to den Boer. Most simply, just assume that DHP h= ard. Use a Maurer-Wolf reduction, or rely on Boneh-Lipton's results about = the conjectural existence of such reductions. I just see the den Boer redu= ction as simpler, but maybe that's being too sentimental. Side joke: for those that really like to see vitanums pi and e in their pri= mes (not to mention sqrt(2)), look up Stirling's formula to find them in 63= 0*(427!+1)+1. >>> From nobody Thu Apr 6 14:40: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 53678129665 for ; Thu, 6 Apr 2017 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYcGrMlvpRmZ for ; Thu, 6 Apr 2017 14:40:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0054.outbound.protection.outlook.com [104.47.1.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E111B129556 for ; Thu, 6 Apr 2017 14:40:29 -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=c2Si3Z1RPJzS+WnORQmY6vGAmkRKND40OMtYxQHXLCk=; b=qAJj9k0yQlhrrvjqPnkMVlJFBw1MbDxeaqGVem14Adwf53E6hQMo72f8OIKCC8Qsi2Djkr5BK7EaT8liXHRZofEcp8zULH0gpZAVXgt85RIXIJL78oAAz/eGDsdCmGYfQksTe7z0zOFevjFIoH8K9SsDdGbK9iugV3BJ2c6J9rE= 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.1005.10; Thu, 6 Apr 2017 21:40:27 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::b190:a985:8b5:6f4e]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::b190:a985:8b5:6f4e%14]) with mapi id 15.01.1005.021; Thu, 6 Apr 2017 21:40:26 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Draft agenda for CFRG meeting on Sunday 30th April (at Eurocrypt 2017) Thread-Index: AQHSrx5nq2fTNFW8xESH8ZWkmnSVNg== Date: Thu, 6 Apr 2017 21:40:26 +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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [78.146.52.180] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:WkXKcOaA+jjq4RbcEm8heRLAreKZTppAZU2IfXDaXOg96gjaUupzbXYTkVlrOzgJrbppshCvGIBTK/DQuPCCOpI/hzWvnzvaNwpQ94/+reZ6vdrhzKF96heUsq+kD05SRhhN8U7SJxjKWNeB1QJMm6I34kZaEB5rypVfZSG4rpZIbr8PjeQNuVIV/IvjtdLmse7LLeD2V0GIzA8jtBUDpzLJGHp6WRCOPwLvPZCdBhHmpAnz3KlB9yZn60YYy/IdBF2vzX79gBDKxWMGI756qr1RzIdvCTrZa6xV9J05Qcp4YlH/Q1u4mhx9bRti7hE/QmvF79JdtL2TpVBp9uBeVQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(66654002)(50854003)(24454002)(52564003)(86362001)(4326008)(305945005)(2900100001)(8936002)(7736002)(561944003)(4001350100001)(50986999)(3660700001)(54356999)(99286003)(53546009)(6916009)(81166006)(3280700002)(6436002)(25786009)(42882006)(1730700003)(8676002)(6306002)(6512007)(551544002)(66066001)(5640700003)(2501003)(6506006)(3846002)(36756003)(6116002)(102836003)(53936002)(229853002)(5250100002)(189998001)(74482002)(5660300001)(2906002)(2351001)(83506001)(6486002)(38730400002)(110136004); 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: 5ba0e7fb-ec2b-44c7-b5e5-08d47d358a07 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:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906; x-forefront-prvs: 02698DF457 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6310830EC3F4104E9575E165831CD4C4@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 21:40:26.7701 (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] Draft agenda for CFRG meeting on Sunday 30th April (at Eurocrypt 2017) 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, 06 Apr 2017 21:40:34 -0000 RGVhciBDRlJHLA0KDQpIZXJlIGlzIGEgZHJhZnQgYWdlbmRhIGZvciB0aGUgQ0ZSRyBNZWV0aW5n IGluIFBhcmlzIG9uIFN1bmRheSAzMHRoIEFwcmlsLg0KQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoN ClBsZWFzZSBhbHNvIHNlZSBteSBvcmlnaW5hbCBtZXNzYWdlIGJlbG93IGZvciBpbXBvcnRhbnQg cmVnaXN0cmF0aW9uDQppbmZvcm1hdGlvbiBmb3IgdGhpcyBtZWV0aW5nLg0KDQpUaGFua3MsDQoN Cktlbm55DQoNCi0tLQ0KDQpDRlJHIEFnZW5kYQ0KSUVURiBJbnRlcmltLCBQYXJpcywgRnJhbmNl DQpBcHJpbCAzMCwgMjAxNyAgMTY6MDAtMTg6MDANClZlbnVlOiBVUE1DIENhbXB1cyBKdXNzaWV1 LCA0IHBsYWNlIEp1c3NpZXUsIDc1MDA1IFBhcmlzLCBGcmFuY2UNClJvb206IFRCQQ0KDQpDaGFp cnM6IEtlbm55IFBhdGVyc29uIGFuZCBBbGV4ZXkgTWVsbmlrb3YNCg0KMTY6MDAgQ0ZSRyBzdGF0 dXMgdXBkYXRlIGZyb20gQ0ZSRyBjaGFpcnMNCiAgICAgICgxMCBtaW5zOyBLZW5ueSBQYXRlcnNv bikNCg0KMTY6MTAgQXJnb24gMiB1cGRhdGUNCiAgICAgICgxNSsxMCBtaW5zOyBEbWl0cnkgS2hv dnJhdG92aWNoKQ0KDQoxNjozNSBQS0VYOiBBIFBhc3N3b3JkLUF1dGhlbnRpY2F0ZWQgUHVibGlj IEtleSBFeGNoYW5nZQ0KICAgICAgKDEwKzUgbWluczsgRGFuIEhhcmtpbnMpDQoNCjE2OjUwIENh ZXNhcidzIFJvbGUgaW4gdGhlIEZhbGwgb2YgQUUgU2VjdXJpdHkNCiAgICAgICgxNSsxMCBtaW5z OyBQb295YSBGYXJzaGltKQ0KDQoxNzoxNSBCSVAzMi1FZDI1NTE5DQogICAgICAoMTUrMTAgbWlu czsgRG1pdHJ5IEtob3ZyYXRvdmljaCkNCg0KMTc6NDAgT3BlbiBkaXNjdXNzaW9uDQoNCjE4OjAw IEZpbmlzaA0KDQoNCg0KDQoNCk9uIDIzLzAzLzIwMTcgMjM6MzgsICJQYXRlcnNvbiwgS2Vubnki IDxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPiB3cm90ZToNCg0KPkRlYXIgQ0ZSRywNCj4NCj5X ZSB3aWxsIGhhdmUgYSBtZWV0aW5nIG9mIENGUkcgYXQgRXVyb2NyeXB0IDIwMTcgaW4gUGFyaXMu IFRoZSBtZWV0aW5nDQo+d2lsbCBiZSBvbiBTdW5kYXkgMzB0aCBBcHJpbCBmcm9tIDRwbSB0byA2 cG0gKGxvY2FsIHRpbWUpLiBUaGUgbWVldGluZw0KPndpbGwgYmUgaGVsZCBhdCB0aGUgZm9sbG93 aW5nIGFkZHJlc3M6DQo+DQo+VVBNQyBDYW1wdXMgSnVzc2lldSwgNCBwbGFjZSBKdXNzaWV1LCA3 NTAwNSBQYXJpcywgRnJhbmNlDQo+DQo+DQo+VGhlIHByZWNpc2Ugcm9vbSB3aWxsIGJlIGFubm91 bmNlZCBjbG9zZXIgdG8gdGhlIGRhdGUgb2YgdGhlIGV2ZW50Lg0KPg0KPklmIHlvdSBwbGFuIHRv IGF0dGVuZCB0aGUgbWVldGluZywgeW91IG5lZWQgdG8gcmVnaXN0ZXIgdmlhOg0KPg0KPmh0dHBz Oi8vZXVyb2NyeXB0MjAxNy5kaS5lbnMuZnIvcmVnaXN0cmF0aW9uLmh0bWwNCj4NCj4NCj5Ob3Rl IHRoYXQ6DQo+DQo+MS4gVGhlcmUncyBhbiBvcHRpb24gb24gdGhlIHdlYnNpdGUgdG8gcmVnaXN0 ZXIgb25seSBmb3IgdGhlIHZhcmlvdXMNCj53b3Jrc2hvcHMgdGhhdCBhcmUgcnVubmluZyBpbiBw YXJhbGxlbCBvbiB0aGUgU3VuZGF5LCByYXRoZXIgdGhhbiBhbGwgb2YNCj50aGUgRXVyb2NyeXB0 IGNvbmZlcmVuY2UuIElmIHlvdSB3YW50IHRvIGF0dGVuZCBhbnkgb2YgdGhlIHdvcmtzaG9wcyBp bg0KPmFkZGl0aW9uIHRvIHRoZSBDRlJHIG1lZXRpbmcsIHlvdSBuZWVkIHRvIHBheSB0aGUgcmVn aXN0cmF0aW9uIGZlZSBvZg0KPlVTRCQ4MC4gWW91IGNhbiB0aGVuIGdvIHRvIGFueSBvZiB0aGUg U3VuZGF5IHdvcmtzaG9wcyBhcyB3ZWxsIGFzIHRoZSBDRlJHDQo+bWVldGluZyAtIGFuZCBpdCdz IGEgZ3JlYXQgbGlzdC4NCj4NCj4yLiBJZiB5b3UgcGxhbiB0byBPTkxZIGF0dGVuZCB0aGUgQ0ZS RyBtZWV0aW5nLCBhbmQgd2lsbCBub3QgYXR0ZW5kIGFueSBvZg0KPnRoZSBvdGhlciB3b3Jrc2hv cHMsIHRoZW4geW91IGRvIE5PVCBuZWVkIHRvIHJlZ2lzdGVyIG9ubGluZSBhbmQgcGF5IHRoZQ0K PmZlZSwgYnV0IHlvdSBNVVNUIGxldCBtZSBrbm93IGJ5IGUtbWFpbCB0aGF0IHlvdSBwbGFuIHRv IGF0dGVuZCBpbiB0aGlzDQo+d2F5LCBzbyB3ZSBjYW4ga2VlcCB0cmFjayBvZiBudW1iZXJzLiAo VGhlIG9yZ2FuaXNlcnMgaGF2ZSBraW5kbHkgYWdyZWVkDQo+dG8gd2FpdmUgdGhlIGZlZSBmb3Ig IkNGUkcgb25seSIgYXR0ZW5kZWVzLikNCj4NCj4zLiBUaGUgZWFybHkgYmlyZCByYXRlIGV4cGly ZXMgb24gTWFyY2ggMzFzdCwgc28gZ2V0IHJlZ2lzdGVyaW5nIQ0KPg0KPlBsZWFzZSBhbHNvIHNl bmQgbWUgYW5kIEFsZXhleSAob2ZmLWxpc3QpIHByb3Bvc2FsIGZvciB0YWxrcywgdG9waWNzIGZv cg0KPmRpc2N1c3Npb24gZXRjLiBXZSB3aWxsIGFubm91bmNlIGEgcHJvZ3JhbSBhcyBzb29uIGFz IHdlIGNhbi4NCj4NCj5NYW55IHRoYW5rcywNCj4NCj5LZW5ueSANCj4NCg0K From nobody Thu Apr 6 19:29:28 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 14F83128E19 for ; Thu, 6 Apr 2017 19:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sn-ByfuQeyC for ; Thu, 6 Apr 2017 19:29:25 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B2E12708C for ; Thu, 6 Apr 2017 19:29:23 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id g2so51453319pge.3 for ; Thu, 06 Apr 2017 19:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=am2EbZPqRAi04ZaRQXMjS1P7eSIEkMdu6RlpeNPNtlM=; b=NzdUq+OMWB5VuHnpQp6tvCkmW9M/5Ll9pelFOmcijOVtD7QzYQdi4sONJ4H0HVuih1 gvokV/wAZ4LhbYOonmJtdA+uKuX2rf82MPp90vNhz4M527sg8RfrUGY5ehqyHw+H4Tee iU/PBFiFp40ItSyXX/ul8hhGUcSpV1y7/9lntUlmhjcMpGBSzRCzPOnRW0PIMNTFpiQ7 ObxB9haYHO10Ht4iOQHjYXrjVRIT2LhAxqMr/4cw+nQy+CELP8z1KDk9Mzlg9CjYyGgj d5Quc5iV7Jxkp7/TEl1/nIAsFF7qBfL1CTpVS1qlhWMRHqrFL1SFJv37Y7rTcJF3GSlO h1Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=am2EbZPqRAi04ZaRQXMjS1P7eSIEkMdu6RlpeNPNtlM=; b=JI1obBuIcoCy1prEa1iPLrYJEytqtF0pC6x7ZDx2QB9Ap+DPC83SobyFrdio7xzIgf YdCC0/CvaGS+zaBVrn/xCxYoK7qJirZStRsV0fX5vtRpw2Vy00tKMhw3JhJHyfg1fhNW BO2E4HZP1xyy8TVX2ZG4faSEJizGN2X/lodrY5751U0gr46TiUJCtM2aQWxGGN3W2wkR 9wFyYZEVG7udAofkJj2245r140vad6wEWfVuPgWpVoZS8+CjKazwAB8BGEnvcLyitAZs OS8F2jnKsA7N2INIgFCtxd69eAQv8rdx89hextFo9smguqXSozzRi5tUV06fh2aW0d91 xnNQ== X-Gm-Message-State: AFeK/H21s+IQx7loogcw+P7vesffDCD5X9JDLH6UAeDDeVKN8Z1W0DHno5nwI8EGhvB/CA== X-Received: by 10.98.214.4 with SMTP id r4mr38771658pfg.185.1491532162912; Thu, 06 Apr 2017 19:29:22 -0700 (PDT) Received: from ?IPv6:2601:1c2:4f03:b950:7472:1d95:ea1f:52e3? ([2601:1c2:4f03:b950:7472:1d95:ea1f:52e3]) by smtp.gmail.com with ESMTPSA id u69sm5949654pfg.121.2017.04.06.19.29.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 19:29:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Anna (Amy) Johnston" X-Mailer: iPad Mail (14E304) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501B0AC3A@XMB116CNC.rim.net> Date: Thu, 6 Apr 2017 19:29:21 -0700 Cc: "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> <810C31990B57ED40B2062BA10D43FBF501B0AC3A@XMB116CNC.rim.net> To: Dan Brown Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 07 Apr 2017 02:29:27 -0000 Quick review, just so we're on the same page: Backdoored primes have hidden p= roperties that allow discrete logarithms to be more easily computed. This g= enerally implies a polynomial structure to the prime which enables a more ef= ficient sieve -- the special number field sieve (SNFS). All primes can be l= inked to a special number field sieve, but finding the correct relation is v= ery difficult (computationally infeasible) and some may not reduce computati= on as well as others. In other words no prime is guaranteed to be safe agai= nst the SNFS, intentionally backdoored or not. Number field sieves -- general, special or otherwise -- have three stages: s= ieve, solve (huge system of equations), and index calculus (find discrete lo= g). Once the sieve/solve steps have been completed, individual discrete log= arithms are fairly fast and anywhere the prime is being used is vulnerable. The SNFS only improves the sieve, it does not improve the linear algebra sta= ge. So if the linear algebra is becoming the time consumer (calendar wise, a= s the massive parallelism in the sieve means it spends a lot of compute time= but not as much calendar time), the SNFS will not be as large a concern. Anyone concerned about the SNFS, or any index calculus style attack, should b= e treating primes as cryptographic parameters with a fixed life time. Singl= e primes used across an entire network would be worth the expense of the sie= ves. Never changing the prime gives an attacker all the time in the world t= o break it, and once broken, they own it and everything protected with it. This is why I recommend against static primes of any kind. A. Johnston Sent from my iPad > On Apr 6, 2017, at 07:26, Dan Brown wrote: >=20 > Good points! Responses inline below (between <<< >>> sorry if that's awkw= ard.) >=20 > -----Original Message----- > From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Anna (Amy) Johnston= >=20 > With a prime like this (and with the knowledge that q is prime), a better w= ay (non-probabilistic) is to use Pocklington's theorem. Two exponentiations= with the right base and you've proved primality. q can also be checked for= primality with Pocklington's, but it takes a larger number of much smaller e= xponentiations. >=20 > <<< > Sounds right. Primality proofs are good checks before deployment. I felt= they were not needed to tentatively discuss the merits. >>>>=20 >=20 > The SNFS reduces the computation cost of the sieve, but as larger base fie= lds become the norm (at least 2048 bits), the linear algebra, not the sieve w= ill be the problem (see iacr e-print 2017/067, page 8, as well as other disc= rete logarithm records in the past -- all shift work away from the linear al= gebra to the sieve). This means that back doors are not as big a concern. >=20 > <<<=20 > I was extrapolating (too much?) from Fried et al. ia.cr/2016/961, especial= ly this from the Section 6.3 Lessons: >=20 > "Both from this perspective, and from our more modern one, dismissing > the risk of trapdoored primes in real usage appears to have been a mistake= , as > the apparent difficulties encountered by the trapdoor designer in 1992 tur= n out > to be easily circumvented." >=20 > My extrapolation is that for even for very large keysizes, let's not dismi= ss the possibility of a trapdoor, so let's use some kind of additional count= ermeasure. I'm not alone in this, since other fixed DH prime in IETF RFCs a= re derived from pi, etc. I agree that it may, in the end, be overly cautious= , but it seems to have little cost.=20 >>>>=20 >=20 > If sieving attacks are the main concern, then regularly changing the prim= es used would be a bigger boost to security. Fixed primes, uses everywhere,= mean that the huge cost of the sieve and solving the system of equations ha= ve an even bigger payoff. Changing primes regularly minimizes an attackers g= ain from any possible sieve attack -- SNFS, more general, or other index cal= culus attacks which may be developed.=20 >=20 > <<<=20 > Yes, you're essentially right about variable primes. I totally forgot to c= ompare to them. Prime 630*(427!+1)+1 should only be compared to other fixed= DH primes. At the moment, I don't remember the usual tradeoffs between fixe= d and variable classic DH primes ..., but I recall that some like fixed DH p= rimes.=20 >=20 > Hmm, I think variable DH primes compare less favorably to 630*(427!+1)+1 o= n the issue of the den Boer reduction. I rather like the original den Boer r= eduction between DHP and DLP, and nearly optimizing it forces one to a speci= al prime, which might as well (???) be fixed. I do realize that there are r= easonable alternatives to den Boer. Most simply, just assume that DHP hard.= Use a Maurer-Wolf reduction, or rely on Boneh-Lipton's results about the c= onjectural existence of such reductions. I just see the den Boer reduction a= s simpler, but maybe that's being too sentimental. >=20 > Side joke: for those that really like to see vitanums pi and e in their pr= imes (not to mention sqrt(2)), look up Stirling's formula to find them in 63= 0*(427!+1)+1. >>>>=20 From nobody Thu Apr 6 20:13:29 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A99129495 for ; Thu, 6 Apr 2017 20:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZcKzeniL6KY for ; Thu, 6 Apr 2017 20:13:26 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD6B129446 for ; Thu, 6 Apr 2017 20:13:25 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id x125so53217436pgb.0 for ; Thu, 06 Apr 2017 20:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3e/pQyxrwNDwzlP1/pH9Wnpx5Lv92jva2hHNol6BT7Y=; b=lqvqXya7ndDlMoQ9gwT0qwxa1dQ4d90g5mklXCkrXkA2uKKNvBqTQh/HTWuX6e4NOv /KUd0g04LHMDg+Nc700/uNEc+vItqxjg9YdRPlkYkjUS/SSXN0hGTiRCZdPDjrhLmJcG io8OB+cS74BZbBbeCOg29yic0LKshTsZphI1rImbtKLpz4bMb0mulQQ3w5WgrQMDWdGP R1t3kIx7yzMdMMl66Qb8WBQz/2ibiwvG5pRNCvh9iSrSZXwHMC8SvnzavaAME6CMlec3 B1VFWHtkwqvLhMxDBtd6Ullf5VphfCsFHwfrrYBsYNXTfTcd3Hg0tiix4Fdvf0Z219vU aWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3e/pQyxrwNDwzlP1/pH9Wnpx5Lv92jva2hHNol6BT7Y=; b=f6Ly4HF84ARVjHLZGy3/bKZGMxJROa5p1h93P4TrGNMnhDjxkd4vZbUDnp9/saIUGv uQVDPYcAVaH6VYN/GHrgFiwlKbg4/c2KNQl5eQXPVsrEwl5oZD2fsz0xrLNbjEbOIKWE nlFvHSZp91PFD2YA49jbfPGKzEMnr0cC5S1+DjsUMNmLP0kskFMQUJfWkTNfHneQ9QfL v55PdQ6d6Hiq9xxO7Vq28jVoqfJ5DfuqGaAZzk0DHVRcthgnEmZHyImU/qyobEbPgozO ycYSP+0nCilG1haQ8ZMitUaJFa46i4XbhtPMXWoOEHuVpClyyzm3sBnFxcFFTf8yjDdi CB7A== X-Gm-Message-State: AFeK/H0h/Tzh+J4zqPQaR+Zh07ShbARaE0XKdJLtxGdulQEd+IVbgecKPItMhmBlXD4GaUvQmftYIFJmx3WWjA== X-Received: by 10.98.17.20 with SMTP id z20mr39344167pfi.67.1491534805323; Thu, 06 Apr 2017 20:13:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Thu, 6 Apr 2017 20:13:24 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B0A7E2@XMB116CNC.rim.net> <88898D32-CFF0-4043-BA88-9849031069E2@seer-grog.net> <7626A54F-BE87-4E68-B0F9-54CD878B4A87@juniper.net> <91D64FF1-D997-42FB-90CE-3B1422584974@juniper.net> <810C31990B57ED40B2062BA10D43FBF501B0AC3A@XMB116CNC.rim.net> From: Watson Ladd Date: Thu, 6 Apr 2017 20:13:24 -0700 Message-ID: To: "Anna (Amy) Johnston" Cc: Dan Brown , "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cfrg] Prime 630*(427!+1)+1 for classic DH? 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, 07 Apr 2017 03:13:28 -0000 On Thu, Apr 6, 2017 at 7:29 PM, Anna (Amy) Johnston w= rote: > Quick review, just so we're on the same page: Backdoored primes have hidd= en properties that allow discrete logarithms to be more easily computed. T= his generally implies a polynomial structure to the prime which enables a m= ore efficient sieve -- the special number field sieve (SNFS). All primes c= an be linked to a special number field sieve, but finding the correct relat= ion is very difficult (computationally infeasible) and some may not reduce = computation as well as others. In other words no prime is guaranteed to be= safe against the SNFS, intentionally backdoored or not. > > Number field sieves -- general, special or otherwise -- have three stages= : sieve, solve (huge system of equations), and index calculus (find discret= e log). Once the sieve/solve steps have been completed, individual discret= e logarithms are fairly fast and anywhere the prime is being used is vulner= able. > > The SNFS only improves the sieve, it does not improve the linear algebra = stage. So if the linear algebra is becoming the time consumer (calendar wi= se, as the massive parallelism in the sieve means it spends a lot of comput= e time but not as much calendar time), the SNFS will not be as large a conc= ern. Smart attackers tune the relative complexities of the two stages to optimize for attack cost. If you can sieve faster, you can sieve harder to save time in the linear algebra step. This depends crucially on interconnect speed, resources, etc. They also balance the precomputation time against the time to find a particular discrete logarithm. The gains from cheapening an already cheap step depend on the new tradeoffs that enables. > Anyone concerned about the SNFS, or any index calculus style attack, shou= ld be treating primes as cryptographic parameters with a fixed life time. = Single primes used across an entire network would be worth the expense of t= he sieves. Never changing the prime gives an attacker all the time in the = world to break it, and once broken, they own it and everything protected wi= th it. The GNFS parallelizes across primes as well. Furthermore, using supplied primes by each side has lead to security vulnerabilities in TLS. These were avoidable, but show that there is no panacea. However, no attacker will ever conduct a calculation of size 2^256. The way to avoid them computing every key is to make sure that they cannot even compute 1 key. > > This is why I recommend against static primes of any kind. > > A. Johnston > > Sent from my iPad > >> On Apr 6, 2017, at 07:26, Dan Brown wrote: >> >> Good points! Responses inline below (between <<< >>> sorry if that's aw= kward.) >> >> -----Original Message----- >> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Anna (Amy) Johnst= on >> >> With a prime like this (and with the knowledge that q is prime), a bette= r way (non-probabilistic) is to use Pocklington's theorem. Two exponentiat= ions with the right base and you've proved primality. q can also be checke= d for primality with Pocklington's, but it takes a larger number of much sm= aller exponentiations. >> >> <<< >> Sounds right. Primality proofs are good checks before deployment. I fe= lt they were not needed to tentatively discuss the merits. >>>>> >> >> The SNFS reduces the computation cost of the sieve, but as larger base f= ields become the norm (at least 2048 bits), the linear algebra, not the sie= ve will be the problem (see iacr e-print 2017/067, page 8, as well as other= discrete logarithm records in the past -- all shift work away from the lin= ear algebra to the sieve). This means that back doors are not as big a con= cern. >> >> <<< >> I was extrapolating (too much?) from Fried et al. ia.cr/2016/961, especi= ally this from the Section 6.3 Lessons: >> >> "Both from this perspective, and from our more modern one, dismissing >> the risk of trapdoored primes in real usage appears to have been a mista= ke, as >> the apparent difficulties encountered by the trapdoor designer in 1992 t= urn out >> to be easily circumvented." >> >> My extrapolation is that for even for very large keysizes, let's not dis= miss the possibility of a trapdoor, so let's use some kind of additional co= untermeasure. I'm not alone in this, since other fixed DH prime in IETF RF= Cs are derived from pi, etc. I agree that it may, in the end, be overly cau= tious, but it seems to have little cost. >>>>> >> >> If sieving attacks are the main concern, then regularly changing the pr= imes used would be a bigger boost to security. Fixed primes, uses everywhe= re, mean that the huge cost of the sieve and solving the system of equation= s have an even bigger payoff. Changing primes regularly minimizes an attac= kers gain from any possible sieve attack -- SNFS, more general, or other in= dex calculus attacks which may be developed. >> >> <<< >> Yes, you're essentially right about variable primes. I totally forgot to= compare to them. Prime 630*(427!+1)+1 should only be compared to other fi= xed DH primes. At the moment, I don't remember the usual tradeoffs between = fixed and variable classic DH primes ..., but I recall that some like fixed= DH primes. >> >> Hmm, I think variable DH primes compare less favorably to 630*(427!+1)+1= on the issue of the den Boer reduction. I rather like the original den Bo= er reduction between DHP and DLP, and nearly optimizing it forces one to a = special prime, which might as well (???) be fixed. I do realize that there= are reasonable alternatives to den Boer. Most simply, just assume that DH= P hard. Use a Maurer-Wolf reduction, or rely on Boneh-Lipton's results abo= ut the conjectural existence of such reductions. I just see the den Boer r= eduction as simpler, but maybe that's being too sentimental. >> >> Side joke: for those that really like to see vitanums pi and e in their = primes (not to mention sqrt(2)), look up Stirling's formula to find them in= 630*(427!+1)+1. >>>>> > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Apr 6 22:42:48 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 3F0821267BB for ; Thu, 6 Apr 2017 22:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO6H7PKOwlrT for ; Thu, 6 Apr 2017 22:42:41 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0433126DD9 for ; Thu, 6 Apr 2017 22:42:40 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id c45so11538249qtb.1 for ; Thu, 06 Apr 2017 22:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DeWVhlPsgblZOPNdoXZXMTIVbK++gaTsQ1ejvF3ggV8=; b=MbERItYYRz/G301qDaOfbnKB3fJERjVY9usw7IWkQbNImlbyP6Tx+2Di35V/6Y+Dlg GWtsPWIDwhtiqdzLGfnF9l2n1vI848HKUlHlZW5NMy+LgvoRkVI9vT0Pg+OsebyZODO4 3d245nCG8zZ51rKXD8ehFLxTXYVLaoYZypUkwo4iZ6hPtP6Fwcjse9liFckTMV4af1JH k5PX2ljsKKPUhVhbIOaBf+heXmJq1D/TjEfIl/gCoDVUbX2OTeX/xtST/rv0UvJNZOGy 2YTZWnDNKveseRKeh7BF0u6HPHXo4LTuvqhEbUVxKM5rFdjtz3uQGvWURDMZj11jV0M0 upYw== 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=DeWVhlPsgblZOPNdoXZXMTIVbK++gaTsQ1ejvF3ggV8=; b=uAy0Id8G4Qu08HjhPVneS4i6OukF0BqOSwmYtHOyTmBZOiDEbKaJeI4qGnQBKume37 SmA7iqal/Jackluiw1KQS52qwXQT0oPKbo0ml95KaD3QxUBWdsSBxKYLIPQYzqjnZC2q tPvtdpgwU6/iNFXmlxYcvurnXJGOs0K4/YhA2TeHULxDJIaMl4M7D3J0N17nHxcr8VS3 NjLSuPAi30QKrPLcHFBUHfoaA805+GYvvG295d7XCBG66hhXVvP7EdQ9RC0zCZsImNck kF3KjmXNHlC9Ta7uoUyYEiwtgkGTTjWeo2UNrWrZ0Omc3VZH5MRwn/JxCSaP6/DXA73f t+fA== X-Gm-Message-State: AFeK/H29UjvnqmCbsY8LPqcAaEheO3hiHuo9cB9glIdGrd4eNHM/DFzo6zuQ0JDiOD0bm5OKaEWDJG/OQlmOxQ== X-Received: by 10.200.54.207 with SMTP id b15mr43386225qtc.9.1491543759753; Thu, 06 Apr 2017 22:42:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.4 with HTTP; Thu, 6 Apr 2017 22:42:39 -0700 (PDT) In-Reply-To: References: <58D6A719.1070807@isode.com> From: "Stanislav V. Smyshlyaev" Date: Fri, 7 Apr 2017 08:42:39 +0300 Message-ID: To: "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a1139782af7990d054c8d1793 Archived-At: Subject: Re: [Cfrg] CFRG side meeting on re-keying in Chicago 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, 07 Apr 2017 05:42:45 -0000 --001a1139782af7990d054c8d1793 Content-Type: text/plain; charset=UTF-8 Dear colleagues, Sending you a follow-up of our CFRG side meeting at IETF 98, on Thursday, the 30-th of March, dedicated to the process of development of a CFRG document on re-keying (draft-irtf-cfrg-re-keying ). The current version of the document is draft-irtf-cfrg-re-keying-01 , it addresses some first concerns, but is still at quite an early stage, a large number of new comments and proposals have been received, so the discussion was needed - and it was the aim of the CFRG side meeting in Chicago at IETF 98. The following members of CFRG participated in the meeting: Scott Fluhrer, Sean Leonard (part of the meeting), Yoav Nir, Paul Hoffman, Quynh Dang, Dorothy Cooley, Alexey Melnikov (part of the meeting), Jim Schaad, Daniel Fox Franke, Russ Housley, Maksim Kollegin, Stanislav Smyshlyaev. The received considerations were divided into three parts: 1) issues of the scope and aims of re-keying, declared in the document; 2) recommendations and guidelines in the document for choosing certain mechanisms for designed protocols and solutions; 3) mechanisms themselves: a list of defined mechanisms and issues of their descriptions. 1) The scope and aims were defined according to the comments of Scott Fluhrer, Evgeny Alekseev and Russ Housley: a) additional side channel resistance (against DPA or EMI style attacks); b) PFS security regarding segments of encryption process; c) lightweight cryptography, usage of ciphers with 32-bit and 64-bit blocks, (additional issues due to combinatorial problems - bithday paradox on outputs of basic block cipher permutation); d) additional security against possible future attacks on the used ciphers (by limiting the volume of plaintext-ciphertext pairs collected by and adversary) - as a safety margin. Important notice: This MUST NOT be used as a method to prolongate life of ciphers that are already known to be vulnerable. There also was a discussion on possible connection with post-quantum security (Paul Hoffman, Scott Fluhrer, Stanislav Smyshlyaev): Question: Can some post-quantum security issues for symmetric crypto (i.e. related to Grover's algorithm) solved by re-keying? Answer: No, since the reduction of security caused by Grover's algorithm is not connected with a size of plaintext transformed by a cipher - only a negligible (sufficient for key uniqueness) material is needed for Grover's algorithm - and the aim of re-keying is to limit a size of plaintext transformed on one key. Question: Which reasons remain when we are treating block ciphers with large block sizes, e.g. ChaCha20? Answer: The combinatorial problems become unimportant, but all other remain: side-channel resistance, PFS, security margin. 2) The proposal of Russ Housley (accepted at the meeting): to base the text of recommendations in the document for choice of a re-keying technique (external/internal) on the following frame: external re-keying is chosen on a protocol level independently of a block cipher and a block cipher mode, while an internal re-keying is chosen linked to a block size (of a used cipher) and block cipher mode of operation. The proposal of Daniel Franke (accepted at the meeting): to add a text about advantages and disadvantages of various types of re-keying based on Seoul CFRG (IETF 97) slides. The proposal of Dmitry Belyavsky and Daniel Franke (accepted at the meeting): to provide sample cases (working examples or toy examples) for choosing one or another type of re-keying for the protocols. The question is not about test vectors (though they also must be added to the document), but about illustrating guidelines on choosing re-keying variants for end protocols. Question: Which examples should we choose? Answer: For external serial mechanisms a great working example of TLS 1.3 Key Update exists. For other mechanisms the question must be considered. Question: Should we change the order of chapters such that the main part of recommendations would be given before the description of specific mechanisms. Answer: Yes, otherwise now the document has to be read starting from the end. Question: Should we consider related questions for stream ciphers? Answer: No. Only for block ciphers in various modes (including counter mode, of course). 3) The proposal based on considerations of Maksim Kollegin (accepted at the meeting): to add explicit text about the principles of choice of constants for internal re-keying CTR mode (preventing collisions of blocks of transformed key and block cipher permutation inputs). The proposal of Dorothy Cooley (accepted at the meeting): to write, what ACPKM stands for. The proposal based on considerations of Russ Housley (accepted at the meeting): to add clarifications about advantages and disadvantages of usage of the same primitives for re-keying: if we use different primitives, we separate keys used for data encryption and for supplementary operations (which can be important to prevent leaking data protection keys through additional APIs, e.g. in HSMs), on the other hand, it allows not to add additional circuits/subroutines in implementations (and use the same primitive implementations for all processes). The proposal of Daniel Franke (accepted at the meeting): when choosing constants for internal re-keying, consider only lengths that are multiples of 8. In this case we can cardinally simplify the methods of constructing constants. Question: Which principles should we use when choosing the exact constructions? Answer: For each type we should choose one, not more. The current number of construction is OK, but some could be changed, e.g. the external block cipher based one. HKDF for external hash-based is OK. Question: Which KDF, based on the block ciphers, should be chosen? Answer: Regarding the security issues, they are quite similar, thus in the current draft the primitives from the paper of Abdalla and Bellare are described. The question to consider remains: should we change it for something else (e.g. for some standardized primitive)? Question: Shay Gueron suggested adding the DeriveKey construction from the AES-GCM-SIV paper. Should we? Answer: For now we don't see the arguments for this option. A fruitful discussion about the modes for internal re-keying took place, the final answer is based on the considerations of Scott Fluhrer, Yoav Nir, Jim Schaad, Daniel Franke, Dorothy Cooley and Russ Housley. Question: Should we leave internal constructions for all modes (including CBC, CFB, etc.) or only for CTR and GCM? Answer: We are writing the paper for the future protocols, not for the existing, so let's consider primarily CTR and GCM - and also add CCM. CBC is widely used, so we cannot ignore it, but maybe it's better be done as a separate comment, not as a separate definition of a construction. For internal modes with a master key a construction is not so linked to a specific mode (cf. internal ACPKM constructions without master key for CTR/GCM), so it won't be too difficult. The work on the document will be continued according to the decisions made during the discussion. Best regards, Stanislav V. Smyshlyaev, Ph.D., Head of Information Security Department, CryptoPro LLC 2017-03-29 23:47 GMT+03:00 Stanislav V. Smyshlyaev : > Dear IETF 98 attendees, > > Just a reminder that tomorrow (Thursday, 30th of March) at 10:30 we'll > have a CFRG side meeting in Bianco room (3rd floor, IESG Breakout room). > > Please come if you have any considerations or thoughts about the topic of > re-keying/key update/KDFs etc. The CFRG document on re-keying is at quite > early stage currently, all your opinions and proposals are highly wanted. > > The current version of the document is the following: https:// > datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-01. > > Best regards, > Stanislav Smyshlyaev > > > 2017-03-25 20:21 GMT+03:00 Alexey Melnikov : > >> Dear CRFG participants, >> While CFRG is not meeting in Chicago, there will be a 1 hour design-type >> meeting to talk about re-keying. Below is information about this meeting: >> >> When: On Thursday, March 30th, 10:30am-11:30am >> >> Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG >> Breakout Room. >> >> >> Should the re-keying discussion finish early, other CFRG related topics >> may be discussed. If you have a topic, please reply to this email or to >> me directly. >> >> Thank you, >> Alexey, as a CFRG co-chair. >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > --001a1139782af7990d054c8d1793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear colleagues,
=C2=A0
Send= ing you a follow-up of our CFRG side meeting at IETF 98, on Thursday, the 3= 0-th of March, dedicated to the process of development of a CFRG document o= n re-keying (draft-irtf-cfrg-re-keying).
=C2=A0=C2=A0
= The current version of the document is=C2=A0draft-irtf-cfrg-re-keying-01, it = addresses some first concerns, but is still at quite an early stage, a larg= e number of new comments and proposals have been received, so the discussio= n was needed - and it was the aim of the CFRG side meeting in Chicago at IE= TF 98.
=C2=A0
The following members of CFRG participate= d in the meeting: Scott Fluhrer, Sean Leonard (part of the meeting), Yoav N= ir, Paul Hoffman, Quynh Dang, Dorothy Cooley, Alexey Melnikov (part of the = meeting), Jim Schaad, Daniel Fox Franke, Russ Housley, Maksim Kollegin, Sta= nislav Smyshlyaev.
=C2=A0
The received considerations w= ere divided into three parts:
1) issues of the scope and aims of = re-keying, declared in the document;
2) recommendations and guide= lines in the document for choosing certain mechanisms for designed protocol= s and solutions;
3) mechanisms themselves: a list of defined mech= anisms and issues of their descriptions.
=C2=A0
=C2=A0<= /div>
1)
=C2=A0
The scope and aims were defined acc= ording to the comments of Scott Fluhrer, Evgeny Alekseev and Russ Housley:<= /div>
a) additional side channel resistance (against DPA or EMI style a= ttacks);
b) PFS security regarding segments of encryption process= ;
c) lightweight cryptography, usage of ciphers with 32-bit and 6= 4-bit blocks, (additional issues due to combinatorial problems - bithday pa= radox on outputs of basic block cipher permutation);
d) additiona= l security against possible future attacks on the used ciphers (by limiting= the volume of plaintext-ciphertext pairs collected by and adversary) - as = a safety margin. Important notice: This MUST NOT be used as a method to pro= longate life of ciphers that are already known to be vulnerable.
= =C2=A0
There also was a discussion on possible connection with po= st-quantum security (Paul Hoffman, Scott Fluhrer, Stanislav Smyshlyaev):
Question: Can some post-quantum security issues =C2=A0for symmetric= crypto (i.e. related to Grover's algorithm) solved by re-keying?
=
Answer: No, since the reduction of security caused by Grover's alg= orithm is not connected with a size of plaintext transformed by a cipher - = only a negligible (sufficient for key uniqueness) material is needed for Gr= over's algorithm - and the aim of re-keying is to limit a size of plain= text transformed on one key.
=C2=A0
Question: Which rea= sons remain when we are treating block ciphers with large block sizes, e.g.= ChaCha20?
Answer: The combinatorial problems become unimportant,= but all other remain: side-channel resistance, PFS, security margin.
=
=C2=A0
2)
=C2=A0
The proposal of Russ Ho= usley (accepted at the meeting): to base the text of recommendations in the= document for choice of a re-keying technique (external/internal) on the fo= llowing frame: external re-keying is chosen on a protocol level independent= ly of a block cipher and a block cipher mode, while an internal re-keying i= s chosen linked to a block size (of a used cipher) and block cipher mode of= operation.
=C2=A0
The proposal of Daniel Franke (accep= ted at the meeting): to add a text about advantages and disadvantages of va= rious types of re-keying based on Seoul CFRG (IETF 97) slides.
= =C2=A0
The proposal of Dmitry Belyavsky and Daniel Franke (accept= ed at the meeting): to provide sample cases (working examples or toy exampl= es) for choosing one or another type of re-keying for the protocols. The qu= estion is not about test vectors (though they also must be added to the doc= ument), but about illustrating guidelines on choosing re-keying variants fo= r end protocols.
=C2=A0
Question: Which examples should= we choose?
Answer: For external serial mechanisms a great workin= g example of TLS 1.3 Key Update exists. For other mechanisms the question m= ust be considered.
=C2=A0
Question: Should we change th= e order of chapters such that the main part of recommendations would be giv= en before the description of specific mechanisms.
Answer: Yes, ot= herwise now the document has to be read starting from the end.
= =C2=A0
Question: Should we consider related questions for stream = ciphers?
Answer: No. Only for block ciphers in various modes (inc= luding counter mode, of course).
=C2=A0
3)
= =C2=A0
The proposal based on considerations of Maksim Kollegin (a= ccepted at the meeting): to add explicit text about the principles of choic= e of constants for internal re-keying CTR mode (preventing collisions of bl= ocks of transformed key and block cipher permutation inputs).
=C2= =A0
The proposal of Dorothy Cooley (accepted at the meeting): to = write, what ACPKM stands for.
=C2=A0
The proposal based= on considerations of Russ Housley (accepted at the meeting): to add clarif= ications about advantages and disadvantages of usage of the same primitives= for re-keying: if we use different primitives, we separate keys used for d= ata encryption and for supplementary operations (which can be important to = prevent leaking data protection keys through additional APIs, e.g. in HSMs)= , on the other hand, it allows not to add additional circuits/subroutines i= n implementations (and use the same primitive implementations for all proce= sses).
=C2=A0
The proposal of Daniel Franke (accepted a= t the meeting): when choosing constants for internal re-keying, consider on= ly lengths that are multiples of 8. In this case we can cardinally simplify= the methods of constructing constants.
=C2=A0
Question= : Which principles should we use when choosing the exact constructions?
Answer: For each type we should choose one, not more. The current nu= mber of construction is OK, but some could be changed, e.g. the external bl= ock cipher based one. HKDF for external hash-based is OK.
=C2=A0<= /div>
Question: Which KDF, based on the block ciphers, should be chosen= ?=C2=A0
Answer: Regarding the security issues, they are quite sim= ilar, thus in the current draft the primitives from the paper of Abdalla an= d Bellare are described. The question to consider remains: should we change= it for something else (e.g. for some standardized primitive)?
= =C2=A0
Question: Shay Gueron suggested adding the DeriveKey const= ruction from the AES-GCM-SIV paper. Should we?
Answer: For now we= don't see the arguments for this option.
=C2=A0
A = fruitful discussion about the modes for internal re-keying took place, the = final answer is based on the considerations of Scott Fluhrer, Yoav Nir, Jim= Schaad, Daniel Franke, Dorothy Cooley and Russ Housley.
Question= : Should we leave internal constructions for all modes (including CBC, CFB,= etc.) or only for CTR and GCM?
Answer: We are writing the paper = for the future protocols, not for the existing, so let's consider prima= rily CTR and GCM - and also add CCM. CBC is widely used, so we cannot ignor= e it, but maybe it's better be done as a separate comment, not as a sep= arate definition of a construction. For internal modes with a master key a = construction is not so linked to a specific mode (cf. internal ACPKM constr= uctions without master key for CTR/GCM), so it won't be too difficult.<= /div>
=C2=A0=C2=A0
The work on the document will be continued= according to the decisions made during the discussion.

=C2=A0
Best regards,
Stanislav V. Smyshlyaev, Ph.= D.,
Head of Information Security Department,
CryptoPro = LLC
=C2=A0


2017-03-29 23:47 GMT+03:00 Stanislav V. Smys= hlyaev <smyshsv@gmail.com>:
Dear IETF 98 attendees,=C2=A0
Just a reminder that tomorrow (Thursday, 30th of March) at 10:3= 0 we'll have a CFRG side meeting in Bianco room (3rd floor, IESG Breako= ut room).=C2=A0

Please come if you have any consid= erations or thoughts about the topic of re-keying/key update/KDFs etc. The = CFRG document on re-keying is at quite early stage currently, all your opin= ions and proposals are highly wanted.

The current = version of the document is the following:=C2=A0https:= //datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-01.=

Best regards,
Stanislav Smyshlyaev


2017-03-25 20:21 GMT+03:00 Alexey Melnikov <= span dir=3D"ltr"><alexey.melnikov@isode.com>:
Dear CRFG participants,
While CFRG is not meeting in Chicago, there will be a 1 hour design-type meeting to talk about re-keying. Below is information about this meeting:
When: On Thursday, March 30th, 10:30am-11:30am

Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG
Breakout Room.


Should the re-keying discussion finish early, other CFRG related topics
may be discussed. If you have a topic, please reply to this email or to
me directly.

Thank you,
Alexey, as a CFRG co-chair.



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


--001a1139782af7990d054c8d1793-- From nobody Fri Apr 14 16:06:05 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32079129B1E for ; Fri, 14 Apr 2017 16:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmsTCt4K51XV for ; Fri, 14 Apr 2017 16:06:02 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860B3129B19 for ; Fri, 14 Apr 2017 16:06:02 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 21so48465741pgg.1 for ; Fri, 14 Apr 2017 16:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=kVK3BZorFgXRRYMCI2NTS6e0Mbt9iNrGhC0Gsi/+Zno=; b=ZhtNjwAvXAIG15RYkraArgPx/U5rSu47c5vYT1Sc5wKQAe5LP6+QfiOavFV0VnCr8H aOE/UxO/7rUdDlfNbBA37nCwzzlY1xz48jCLpJoregpdLIHHF2XKpyWBE7QaI0wwz6SD 8HGnbKMvat30B7+KXI/PTBFCkQEpu7JYseKw6AIg8pb2CrqxFPTTHw/e8FQ2xpTupWI+ WsMjjXCsJJzmdsVGySVugtuaMMYUb5I0Fd7F96G/Eg2JYATJdcSCOS9Dt03ambl1tRqb PwRhzglM20lWOV1zz3JbHPgct5ZaJBjdKS3em1ZkZaD+AeaKBxlwH04w5IgE6HrOFQDV GsYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=kVK3BZorFgXRRYMCI2NTS6e0Mbt9iNrGhC0Gsi/+Zno=; b=LF2dNQ7Qel0GMK8tOFSDP2bv8YZtADHRVU2XSjmkGRP9003AMNqg9Gnj8/zcyDFeLn 5nzcHXpEZ2sMtQM3VbovE2EqUED8Jf4dykxMVuOZR9rsk22UhFjCsM0c4xRWYJ7+dUta iHCpUImv8VRgBH6K7DqdGuqr749z8VcX9Vd78A86gJx08oJCDzzUdoChl8eWYFq3B9yz MvQkf1HkCk6lPE2N9Mk0A6p7OaWCzIYY68D3pV6VtqqeF8BKi/wDsjQNh3J6yn7NyCsO AXahYdt+5dxpglRA93j0O5qrUMnMR3FYT98O0YhccvpMpXbs1bitaDzhshG1z9W6N23T RM0A== X-Gm-Message-State: AN3rC/7buhclUWXSBRFRjJI9Ek1iCaQ6vMt2Tne4ImyDk7F4OHf4hc4O qdqLVGkR35yWvB/aMSg= X-Received: by 10.84.225.129 with SMTP id u1mr11655749plj.123.1492211161321; Fri, 14 Apr 2017 16:06:01 -0700 (PDT) Received: from [192.168.1.126] ([52.119.113.96]) by smtp.gmail.com with ESMTPSA id k88sm5004701pfj.79.2017.04.14.16.06.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 16:06:00 -0700 (PDT) From: Oleg Andreev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 14 Apr 2017 16:05:59 -0700 To: cfrg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cfrg] Revised ChainKD: BIP32 adaptation to Ed25519 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, 14 Apr 2017 23:06:04 -0000 Hello, I would like to present a revised version ChainKD: a deterministic = hierarchical=20 key derivation scheme for Ed25519 inspired by BIP32 [1]. This a result = of ongoing discussion on CFRG list [2,3], Curves list at moderncrypto.org [4,5] and = Tor-dev list [6]. ChainKD is now a concrete proposal, with specification and a working = code,=20 ready to be evaluated as a candidate for becoming an industry standard. Specification & rationale: = https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specification= s/chainkd.md Implementation in Go: = https://github.com/chain/chain/blob/chainkd-dh/crypto/ed25519/chainkd/chai= nkd.go Pull-request & discussion: https://github.com/chain/chain/pull/844/ You will find the description of functionality, rationale and tradeoffs = in the spec (first link above), here I will only highlight some _differences_ with = other=20 schemes and proposals: ChainKD vs BIP32: 1. BIP32 is defined for curve secp256k1, and fairly easily applied to = cofactor=3D1 curves, while ChainKD is designed specifically for Ed25519 having cofactor 8. 2. Derivation index in BIP32 is a 31-bit integer, in ChainKD it is a = binary string. 3. BIP32 proposes a serialization format with metadata and checksums, = ChainKD delegates it to other specifications and uses raw hex representation. ChainKD vs BIP32-Ed25519 (BE for brevity) [7]: 1. Like in BIP32, BE uses 31 integers as derivation indices, ChainKD = allows binary strings. 2. BE extended private key is 96-byte structure with 3 fields, ChainKD = is similar to BIP32=20 having 2-field 64-byte structure. 3. BE has a slightly higher child key collision probability due to a = slightly simpler bit-clearing rule for the child scalars. ChainKD saves 6 bits. I will = note, though, that entropy in all private keys is the same 250 bits in both = schemes. ChainKD vs Tor proposal 224 [8]: 1. ChainKD, like BIP32 uses scalar addition to derive child scalars, = while prop224 uses scalar multiplication.=20 2. Tor's prop224 does not include considerations for hardened derivation = (from the=20 private key only). 3. Tor's prop224 is not concerned with non-signature usage and does = attempt to be compatible with EdDSA [6]. ChainKD strives for compatibility with = EdDSA and DH uses. 4. Note: I'm still in the process of figuring out Tor's requirements to = figure out if the ChainKD satisfies them or not. Result of this investigation = may affect=20 some aspects of the ChainKD design in the near future. Would love to hear more thoughts on this. I imagine there are many more = fine details=20 and considerations to discuss, including, of course, potential bugs and security issues with our design. Thank you! PS. I would like to thank Tony Arcieri, Dmitry Khovratovich, Jason Law, = Gregory Maxwell,=20 Pieter Wuille, Henry de Valence, Mike Hamburg, Trevor Perrin, Taylor R. = Campbell=20 and others for the hugely valuable feedback, suggestions and = explanations. [1] BIP32: = https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [2] CFRG thread 1: = https://www.ietf.org/mail-archive/web/cfrg/current/msg09077.html [3] CFRG thread 2: = https://www.ietf.org/mail-archive/web/cfrg/current/msg09110.html [4] Curves thread 1: = https://moderncrypto.org/mail-archive/curves/2017/000858.html [5] Curves thread 2: = https://moderncrypto.org/mail-archive/curves/2017/000866.html [6] Tor-dev thread: = https://lists.torproject.org/pipermail/tor-dev/2017-April/012204.html [7] BIP32-Ed25519: = https://drive.google.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA [8] Tor prop224 (see KEYBLIND): = https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.= txt =20= From nobody Tue Apr 18 06:45:10 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4615D129481; Tue, 18 Apr 2017 06:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: alexey.melnikov@isode.com, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149252310621.16084.11114354340235265581.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 06:45:06 -0700 Archived-At: Subject: [Cfrg] cfrg - New Meeting Session Request for IETF 99 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:45:06 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the cfrg working group. --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: kitten tcpinc uta dispatch dprive tls saag dmarc Second Priority: jmap mile People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: Please generally avoid conflicts with SEC Area WGs/BOFs --------------------------------------------------------- From nobody Tue Apr 18 08:13:06 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7F8126B7F for ; Tue, 18 Apr 2017 08:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 HbNJJ5NLNYYQ for ; Tue, 18 Apr 2017 08:13:03 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0132.outbound.protection.outlook.com [104.47.42.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF83D1287A0 for ; Tue, 18 Apr 2017 08:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=giJs8iYjsBshoM/u6B65zvxI6cD5LL4qPtD2HFOSAZM=; b=i+oFclUrvJE6mh2lBmJSNYRRz08rEklVTN+30x5Po+6IopQJhYFcCxWFsdeKWsybGFouyBNvD25uZoxhKqHMgJIy+4TXj7pmYoxoFawjC27U9XwKGkIwMXYtNchEF6JAhvht/u3RETsg7X/lJvTPDoc1z6qwnYoZaQ+fwSz9R54= Received: from BN6PR05CA0031.namprd05.prod.outlook.com (10.174.92.172) by CY1PR05MB2490.namprd05.prod.outlook.com (10.167.10.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Tue, 18 Apr 2017 15:13:01 +0000 Received: from BY2NAM05FT023.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::209) by BN6PR05CA0031.outlook.office365.com (2603:10b6:405:39::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Tue, 18 Apr 2017 15:13:01 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT023.mail.protection.outlook.com (10.152.100.160) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Tue, 18 Apr 2017 15:12:57 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Apr 2017 08:12:34 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v3IFCWip012043; Tue, 18 Apr 2017 08:12:33 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id B20B711446; Tue, 18 Apr 2017 08:12:31 -0700 (PDT) To: Adam Langley CC: "David McGrew (mcgrew)" , Yehuda Lindell , "cfrg@ietf.org" In-Reply-To: References: <148786730667.20244.7762484121330383342.idtracker@ietfa.amsl.com> Comments: In-reply-to: Adam Langley message dated "Fri, 24 Feb 2017 11:57:23 -0800." From: "Mark D. Baushke" Date: Tue, 18 Apr 2017 08:12:31 -0700 Message-ID: <29736.1492528351@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(2980300002)(24454002)(199003)(189002)(377454003)(9170700003)(48376002)(2906002)(2810700001)(5003940100001)(50466002)(7696004)(2950100002)(53546009)(4326008)(38730400002)(110136004)(6246003)(47776003)(54906002)(6266002)(55016002)(53936002)(229853002)(6916009)(77096006)(105596002)(356003)(106466001)(81166006)(86362001)(93886004)(230783001)(53416004)(76506005)(6392003)(7846003)(5660300001)(7126002)(305945005)(8676002)(117636001)(8936002)(189998001)(76176999)(54356999)(50986999)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2490; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT023; 1:WSCQ8sxbyRTa1N+QDiPvMTWlf6cZWcdlwtVKcZfTtLju07OxjnJJNlfVxGNSGefCPFu4VD3V+pZ6qG8e5+WuE4OC2EFjvAzPDb6i4ObfCQlDEJtzI3IH2GBKLofjViam80z+8mYq+m9Q6CewU4AQ19pCld+tArrXJag9Ewy8yPhYlOl0TYUTMPuVN2HFwJh+Qvw0aEhhmOAuOIVauRMQmW8mRSzcD28PvkMXuwdYt1WHQdGLABkG9iebqz1mq86Xedb81PZ6JjQRl5wd4vxfoLHAjxkIUtWpvF0FRPpNHEZ9p/TAKIiHaP0lxu7FnNPk8xeb6v77hos2dUt44J6Xtq8sbcR0P/vIef66aMezm1y5ZFV6rHoNtghuy2EeVGgPUV2Puy7GG8vYI6cHU6wpV9D6YGfc3+PZyBjZ9EbJfgD7g+6M+V5bhMbVgjKEGTtt64fwDYHM9yst/UuGghYdwcC1GIR4uttbARdV81FM4GfcaiabM0ipDaPYW0ymXhpnZ3Fbjp9YpOHNR+gHqCAa04gZcX72au7hNyguUZjnUyNIz2napfNhonLxMhPW0O9oVq7o1Luw6IZ3SCSew0UvDVdQUdUTXc7/HO4pRcKEWuw3jppL9JCuKWmV1/fHYaHe X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 702fc4b8-fd10-4d4d-f9f0-08d4866d6776 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR05MB2490; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 3:15aIaz4FyJif/b0OSKDz847jWqFe3/D7UXTOeLKiKcAMtge2THi2j411rJCnKVWliSh00x3trAF5RU96c38siXVMdJChLTlYp1GhPaMLSSWTfQBcNJIHH5vOwxyucE7FRpb0FX3937R8Q7sNJCdL0YaPQhqHE4VGfwIU1ovXieWYuhlEZZK06ybS2ph89EYYp/Ix8VlhaGT1g9ldyt6BRMe9j4XScaAh4DP+BLhtIKoOXVod/15Y//zpiMVCLOM/oSTtaz+q4u3pNAmC0/k9f3BHZmWbHFZo2X6qvxU8R/QjFCC5BUvR4M8S7McK5QVUNh4PYXV20YD4Bu/wzrCGlizL0emQ6aDCZ6QGLgzy/jxE24yeZQX+jGMLYmdeReI+XRr65N1BSzcBxmrpX4bXV+RLgCPItI9TCdkKf1UwGN9Br3jMrY1BYzSZl2ebrl/ep79q8ha9JOi+KqxaKxgyHw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 25:aKVqRlPqtI43qhBRpPhJVGeDiU2L2tuLYrbxZH0TyfTUz44Tv8wIa0I51ruLKlBv1ahafUKymSfpqncIhJkl034ZpXduDUM6nCOCFfSa2PB4zQqOpCFNvH5glULZbysedF0ZRMerd/6nLIqNvX2psyWryp1ZRep0uKaCYQ4gpyvOKzAffC/cGpYz52x+sJmYz7M3mFdbIcm5ey1gTCONw7qTI55eY0ZfKrAj+NPnRRIm39Y389dlAIUFmeQqoqcVJCwo+upVTIyOdJhiJugIEhQ8j6WwekMUTdoAs0DerKywa6DLVH/tpx47r3e6CKVgxcJfNLisuWJaS7YzOTELblAbI9tdX3rFtwDC1RcCI6VHx78TFn+gNkGlVphebXP4QDRsEHcCm8GrsHBZixHAMkr52FscZ8m97djKzUY9C34lkPdv0fVg+c94mas+84uj439bcd4I9gnl3ORFhi4sEsWtcsmlTAu9Z+tgGaTfEdk=; 31:AvTQR1P6QhiVHRBm/ois2+cOIUfr3EEXwwDIEh87kfRvS820vmrS2Z2mZPL44cTNqGaDJsVK97v63Q1vGzFrCkQYJMDu9tFpOfW8ieupM9mlNC43j8TXuu0OUAuwffKrEzmnRYVgA7x7y53I0WxMHPhi9bLh5ACC5rqbpWBA57Q4e4L2mKfcZk3yzm0EzHlBBmgt4DyTVBqnZN6qBK7o4Fq8rvoeC90tQahfGhgU4yp8aHbnC7KUTovJxcu1rF8F X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 20:oPoWDqdce4nRdMjr7uGItRwwyzfqGzrXgcaabp+yXhgIRfVazE+QpNJEq/tfzDh91KtRmoYlYP6eHMu1CtmSuf3tomFUaUoCawnqUFLG2RJ77Wdff/IfAcok1W2bdxN7RxV7HTpLp1s3Wu/lUMJVECaa4q4uCw8pkXe36ngvOzDl4ixMHTapXd26sUMqz9rTnXdX/4qCp8BpFZBMAcqX6u4hYthahKwdTMFJCX9TZGZhacoDWWpozQRqTk6xlrPC9q2EG7gj9O7E7B5frW+18kmc1vRJypz4lkwgQDDO89JdcyO1fse6UVDx8rQX9lp3J83AnuZkJhURJsEobkUFheXkTelQxSB2UAFa2fDE7SnB+LySXQgVqZl97dfcp2npr0migOHRLqYUsnCgwFQyR4EvxoY1dk4KNM84WVanTdEC5PMVs79GRufF0Vt+6r8q7mnmxmXc0wlcq5UJdlEi8UBnQqRIB7N6XfRgN6sLfMjAgnRiK7Hw5nbz1QIJ2JC0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(13015025)(8121501046)(5005006)(13024025)(13023025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY1PR05MB2490; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2490; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 4:FJGtSCymalbVN4zKN2RrWcHQjyahzCZztFN/rCNRMwU0mhz7qkpqJJcAgKHwtBY9XZeO3idModsz/zYi+cttNejWhj3X+qYeWOw9McGgBVcSawtMiwAvtGUPqKKTXh/ZdG6DWzHAI+kERCN5l4dzte+53eSvQDifTJXchHx4FNaJf3wXQ+07bEE9mxDXqm/buY2vFBNCUVegN4Wtr4ZcISNCrDF0KWyi8U5waysH3rPG63oUzUBoPg0n/QmJCy5zqwJNvBnLx2864E1sZs6dovlpQERMFHE45a1k9CYcKwDy1VK5CkclmweG5qcPZCcinIkMrplNLPIUVxZzuJzJmY6t2RieCKqHPk77T4xiHYFSJzy8ZIjIEkxO06zG3UEgupYvrpQfKz3akgHSX05pJXw2KnHyHiS6BSf860NjidhvxTjEjfIGp3+/zabu7S+oiHK+PB31Oenz4tG1XvcWvJ7f6ZWQUzc9xU8T2aEBi4GXWS77ebcVAjcBIi3xAOsOvdWyUABkEOAdQ/zUjopbfwpqb51dF4OVokfvzv8gfaCFfVCvAcqCb/r6EBnpexyY50HO67eUrb3Z7uKTxRyv6cNsuN8K5kxsQcatIITUPd5vekHJ6fZudCjckseg/mPH4F+Ab8G2wRx+MQETnrxieBIvjaviz8IkMpJQsLz2nd5VjKDQudrzbTgCNLO0T6OLdgGgs5MhDKH+ynYHUi6vJMkHxUiJNm69HAPOybIWHUTXrRoxUlZt92zNPGf2dLzWAMh6J0GMXeE1eBhdJ4A8s0ikpdZ+QWKloP+wbM58mvn10upFcKt6ZQ+EdUornD48lv4Eqk7ylpr8og4/xoPhsfYdeemssM8mztmI9QkcMs8WYxzEQY1JVGJgsDdr6gT8 X-Forefront-PRVS: 028166BF91 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2490; 23:11XFSb/G7D+8HlOcRHXaVxpsR9aolAqwaLRn/Gq8E?= =?us-ascii?Q?/6rA31jEKfIPaUIi52T37sPkZyB1OYD9SInDuPQw+41RKvN/GP4aS6qkdk95?= =?us-ascii?Q?ckyc22fXO4LVqh29Y8boIh4X/12Sh/+tQyu7OVe1iI4kpzPBEsf/0TZ1Jm0y?= =?us-ascii?Q?zcciNJc3P4gsGQC+yS3euDv0i6G3J6t3wcqiC/9qCmaKBNtnJ2KhRBQSDvtZ?= =?us-ascii?Q?6xBuV/IMQgWRmHzIsEGFmyZRn5DXBbybkLXzL1PBFCEozosCOULwwTVamFF6?= =?us-ascii?Q?o09VaVB1oCUmvz71OY58myWmgeKPjvYC9UDsSAL9vnUYALRzs58FEAIhvl+u?= =?us-ascii?Q?gVvVYvyyQkRaRqaXxbHJD9ZbW7H7sNV7FXpC8fpaukkutwAi0Qn/1M+nkQNS?= =?us-ascii?Q?briLL1bjdIkdRiU960HYddyLNfZ/AxGt3jM7r+WLt6Uf+P+RsMJY+ajhcGuD?= =?us-ascii?Q?texO5MHpAhQ4OIr0+Fj2v4gc1zGt4I5hoHKxuqqJ19dLBIv8Z0ZAilOp4SAu?= =?us-ascii?Q?msB/ywZJ99c7XHaSpLym5NcA8vwmWMQbABHSAgu2SOJO1dB9fHcZ2qZysE7Q?= =?us-ascii?Q?VdXOBHVXUvMsgXhux2jAxmv0pVZOtbbj8wk24X5nbiRt5b1mfIleAxfHS73Q?= =?us-ascii?Q?ylT12UpA5AFnWSuAYCeBCpF4fxTG8WJWn/zITT4vZiqlayOvVUab7vM0qHRe?= =?us-ascii?Q?q4JlZfD1RKu59H/6qRMaYP4NB0MXUGCFuRi7nD33rRBZxxWxo05HHbZqR1Sg?= =?us-ascii?Q?PacGHOz/pNWimlzKJK2XnOSxhtOjyAuksym4CdU8RoEMsQRcF/lDnx4CDnzZ?= =?us-ascii?Q?XSTRPo8Oi+SivufKclQp32A+zQRhQz84g6eK7Dpt53Ks46Y5v+QTS34LdSzd?= =?us-ascii?Q?JwEiEWVa7vYUuXKhdZhhoEref6bjhidWDP3vNJ0jKmlX/SgXW9B85CuUvVQg?= =?us-ascii?Q?2kSUtzJips0giOc3zOegvz3qK+R3GHC8M44Cajyf63ugOGtkGNZiHTvtxARu?= =?us-ascii?Q?O/a9mx9csI2RDx3u0Vqp7C1809Jt9ikv37COz3Ew6tJ0+Auf4w41wsTwmmVy?= =?us-ascii?Q?fHKPrR2AqQKwik4DAGTmgVnBxunD9jQucBo8YjPXUJnZXf1jQ+eP4OjCQ1qz?= =?us-ascii?Q?hipyw34SKr6JSXgMbUer9csIPewZa4CxfffHQaJzl6ojSvp8j9jZANxK2t7K?= =?us-ascii?Q?3T9a4f4jhpQiSPgAG5G5zE65Ee62XpSs95CsggObZHxvXSCa2k/SDim/Ngqu?= =?us-ascii?Q?vB+E8bK7zcLZ1pBU/9AKO3Q3unxxc0ArDzpQWjzDpzAA6CBDWMTDtIgeHGVD?= =?us-ascii?Q?WuH2xWcQ/8dC3XGNwk1vuytXbKGZsxdTiBkyOdYkIbkHgxerteWqeOMAw7Qb?= =?us-ascii?Q?X8AUCgQqfFQW918/zh6BoioY7emqNOkN4PANVHmaEHVnOcVrWJRAF32Gj0zA?= =?us-ascii?Q?o/atbfVoTPPzpD2QjN1W27C+vE/GgI=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 6:PYzRgXyQOJeFEag79kU7TFtPt/pC+DY5WtFkqMFhq4IUPZFtl6aUdYzUoQzyP5Rw2tOeDGqNdX3q/TQ8deH3KYrUPEEXvwFVcOPF20xeYVohGkf7o/NMUAobZEUZpCv06x17e4q0rOXxhoHc3rckILbivTl4GzmT4GDqEV7xY4HGvfplLjQj+VnThu6nfNkCx4C8Ourc+lI9biGieT7xDwjtCS4TfrX2YdskyHaC2fpnRzv+ceK+A0v0jrO4VcHL1cpg8YkXOG1LMOw57TPbcOeCatzVwlhMxyJHtjxYFcRrO/x1C+a+ye2xP6DvWu0KFuiS8q8RPyNdUmihdO9lrYPVBwRsyJ8PG3jiIkUcIRqvwumORpdAaU5zlBhkmXOorDMBDF2MDFdIfhhfqjn18tvyGa7m1ILtrMGp3wK/1bu2kHOO0dIs4aKa0pX0RhhYDgadNqqkiw/sYc2/n3Y5P6iaPhXkaTdhcB3A954Iwfo=; 5:5su6LLTWCs1WeH4IVI9QwCteC5F0V6szr5kgEstPLAZa2PAe244rmlaipw2fHe3fgv885e8L9oQJnz0TYlRQeNllduxuVLWp2eWiPkjehZowkNlPSf6xqCFVl1AUSCL32H8PkMUUeHzgIl1EJeEUew==; 24:JOx/wFZ1KKm14QuIN8WeZyYBliJEbsUnYatn8LolOuCS0Z9ujAa0YSPtedaPnZ2w6ip6VMB14M7K2ASTGLw67xcQDgw5jHQhJ5iGaDnqFK8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2490; 7:0j+l39oxP+tKXZv4eDSyP3C74Fj1KzIDFqur9nx+idCwgBPbr/zhWIeq+5BZuzkAlNtU51kGfxa2wdEpCXsEBGnHKgaWy54Tc+5xuuKPOWnGek1+64pK5yVuBVf8S5F9lcsaypr+G3bf7zry2AWDucTZBnYJZ2/2RkosotkeVsrlcsluwbecMJgrIu3iVPTaEYNmp8FJ8jRb60Ke0n4F3hcYEGOEad3GOW+bqTaYsCKGE9wzvCbKPm3QsZRvMFvXe2yShX1RK/VL9RpPL4Ra6t+LwhMzbsfZ5mtKY096QOnzLsw9nMgS9XNAE6E7jLV323sx/dXfX+eHyXEhPODvZg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2017 15:12:57.7803 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2490 Archived-At: Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-04.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:13:04 -0000 Adam Langley writes: > On Fri, Feb 24, 2017 at 4:40 AM, David McGrew (mcgrew) wrote: > > p.s. - a nit that I noticed in the Ack section: Mosnaček > > Yes, it appears that the IETF processing doesn't handle UTF-8 :( I've > hammered that name into ASCII, I hope Ondrej doesn't mind. For what it is worth, I have found that using ISO-8859-1 encoding on the first line as in '' works, but '' does not. If you are trying to display LATIN SMALL LETTER C WITH CARON in the name, then that change should work fine for you too. -- Mark From nobody Wed Apr 19 17:18: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 37ED312EACF; Wed, 19 Apr 2017 17:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 81jdlO7L3Nea; Wed, 19 Apr 2017 17:17:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F024612EAD7; Wed, 19 Apr 2017 17:17:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3FB98B80100; Wed, 19 Apr 2017 17:17:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, cfrg@irtf.org Message-Id: <20170420001742.3FB98B80100@rfc-editor.org> Date: Wed, 19 Apr 2017 17:17:42 -0700 (PDT) Archived-At: Subject: [Cfrg] RFC 8125 on Requirements for Password-Authenticated Key Agreement (PAKE) Schemes 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, 20 Apr 2017 00:17:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8125 Title: Requirements for Password-Authenticated Key Agreement (PAKE) Schemes Author: J. Schmidt Status: Informational Stream: IRTF Date: April 2017 Mailbox: joern-marc.schmidt@secunet.com Pages: 10 Characters: 25375 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-cfrg-pake-reqs-08.txt URL: https://www.rfc-editor.org/info/rfc8125 DOI: 10.17487/RFC8125 Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG). This document is a product of the Crypto Forum Research Group of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Apr 25 07:00: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 A7069129462 for ; Tue, 25 Apr 2017 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WunbbL5qrKLW for ; Tue, 25 Apr 2017 06:59:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 51EA012944E for ; Tue, 25 Apr 2017 06:59:56 -0700 (PDT) X-AuditID: c1b4fb30-1aff698000002705-d0-58ff565ab100 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 94.61.09989.A565FF85; Tue, 25 Apr 2017 15:59:54 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.41]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0339.000; Tue, 25 Apr 2017 15:59:53 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "cfrg@irtf.org" , "Paterson, Kenny" , Alexey Melnikov Thread-Topic: Call for review on EDHOC Thread-Index: AQHSvcw2MQ0cM8b2CUWWmQ5Lc47jnw== Date: Tue, 25 Apr 2017 13:59:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <3A00D61F22D65B4F868BA221285AA108@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9UDcq7H+EwY+96hb73x9isuj+cZDJ ouvOSVYHZo+dpw6weUzeeJjN48vrVWwBzFFcNimpOZllqUX6dglcGWd2HGIq2CdUseDDW8YG xgahLkZODgkBE4k1G/4xgthCAusZJR5cDehi5AKyFzNKvF7+gw0kwSbgIvGg4RETiC0iUCfx YdkbsAZhAUWJRXt6WSDiahIdb/+yQ9h6EhfPXWTtYmTnYBFQlZjrCxLlFbCQ2P+sDWwio4CY xPdTa8AmMguIS9x6Mp8J4hwBiSV7zjND2KISLx//YwWxRYEm7u1pZ4OIK0msPbwdaCsHUK+m xPpd+hBjrCUWbH/NCmErSkzpfsgOsVZQ4uTMJywTGEVmIdk2C6F7FpLuWUi6ZyHpXsDIuopR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMGYObvltsIPx5XPHQ4wCHIxKPLwPWP5FCLEmlhVX 5h5ilOBgVhLh3Sr5P0KINyWxsiq1KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUw WSYOTqkGxpAA3v+KX6YwzVb10tyda18yb9qbFyGzv6jt2bPTZdbN21acMyK+bmS7fvX9MjHr ZWyJHZH6N1teMhqFSYUaMW9SXP3nsnfSI4N1E66u7HlWnymp+t3p3u0QtZopEoLR976GXnT5 texx33zJc9Iz7O95spir9d6tOxeVd4dhg6/KEgfHD0zrc5VYijMSDbWYi4oTAavNzFuVAgAA Archived-At: Subject: [Cfrg] Call for review on EDHOC 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, 25 Apr 2017 13:59:59 -0000 DQpEZWFyIENGUkcsIA0KDQpXZSBoYXZlIHdyaXR0ZW4gYSBkcmFmdCBvbiBlbWJlZGRpbmcgYSBr ZXkgZXhjaGFuZ2UgaW4gQ0JPUiAoUkZDIDcwNDkpIGFuZA0KQ09TRSAodG8tYmUgUkZDIDgxNTIp IGZvciB0aGUgYmVuZWZpdCBvZiBlLmcuIElvVCBkZXZpY2VzIGltcGxlbWVudGluZw0KdGhvc2Ug c3BlY2lmaWNhdGlvbnMuIFRoZSBkcmFmdCBpcyBlbnRpdGxlZCBFcGhlbWVyYWwgRGlmZmllLUhl bGxtYW4gT3Zlcg0KQ09TRSAoRURIT0MpOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNkaGUtMDYNCg0KV2Ugd291bGQgYmUgdmVyeSBncmF0 ZWZ1bCBpZiBzb21lb25lIGhhZCB0aGUgdGltZSB0byBtYWtlIGEgcmV2aWV3Lg0KDQpDaGFpcnM6 IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIG1ha2UgYSAyLW1pbnV0ZSBhbm5vdW5jZW1lbnQgaW4g dGhlIENGUkcNCm1lZXRpbmcgYXQgRXVyb2NyeXB0IDIwMTc/DQoNClRoYW5rcw0KR8O2cmFuDQoN Cg0KDQoNCk9uIDIwMTctMDQtMjUgMTU6MzIsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQp3cm90ZToNCg0KPg0KPkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS0wNi50eHQNCj5oYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEfDtnJhbiBTZWxhbmRlciBhbmQgcG9zdGVkIHRvIHRoZQ0K PklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNk aGUNCj5SZXZpc2lvbjoJMDYNCj5UaXRsZToJCUVwaGVtZXJhbCBEaWZmaWUtSGVsbG1hbiBPdmVy IENPU0UgKEVESE9DKQ0KPkRvY3VtZW50IGRhdGU6CTIwMTctMDQtMjUNCj5Hcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJMjgNCj5VUkw6ICAgICAgICAgICAgDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVj ZGhlLTA2LnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS8NCj5IdG1saXplZDogICAgICAg DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVj ZGhlLTA2DQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNkaGUtMDYNCj5EaWZmOiAgICAgICAg ICAgDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlbGFuZGVyLWFj ZS1jb3NlLWVjZGhlLTA2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgRXBoZW1lcmFsIERpZmZpZS1IZWxsbWFuIE92ZXIgQ09TRSAoRURIT0MpLCBhDQo+ICAgY29t cGFjdCwgYW5kIGxpZ2h0d2VpZ2h0IGF1dGhlbnRpY2F0ZWQgRGlmZmllLUhlbGxtYW4ga2V5IGV4 Y2hhbmdlDQo+ICAgd2l0aCBlcGhlbWVyYWwga2V5cyB0aGF0IGNhbiBiZSB1c2VkIG92ZXIgYW55 IGxheWVyLiAgRURIT0MgbWVzc2FnZXMNCj4gICBhcmUgZW5jb2RlZCB3aXRoIENCT1IgYW5kIENP U0UsIGFsbG93aW5nIHJldXNlIG9mIGV4aXN0aW5nIGxpYnJhcmllcy4NCj4NCj4gICAgICAgICAg ICAgICAgICAgICAgDQoNCg== From nobody Tue Apr 25 10:20:33 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8613168A for ; Tue, 25 Apr 2017 10:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVA5LA1xhVUU for ; Tue, 25 Apr 2017 10:20:29 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0059.outbound.protection.outlook.com [104.47.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3280B1316ED for ; Tue, 25 Apr 2017 10:19:41 -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=2CvgQAygxt4tnLUCXF8V5wsVUCR0462p1KSuil1rE0Q=; b=ylwvudThtc73rw2XnOu5VN2lzbIaGX2lH6w0Lj3cJFhcJkyYNMb8hYgCp9j98rfd4NLCeUnOanyYo2lyv677gB2T0HvIQnI2of0w3IVdUqoBInxvlUQy6/P6OUchSrFoKFNBK8Js4Dmdoc1oqbzIQeeFM/QeSLP/Uowx2OiHMrM= 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.1047.13; Tue, 25 Apr 2017 17:19:39 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a814:f700:62dd:515f]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a814:f700:62dd:515f%14]) with mapi id 15.01.1047.019; Tue, 25 Apr 2017 17:19:38 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Final agenda for CFRG meeting on Sunday 30th April (at Eurocrypt 2017) + joining instructions Thread-Index: AQHSvegeAX81MPMHQU2DcLt4gqcrWA== Date: Tue, 25 Apr 2017 17:19:38 +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: [85.255.237.173] x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:Ms9D+KnfpBgZUgLJ3SGpF28+JdyYahaNj9kZYd8Bb+IeOx0oTm0zJQYWnkEA/yXghbq3bqoTB0ruQQnX3uTOqWisO5USwkOWm/+MfSF4/nW91LR0TtQIfhAkoHzoS2DHgbwcEBAIU3e0mlIZrXRX/uZubbM2WVQPhEVAamMp2cgXkuwEpZy7qELuD1zDGi3w4pM5fDATqpGnz6Tbk+sF9DZ+uDvWgvDUyPQs9b/ET7om7mw8WStrxQhnPfI6MLaqCcz1gbymN5UDwsEK8s2yzNPGihjbVNSX8/Ll3Ai8EfJXyAmJg9Wh580OYf7foyloDPGpJJflXsJNuonBlvEo7A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39450400003)(39840400002)(39410400002)(39400400002)(52024003)(497574002)(42882006)(551544002)(6246003)(66066001)(6916009)(229853002)(99286003)(6506006)(3280700002)(2906002)(3660700001)(2900100001)(6436002)(6486002)(2351001)(966004)(189998001)(5250100002)(5660300001)(74482002)(4001350100001)(2501003)(102836003)(54356999)(15188155005)(3846002)(16799955002)(7736002)(6306002)(83506001)(6512007)(6116002)(36756003)(25786009)(50986999)(1730700003)(81166006)(110136004)(86362001)(305945005)(53936002)(8676002)(38730400002)(5640700003)(8936002); 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: 89ea8812-f9c3-444d-94f5-08d48bff40d9 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)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906; x-forefront-prvs: 0288CD37D9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4EDAEB660FDC654A98150BA150F01489@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 17:19:38.5904 (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] Final agenda for CFRG meeting on Sunday 30th April (at Eurocrypt 2017) + joining instructions 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, 25 Apr 2017 17:20:32 -0000 RGVhciBDRlJHLA0KDQpCZWxvdyBpcyB0aGUgZmluYWwgYWdlbmRhIGZvciB0aGUgQ0ZSRyBNZWV0 aW5nIHRvIGJlIGhlbGQgaW4gUGFyaXMgb24NClN1bmRheSAzMHRoIEFwcmlsLiANCg0KSm9pbmlu ZyBpbnN0cnVjdGlvbnMgYXJlIGFsc28gaW5jbHVkZWQgYmVsb3cgdGhlIGFnZW5kYS4gVGFrZSBj YXJlZnVsIG5vdGUNCm9mIHRoZSB2ZXJ5IHNwZWNpZmljIHJlcXVpcmVtZW50cyBjb25jZXJuaW5n IHRoZSBuZWVkIHRvIGNhcnJ5DQppZGVudGlmaWNhdGlvbiB3aXRoIHlvdS4NCg0KUGxlYXNlIGlt bWVkaWF0ZWx5IHNlbmQgbWUgeW91ciBkZXRhaWxzIChuYW1lLCBhZmZpbGlhdGlvbikgSUYgeW91 IGhhdmUNCm5vdCBmb3JtYWxseSByZWdpc3RlcmVkIGZvciB0aGUgbWVldGluZyB2aWEgdGhlIEV1 cm9jcnlwdCB3ZWJzaXRlLCBidXQgYXJlDQpwbGFubmluZyBvbiBhdHRlbmRpbmcuIChJZiB5b3Ug ZG8gbm90IGRvIHNvLCBhbmQgaGF2ZSBub3QgZm9ybWFsbHkNCnJlZ2lzdGVyZWQsIHRoZW4geW91 IG1heSBiZSBkZW5pZWQgZW50cnkgdG8gdGhlIFVNUEMgY2FtcHVzLikNCg0KDQpSZWdhcmRzDQoN Cktlbm55DQoNCi0tLQ0KDQpDRlJHIEludGVyaW0gTWVldGluZywgUGFyaXMsIEZyYW5jZQ0KVGlt ZTogU3VuZGF5IEFwcmlsIDMwLCAyMDE3ICAxNjowMC0xODowMA0KVmVudWU6IFVQTUMgQ2FtcHVz IEp1c3NpZXUsIDQgcGxhY2UgSnVzc2lldSwgNzUwMDUgUGFyaXMsIEZyYW5jZQ0KUm9vbTogMjAz DQpWZW51ZSBtYXAgYW5kIGRldGFpbHM6DQpodHRwOi8vd3d3LmllZWUtc2VjdXJpdHkub3JnL1RD L0V1cm9TUDIwMTcvZXZlbnRzLnBocA0KDQoNCkNoYWlyczogS2VubnkgUGF0ZXJzb24gYW5kIEFs ZXhleSBNZWxuaWtvdg0KDQpBZ2VuZGE6IA0KDQoxNjowMCBDRlJHIHN0YXR1cyB1cGRhdGUgZnJv bSBDRlJHIGNoYWlycw0KICAgICAgKDEwIG1pbnM7IEtlbm55IFBhdGVyc29uKQ0KDQoxNjoxMCBB cmdvbiAyIHVwZGF0ZQ0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaXJ0Zi1jZnJnLWFyZ29uMi8NCiAgICAgICgxNSsxMCBtaW5zOyBEbWl0cnkgS2hvdnJhdG92 aWNoKQ0KDQoxNjozNSBQS0VYOiBBIFBhc3N3b3JkLUF1dGhlbnRpY2F0ZWQgUHVibGljIEtleSBF eGNoYW5nZQ0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFy a2lucy1wa2V4Lw0KICAgICAgKDEwKzUgbWluczsgRGFuIEhhcmtpbnMpDQoNCjE2OjUwIENhZXNh cidzIFJvbGUgaW4gdGhlIEZhbGwgb2YgQUUgU2VjdXJpdHkNCiAgICAgICgxNSsxMCBtaW5zOyBQ b295YSBGYXJzaGltKQ0KDQoxNzoxNSBCSVAzMi1FZDI1NTE5DQogICAgICAoMTUrMTAgbWluczsg RG1pdHJ5IEtob3ZyYXRvdmljaCkNCg0KMTc6NDAgRXZhbHVhdGlvbiBvZiBzZWNwMjU2azEgYXMg cG9wdWxhciBhbHRlcm5hdGl2ZSBjdXJ2ZQ0KICAgICAgKDUrNSBtaW5zOyBDaHJpc3RvcGhlciBB bGxlbikNCg0KMTc6NTAgRXBoZW1lcmFsIERpZmZpZS1IZWxsbWFuIE92ZXIgQ09TRSAoRURIT0Mp Og0KICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1j b3NlLWVjZGhlLTA2DQogICAgICAoNSBtaW5zOyBHw7ZyYW4gU2VsYW5kZXIpDQoNCjE3OjU1IE9w ZW4gZGlzY3Vzc2lvbg0KDQoxODowMCBGaW5pc2gNCg0KSm9pbmluZyBpbnN0cnVjdGlvbnMNCg0K DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCioqKioqDQoqKklNUE9SVEFOVCoqIFBsZWFzZSBicmluZyBh IHBpZWNlIG9mIElEIGluIG9yZGVyIHRvIGVudGVyIHRoZSBVUE1DDQpjYW1wdXMuIFNpbmNlIHRo ZSBldmVudHMgaGFwcGVuIGR1cmluZyB0aGUgd2Vla2VuZCwgVVBNQyBhc2tlZCB1cyBmb3INCnRo ZSBuYW1lcyBvZiBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBhZmZpbGlhdGVkIGV2ZW50cyBhbmQg dGhlaXINCnNlY3VyaXR5IHBlb3BsZSBtaWdodCBjaGVjayB0aGUgaWRlbnRpdHkgb2YgdGhlIHBl b3BsZSBlbnRlcmluZyB0aGUNCmNhbXB1cyBhZ2FpbnN0IG91ciBsaXN0LiBXZSBkb24ndCByZWFs bHkga25vdyBob3cgc2VyaW91cyB0aGV5IHdpbGwgYmUNCmFib3V0IHRoaXMsIGJ1dCB3ZSB3b3Vs ZCBwcmVmZXIgbGlrZSB0byBiZSBvbiB0aGUgc2FmZSBzaWRlLCBzbyB3ZQ0Ka2luZGx5IGFzayB5 b3UgdG8gYnJpbmcgYSBwaWVjZSBvZiBJRC4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKioqKioNCg0K VGhlIHJlZ2lzdHJhdGlvbiBkZXNrIGZvciB0aGUgYWZmaWxpYXRlZCBldmVudHMgaXMgaW4gdGhl IENhdGVyaW5nDQpab25lIG9uIHRoZSAxc3QgZmxvb3IgYmV0d2VlbiB0b3dlcnMgNDQgYW5kIDQ1 LiBGb3IgbW9yZSBpbmZvcm1hdGlvbg0KYWJvdXQgdGhlIHZlbnVlIGluY2x1ZGluZyBtYXBzIGFu ZCBwaWN0dXJlcyBoYXZlIGEgbG9vayBoZXJlOg0KaHR0cDovL3d3dy5pZWVlLXNlY3VyaXR5Lm9y Zy9UQy9FdXJvU1AyMDE3L3ZlbnVlLnBocA0KDQpBIGJyb2NodXJlIGNvbnRhaW5pbmcgbG90cyBv ZiB1c2VmdWwgaW5mb3JtYXRpb246DQpodHRwczovL2V1cm9jcnlwdDIwMTcuZGkuZW5zLmZyL0Fm ZmlsaWF0ZWRFdmVudHNCcm9jaHVyZS5wZGYNCihoYXJkIGNvcGllcyB3aWxsIGJlIGF2YWlsYWJs ZSBhdCB0aGUgcmVnaXN0cmF0aW9uIGRlc2spLg0KDQo= From nobody Wed Apr 26 01:04:01 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91F131CDA for ; Wed, 26 Apr 2017 01:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW4pjPM8Gorp for ; Wed, 26 Apr 2017 01:03:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 A4409131CD5 for ; Wed, 26 Apr 2017 01:03:55 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id 203so104004485ywe.0 for ; Wed, 26 Apr 2017 01:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wTFrU8VI2CkM6qeZZwdIsSha4vadxCXth3hyiB5AT+k=; b=aZpGWJatgGBGJbchqIhRtOQnPJ1jT9y23PltavZDTQJsiYCzw7r5+VCJW61wFY5TkD gr1EJz9eUvjkqpBMlX6GSOW2X168owireSXlKgP/RHEXKr4kMR7AQXcJrRDOz7liG+ZU WAVSbC/KUVY42pp/vyYzCUKx4YVZyJCjEL/BzUiAHFay0H5KocqtWfma7m8uskDzHnW+ LTUhzSryoqFqL/W44MOFr2rLrFCB8To/SE4UFjFVTGz1kZYwA9Yo5H1UandFwv2WN1FQ 4bdSvrhLRBKInO19VXoN4FUUpJlZp8u2W3X8mV1XfCFLq9e0DxC0/2GlHRm3vuynMmzz +Jrw== 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=wTFrU8VI2CkM6qeZZwdIsSha4vadxCXth3hyiB5AT+k=; b=XnuypARkbjRJIZOvR4n0bG+3YRl9OYIzeTy8ygaarn2xbeHtYhTZI8D+fGGCvNLfJR VJz27GcRsj6eJDrleU9iC1sLmEXnvWEJ4eNKYAdFR75ucOHktL3d4CyWEJTFrRRR4dpH /zPSVfpoiSQw0GoSsbGnLY99qzvrCLRF2tbf04MnKJT+GRncdc60kcmwmuOw54Po8p4p lOVGLYW4RXpOt8mZMCfp126Zm2NA3eMwoR7TL9iojIhxZRIaq7iHfv6/tNhlR51ni+uR 7cErHyob2lGBGz0HnPKR3NEx34zb/hFVQiYh5k70SLOPZdA+kgA/U9j1xZGjowth0azc rUuQ== X-Gm-Message-State: AN3rC/6zo4agMANLZGiGDW8VT5SUNxnpGndoy50eL3I6syfEpUvPlTjX 8YO9J2MBffzHneYw1I8fk0FUELeKTA== X-Received: by 10.129.157.214 with SMTP id u205mr14027653ywg.12.1493193834849; Wed, 26 Apr 2017 01:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.10.12 with HTTP; Wed, 26 Apr 2017 01:03:39 -0700 (PDT) In-Reply-To: References: From: Dmitry Khovratovich Date: Wed, 26 Apr 2017 10:03:39 +0200 Message-ID: To: Oleg Andreev Cc: cfrg@irtf.org Content-Type: multipart/alternative; boundary=94eb2c0bcc3e1b6b82054e0d48f4 Archived-At: Subject: Re: [Cfrg] Revised ChainKD: BIP32 adaptation to Ed25519 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, 26 Apr 2017 08:04:00 -0000 --94eb2c0bcc3e1b6b82054e0d48f4 Content-Type: text/plain; charset=UTF-8 Hi Oleg, I have depicted our and yours schemes at the attached pictures, and I invite the readers to look at them. The scheme by Dmitry is here https://drive.google.com/open?id=0ByMtMw2hul0Ea1pkVkxUYmpSd1k and the newest scheme by Oleg is here https://drive.google.com/open?id=0ByMtMw2hul0ERHhlNXhxT1Axa0k One may see that the Oleg version does save on space for public/private keys and for HMAC calls. However, it is more intrusive as it uses HMAC instead of SHA-512 for the private key derivation and introduces an extra HMAC call in the signature generation phase thus making it incompatible with the original EdDSA. (Generally I do not see any reason to use HMAC, particularly HMAC with a public key, when we just need a keyed hash function). I truly believe that it is worth to rely as much as possible on the EdDSA parts as TCB, thus minimizing the difference. It seems to be possible to combine both Oleg's approach to compactness and ours to be less intrusive. Concretely, I suggest deriving the "chain code" directly by hashing the extended private key: https://drive.google.com/open?id=0ByMtMw2hul0EcGxEUHpaSWFWLUE Note that the k_R part enters the hash function exactly in the same way as it does in the signature generation phase. However, a collision is possible only if k_L equals M, which is unlikely (and can be properly upper bounded) for an attacker who does not know k_L. A formal security proof should handle this case. An alternative could be to use a different hash function here. I wonder what the community thinks of these three approaches. Dmitry On Sat, Apr 15, 2017 at 1:05 AM, Oleg Andreev wrote: > Hello, > > I would like to present a revised version ChainKD: a deterministic > hierarchical > key derivation scheme for Ed25519 inspired by BIP32 [1]. This a result of > ongoing > discussion on CFRG list [2,3], Curves list at moderncrypto.org [4,5] and > Tor-dev list [6]. > > ChainKD is now a concrete proposal, with specification and a working code, > ready to be evaluated as a candidate for becoming an industry standard. > > Specification & rationale: > https://github.com/chain/chain/blob/chainkd-dh/docs/ > protocol/specifications/chainkd.md > > Implementation in Go: > https://github.com/chain/chain/blob/chainkd-dh/crypto/ > ed25519/chainkd/chainkd.go > > Pull-request & discussion: > https://github.com/chain/chain/pull/844/ > > You will find the description of functionality, rationale and tradeoffs in > the spec > (first link above), here I will only highlight some _differences_ with > other > schemes and proposals: > > ChainKD vs BIP32: > 1. BIP32 is defined for curve secp256k1, and fairly easily applied to > cofactor=1 curves, > while ChainKD is designed specifically for Ed25519 having cofactor 8. > 2. Derivation index in BIP32 is a 31-bit integer, in ChainKD it is a > binary string. > 3. BIP32 proposes a serialization format with metadata and checksums, > ChainKD > delegates it to other specifications and uses raw hex representation. > > ChainKD vs BIP32-Ed25519 (BE for brevity) [7]: > 1. Like in BIP32, BE uses 31 integers as derivation indices, ChainKD > allows binary strings. > 2. BE extended private key is 96-byte structure with 3 fields, ChainKD is > similar to BIP32 > having 2-field 64-byte structure. > 3. BE has a slightly higher child key collision probability due to a > slightly simpler > bit-clearing rule for the child scalars. ChainKD saves 6 bits. I will > note, though, > that entropy in all private keys is the same 250 bits in both schemes. > > ChainKD vs Tor proposal 224 [8]: > 1. ChainKD, like BIP32 uses scalar addition to derive child scalars, while > prop224 uses > scalar multiplication. > 2. Tor's prop224 does not include considerations for hardened derivation > (from the > private key only). > 3. Tor's prop224 is not concerned with non-signature usage and does > attempt to be > compatible with EdDSA [6]. ChainKD strives for compatibility with EdDSA > and DH uses. > 4. Note: I'm still in the process of figuring out Tor's requirements to > figure out > if the ChainKD satisfies them or not. Result of this investigation may > affect > some aspects of the ChainKD design in the near future. > > Would love to hear more thoughts on this. I imagine there are many more > fine details > and considerations to discuss, including, of course, potential bugs and > security issues with our design. > > Thank you! > > PS. I would like to thank Tony Arcieri, Dmitry Khovratovich, Jason Law, > Gregory Maxwell, > Pieter Wuille, Henry de Valence, Mike Hamburg, Trevor Perrin, Taylor R. > Campbell > and others for the hugely valuable feedback, suggestions and explanations. > > [1] BIP32: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > [2] CFRG thread 1: https://www.ietf.org/mail-archive/web/cfrg/current/ > msg09077.html > [3] CFRG thread 2: https://www.ietf.org/mail-archive/web/cfrg/current/ > msg09110.html > [4] Curves thread 1: https://moderncrypto.org/mail- > archive/curves/2017/000858.html > [5] Curves thread 2: https://moderncrypto.org/mail- > archive/curves/2017/000866.html > [6] Tor-dev thread: https://lists.torproject.org/ > pipermail/tor-dev/2017-April/012204.html > [7] BIP32-Ed25519: https://drive.google.com/open?id= > 0ByMtMw2hul0EMFJuNnZORDR2NDA > [8] Tor prop224 (see KEYBLIND): https://gitweb.torproject.org/ > torspec.git/tree/proposals/224-rend-spec-ng.txt > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > -- Best regards, Dmitry Khovratovich --94eb2c0bcc3e1b6b82054e0d48f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Oleg,

I have depicted our and yours = schemes at the attached pictures, and I invite the readers to look at them.= The scheme by Dmitry is here=C2=A0https://drive.google.com/open?id=3D0ByM= tMw2hul0Ea1pkVkxUYmpSd1k and the newest scheme by Oleg is here=C2=A0ht= tps://drive.google.com/open?id=3D0ByMtMw2hul0ERHhlNXhxT1Axa0k

One may see that the Oleg version does save on space for pu= blic/private keys and for HMAC calls. However, it is more intrusive as it u= ses HMAC instead of SHA-512 for the private key derivation and introduces a= n extra HMAC call in the signature generation phase thus making it incompat= ible with the original EdDSA. (Generally I do not see any reason to use HMA= C, particularly HMAC with a public key, when we just need a keyed hash func= tion).

I truly believe that it is worth to rely as= much as possible on the EdDSA parts as TCB, thus minimizing the difference= . It seems to be possible to combine both Oleg's approach to compactnes= s and ours to be less intrusive. Concretely, I suggest deriving the "c= hain code" directly by hashing the extended private key:
Note that the k_R part enters the hash function exactly in the same way as= it does in the signature generation phase. However, =C2=A0a collision is p= ossible only if k_L equals M, which is unlikely (and can be properly upper = bounded) for an attacker who does not know k_L.=C2=A0 A formal security pro= of should =C2=A0handle this case. An alternative could be to use a differen= t hash function here. =C2=A0=C2=A0

I wonder what t= he community thinks of these three approaches.

Dmi= try

On= Sat, Apr 15, 2017 at 1:05 AM, Oleg Andreev <oleganza@gmail.com>= wrote:
Hello,

I would like to present a revised version ChainKD: a deterministic hierarch= ical
key derivation scheme for Ed25519 inspired by BIP32 [1]. This a result of o= ngoing
discussion on CFRG list [2,3], Curves list at moderncrypto.org [4,5] and = Tor-dev list [6].

ChainKD is now a concrete proposal, with specification and a working code,<= br> ready to be evaluated as a candidate for becoming an industry standard.

Specification & rationale:
https://github= .com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md

Implementation in Go:
https://github.com/c= hain/chain/blob/chainkd-dh/crypto/ed25519/chainkd/chainkd.go<= br>
Pull-request & discussion:
https://github.com/chain/chain/pull/844/

You will find the description of functionality, rationale and tradeoffs in = the spec
(first link above), here I will only highlight some _differences_ with othe= r
schemes and proposals:

ChainKD vs BIP32:
1. BIP32 is defined for curve secp256k1, and fairly easily applied to cofac= tor=3D1 curves,
=C2=A0 =C2=A0while ChainKD is designed specifically for Ed25519 having cofa= ctor 8.
2. Derivation index in BIP32 is a 31-bit integer, in ChainKD it is a binary= string.
3. BIP32 proposes a serialization format with metadata and checksums, Chain= KD
=C2=A0 =C2=A0delegates it to other specifications and uses raw hex represen= tation.

ChainKD vs BIP32-Ed25519 (BE for brevity) [7]:
1. Like in BIP32, BE uses 31 integers as derivation indices, ChainKD allows= binary strings.
2. BE extended private key is 96-byte structure with 3 fields, ChainKD is s= imilar to BIP32
=C2=A0 =C2=A0having 2-field 64-byte structure.
3. BE has a slightly higher child key collision probability due to a slight= ly simpler
=C2=A0 =C2=A0bit-clearing rule for the child scalars. ChainKD saves 6 bits.= I will note, though,
=C2=A0 =C2=A0that entropy in all private keys is the same 250 bits in both = schemes.

ChainKD vs Tor proposal 224 [8]:
1. ChainKD, like BIP32 uses scalar addition to derive child scalars, while = prop224 uses
=C2=A0 =C2=A0scalar multiplication.
2. Tor's prop224 does not include considerations for hardened derivatio= n (from the
=C2=A0 =C2=A0private key only).
3. Tor's prop224 is not concerned with non-signature usage and does att= empt to be
=C2=A0 =C2=A0compatible with EdDSA [6]. ChainKD strives for compatibility w= ith EdDSA and DH uses.
4. Note: I'm still in the process of figuring out Tor's requirement= s to figure out
=C2=A0 =C2=A0if the ChainKD satisfies them or not. Result of this investiga= tion may affect
=C2=A0 =C2=A0some aspects of the ChainKD design in the near future.

Would love to hear more thoughts on this. I imagine there are many more fin= e details
and considerations to discuss, including, of course, potential bugs and
security issues with our design.

Thank you!

PS. I would like to thank Tony Arcieri, Dmitry Khovratovich, Jason Law, Gre= gory Maxwell,
Pieter Wuille, Henry de Valence, Mike Hamburg, Trevor Perrin, Taylor R. Cam= pbell
and others for the hugely valuable feedback, suggestions and explanations.<= br>
[1] BIP32: https://github.com/bitcoin/= bips/blob/master/bip-0032.mediawiki
[2] CFRG thread 1: https://www.ietf.= org/mail-archive/web/cfrg/current/msg09077.html
[3] CFRG thread 2: https://www.ietf.= org/mail-archive/web/cfrg/current/msg09110.html
[4] Curves thread 1: https://moderncryp= to.org/mail-archive/curves/2017/000858.html
[5] Curves thread 2: https://moderncryp= to.org/mail-archive/curves/2017/000866.html
[6] Tor-dev thread: https://lis= ts.torproject.org/pipermail/tor-dev/2017-April/012204.html [7] BIP32-Ed25519: https://drive.goog= le.com/open?id=3D0ByMtMw2hul0EMFJuNnZORDR2NDA
[8] Tor prop224 (see KEYBLIND): https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt



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



--
Best regards,<= /div>
Dmitry Khovratovich
--94eb2c0bcc3e1b6b82054e0d48f4-- From nobody Thu Apr 27 03:13:34 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C300C128A32 for ; Thu, 27 Apr 2017 03:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzcb-xQXFgNU for ; Thu, 27 Apr 2017 03:13:30 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0057.outbound.protection.outlook.com [104.47.2.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C8912896F for ; Thu, 27 Apr 2017 03:13:30 -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=IFYnBQxSzbugk5SmdmAP5JU28xc9lR4eg+aP8BZg+wc=; b=uI9MlS1LJCNO+ZZjksH5DGPNjRrnBkEr3vdyIpoI3nEbPZNcI89y0Qgz7hgcmQGP7n9cbhCmchFolLwRaYLIwylKWpk4In4q73fs9IRny1+yxddT4UmML6mhDphwlUnvjlwpFm2HTSau2UO8pxrPbCymXvv115wVnZIK/fboXcU= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 10:13:26 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a814:f700:62dd:515f]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::a814:f700:62dd:515f%14]) with mapi id 15.01.1047.019; Thu, 27 Apr 2017 10:13:26 +0000 From: "Paterson, Kenny" To: "cfrg@irtf.org" Thread-Topic: Research Group Last Call: draft-nir-cfrg-rfc7539bis Thread-Index: AQHSvz7oBYW24CQD50KN6G/kOpU85g== Date: Thu, 27 Apr 2017 10:13:26 +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-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:xplNF3e5oGylLF8EEEcXMGdYIi5BgYKjeRTByII1RQtNeu4953wSm0geiZslmPv797nWX2gFUXKz4Eb/CEhNfIRWyOcvkAieSAOMaA6KhyllB1hIVP/G5mKDmpggmUqqTD1nDa6NoIb7Wo+RpTmfOgGIFUduhgdl1aKpKg0IexUFyLt5jDa3rWqH0sHsjGmMl9XjU5xoQk+KssJ0OPF+6AmJjFI6TgsGxQJPec4uJxxFpXfoP+E5k0WObH5LJ7pOHZkP0t32gKIguXOKE3S92vDbM+qVz6bAkszSyM68PbyQqoHwj9BayhnT2Goyj/0PRh3jQAkqr58KxILS1mIOLw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39410400002)(39450400003)(39400400002)(5640700003)(230783001)(86362001)(2351001)(99286003)(6916009)(5250100002)(42882006)(6486002)(68196006)(4326008)(66066001)(36756003)(25786009)(2501003)(189998001)(83506001)(6116002)(110136004)(39060400002)(6436002)(7736002)(305945005)(74482002)(3660700001)(3280700002)(5660300001)(6512007)(8936002)(1730700003)(6506006)(2900100001)(3846002)(8676002)(54356999)(38730400002)(53936002)(81166006)(2906002)(50986999)(6306002)(4001350100001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 3db561d2-a409-43c4-4890-08d48d560b7e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM4PR0301MB1908; 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)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908; x-forefront-prvs: 029097202E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <30734A930D3DE34287AAAE6986898408@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 10:13:26.5071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908 Archived-At: Subject: [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, 27 Apr 2017 10:13:33 -0000 RGVhciBDRlJHLA0KDQpUaGlzIG1lc3NhZ2Ugc3RhcnRzIDIgd2Vla3MgUkdMQyBvbiBkcmFmdC1u aXItY2ZyZy1yZmM3NTM5YmlzICgiQ2hhQ2hhMjANCmFuZCBQb2x5MTMwNSBmb3IgSUVURiBQcm90 b2NvbHMiKSwgd2hpY2ggd2lsbCBlbmQgb24gVGh1cnNkYXkgMTF0aCBNYXkuDQpUaGUgZHJhZnQg aXMgYXZhaWxhYmxlIGhlcmU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LW5pci1jZnJnLXJmYzc1MzliaXMvDQoNCg0KUGxlYXNlIHByb3ZpZGUgeW91ciByZXZpZXcg Y29tbWVudHMsIGFzIHdlbGwgYXMgc3RhdGVtZW50IG9mIHN1cHBvcnQgKG9yDQpub3QpIGluIHJl cGx5IHRvIHRoaXMgbWVzc2FnZSBvciBkaXJlY3RseSB0byBDRlJHIGNoYWlycy4NCg0KVGhhbmtz LA0KDQpBbGV4ZXkgYW5kIEtlbm55DQoNCg0K From nobody Thu Apr 27 03:36:28 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 96059128B93 for ; Thu, 27 Apr 2017 03:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 qIv3DwlxXdOl for ; Thu, 27 Apr 2017 03:36:24 -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 609C9128B8E for ; Thu, 27 Apr 2017 03:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AA6CABE80; Thu, 27 Apr 2017 11:36:21 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAlhbKVC31nl; Thu, 27 Apr 2017 11:36:21 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15E7BBEB3; Thu, 27 Apr 2017 11:36:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1493289381; bh=JLMx0idbvOz40xxtObk357d0bjMYn7yYND+9wJ+AEvo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=P/BKRbkmBvrV72DsGxAooKme50Y/PDqzYcZPJ4kLgplySyPMIUo2WM7l1adlcgXYZ qEd4/yUk6nPGkzRMIaItDTHCo9lsxxvA4AdYQchpuCdLsgBsQ/3jimIemxSKyMuw0Z 1GZ8rI1iPIlf1KjMdqZUlRSYH97zHpNoYMlCIgnY= To: "Paterson, Kenny" , "cfrg@irtf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6e5e15b2-aa0b-1722-9760-91034b58dac5@cs.tcd.ie> Date: Thu, 27 Apr 2017 11:36:20 +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="DwG1MfsOmgqmSgcA514W3hbuIX9G15hKJ" 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, 27 Apr 2017 10:36:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DwG1MfsOmgqmSgcA514W3hbuIX9G15hKJ Content-Type: multipart/mixed; boundary="cTUTP5Tgo3VF2jd1SIkEkJoamqxq98nj4"; protected-headers="v1" From: Stephen Farrell To: "Paterson, Kenny" , "cfrg@irtf.org" Message-ID: <6e5e15b2-aa0b-1722-9760-91034b58dac5@cs.tcd.ie> Subject: Re: [Cfrg] Research Group Last Call: draft-nir-cfrg-rfc7539bis References: In-Reply-To: --cTUTP5Tgo3VF2jd1SIkEkJoamqxq98nj4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27/04/17 11:13, Paterson, Kenny wrote: > Dear CFRG, >=20 > This message starts 2 weeks RGLC on draft-nir-cfrg-rfc7539bis ("ChaCha2= 0 > 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 (o= r > not) in reply to this message or directly to CFRG chairs. >=20 I looked at the diff vs. 7539 and it seems fine to me. I didn't check back on the errata in detail but assume others did. Cheers, S. > Thanks, >=20 > Alexey and Kenny >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 --cTUTP5Tgo3VF2jd1SIkEkJoamqxq98nj4-- --DwG1MfsOmgqmSgcA514W3hbuIX9G15hKJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZAcmkAAoJEC88hzaAX42i3mwIAJd5ASwTJSf6pwDZzwDL9s+Y bLBTLmKqyWTaXluB8S9y+tdI2O6Bu3J/H/yuis+tiIuepFusuEFNT1H7f/w4rWdh MxJNxeqb7+uWfKBb9gxQIP2jwofGUYGJwKVfk+lkOxv0pgL54zNFFuV8Zy7x3/B3 h/t3eHhQvNWUyyuKZxOOBCctVNc51dgofKmcX2D8L2y5KG1dcWK9zlrUZteWTalb dZoxVLPoMy1mJ9VFjoW/H6xCQNjdmAkgDZddqgfp4cmtsyjaZzF+ZtFywnCIvbkk lfvcp6284QFwXgC2WriiLrbUVKcaPEyaPPpOBIkQiP9jCeedQxZKMoiZVIY4J5k= =Zgwi -----END PGP SIGNATURE----- --DwG1MfsOmgqmSgcA514W3hbuIX9G15hKJ--