Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]
Harry Halpin <hhalpin@w3.org> Fri, 19 December 2014 12:44 UTC
Return-Path: <hhalpin@w3.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F001A888B for <cfrg@ietfa.amsl.com>; Fri, 19 Dec 2014 04:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level:
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 EjxFeC9EPNqp for <cfrg@ietfa.amsl.com>; Fri, 19 Dec 2014 04:44:38 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718E91A8755 for <cfrg@irtf.org>; Fri, 19 Dec 2014 04:44:38 -0800 (PST)
Received: from men75-11-88-175-104-179.fbx.proxad.net ([88.175.104.179] helo=[192.168.1.48]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <hhalpin@w3.org>) id 1Y1wv5-0005v2-Dt; Fri, 19 Dec 2014 07:44:35 -0500
Message-ID: <54941DAC.7030208@w3.org>
Date: Fri, 19 Dec 2014 13:44:28 +0100
From: Harry Halpin <hhalpin@w3.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Watson Ladd <watsonbladd@gmail.com>
References: <CA+Vbu7ye3bytMZ-j8pfZixrjF8irTOoWmRo_GwjB0LphwjXq+Q@mail.gmail.com> <20141202092847.29027.qmail@cr.yp.to> <CA+Vbu7yQoYf3ei3MADhJ1iV6BcuqVUmkg8SkQ4ud=8m7pz7AvQ@mail.gmail.com> <D0B0DC9F.39BD0%kenny.paterson@rhul.ac.uk> <CACsn0c=uyPT6xa4CsXPeAV31QeeO+HfsCXAxt7Ba6NOt_Y2hiA@mail.gmail.com> <CABqy+sr1T-VwQx1NaRA+xvnqVn7smjs2+YrG2Uz1Q+8M6c3hng@mail.gmail.com> <D0B8EDCF.3A504%kenny.paterson@rhul.ac.uk> <CACsn0cnkdjEPGZ5Q1Nm+6OZJVdoj6X-ksc0X_atavQ+610MkXA@mail.gmail.com> <D0B9A74B.3A60D%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D0B9A74B.3A60D%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/t46KqJsGMyJNU4vyPlmt6RHPdIM
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 12:44:43 -0000
On 12/19/2014 11:45 AM, Paterson, Kenny wrote: > Dear Watson, > > On 19/12/2014 04:52, "Watson Ladd" <watsonbladd@gmail.com> wrote: > >> On Dec 18, 2014 12:52 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> >> wrote: >>> >>> Dear Robert, >>> >>> I am going to respond to some of the early points in your message below >>> on >>> behalf of the chairs. Separately, Alexei will respond to some of the >>> other >>> points. Between us, we may not cover everything in your long e-mail. I >>> apologise in advance if this is the case. >>> >>> On 14/12/2014 21:16, "Robert Ransom" <rransom.8774@gmail.com> wrote: >>> >>>> I second Watson Ladd's concern about the chairs' apparent preference >>>> for adopting a document based on draft-black-rpgecc-00 instead of >>>> draft-turner-thecurve25519function-01. >>> >>> Note that the documents are not directly comparable, as you seem to >>> imply >>> here. draft-turner-thecurve25519function-01 specifies a particular >>> key-agreement scheme based on Curve25519. draft-black-rpgecc-00 >>> specifies >>> a curve generation method that can, inter alia, generate curves at a >>> variety of security levels. Its output is not directly usable by >>> implementors, of course, and more work would be needed by this group to >>> take its output and make it suitable for delivery to the TLS WG, >>> assuming >>> that this is the direction CFRG wants to go in (an assumption I am not >>> making at this stage, but something that I will happily admit that I do >>> hope will happen given the way in which this group has been deadlocked >>> for >>> some time now). >> >> The requested modification to draft black makes it generate curve25519 >> as I understand, but with potentially different generators. If this >> request is met, and we add the description of the algorithms, we will >> arrive at the contents of draft-turner25519. Why not start there? > > We could indeed have done that. On the other hand, I believe it's more > appealing to agree on a rigid curve generation method and then recommend > its outputs, delivering that along with appropriate implementation advice. > Perhaps we can even borrow some text from draft-turner25519 to speed > things along? Is some of that reusable, do you think? Indeed, I think this approach squares the circle by allowing Curve 25519 as well as the other "security levels" to be generated. If we could *merge* the drafts and recommend Curve 25519 as a specific curve along with the curves at other security levels, this might finally break the deadlock. Note that W3C Web Cryptography API has a deadline as well - our deadline for CFRG making a firm decision in order for WebCrypto to add in any new curves is March 12th, which would trigger another Last Call for us. https://lists.w3.org/Archives/Member/chairs/2014OctDec/0181.html Otherwise, WebCrypto will progress without them, possibly adding them in later via an errata process. Further details on the debate here under 1.3 "Adding new elliptic curves": http://www.w3.org/2012/webcrypto/DispositionOfComments/WebCryptoDispositionOfComments.html cheers, harry > >> >> We have 6 days, or we will have missed a deadline for the second time. > > Indeed. > >> >>>> draft-black-rpgecc-00 omits several technical details of ECDH (the >>>> precise point format and handling of Œinvalid¹ public-key bitstring >>>> inputs) which the extensive implementation experience of Curve25519 >>>> has shown are needed to ensure interoperability and forward >>>> compatibility and to protect the privacy of users of ECDH >>>> implementations on the Internet. >>>> draft-turner-thecurve25519function-01 includes those technical >>>> details. >>>> >>> >>> Let me repeat. This is correct, but I don't believe it to be relevant >>> for >>> a document that is focussed on curve generation. >> >> That's not the document we were asked to produce, and it's not a >> document that will help implementors. How does a generation method >> help with addressing the request for two or three curves, at security >> levels we feel are relevant? > > It's a document that will produce what we were asked to produce, in a way > whose rigidity can be demonstrated (modulo the selection of input primes). > This is important to some people here. > > I know there are people who will object to the fact that the method was > tweaked and that the primes have been changed. Personally, though, I don't > see that tweaking in order to improve security, as motivated by remarks > made by Dan Bernstein, is a bad thing. As for the primes, there we can > argue about performance, as you eloquently do below. If there are > compelling performance reasons to change the 192-bit level prime, then we > should consider doing it. See below for more on this. > >> >>> >>> >>>> >>>> Adopting draft-black-rpgecc-00 (or a revised version) as a CFRG >>>> document, instead of (a version of) the previously existing >>>> draft-turner-thecurve25519function-01, would raise two serious >>>> concerns: >>>> >>>> * As Watson Ladd has noted, draft-black-rpgecc-00 would require more >>>> effort, and thus more time, for CFRG to modify it into a useful >>>> product than draft-turner-thecurve25519function-01 would. >>> >>> But draft-turner-thecurve25519function-01 only specifies a single ECDH >>> algorithm for a single curve. And this is not what the RG has been asked >>> to produce for recommendation to the TLS WG. Rather, we were asked for >>> curves at different security levels (and implicitly, recommendations >>> about >>> how to use those curves to do key exchange and signatures). So >>> substantial >>> work would also be needed to turn draft-turner-thecurve25519function-01 >>> into what the RG needs to produce. >> >> Changing a single constant or two is not "substantial work". I've >> asked repeatedly for input on what signature format would be >> preferred, and gotten little response: my plan this weekend was to >> write a version with signatures or a separate document. > > Timing is everything in I*TF. I think you were asking for the input at the > wrong point in the process. Worth reflecting on for the next time, perhaps. > >> >>> >>> In short, you are comparing apples and aardvarks here. >>> >>>> >>>> * Adoption of draft-black-rpgecc-00 would reward its authors, both by >>>> crediting them as authors of CFRG's resulting document and by giving >>>> them greater control over CFRG's product. It is inappropriate for >>>> IETF to reward the authors of draft-black-rpgecc-00 for submitting a >>>> document to CFRG that they knew to be inferior to a previous >>>> submission. >>> >>> This is not about rewards. It's about meeting the request of the TLS WG. >>> And I contend that it's not inferior to >>> draft-turner-thecurve25519function-01, >>> but a different beast entirely. >> >> Which one is closer to meeting the express desires of the TLS WG? The >> TLS WG does not want a generation method, but rather new curves. And >> they don't want new "curves" but rather want us to do the hard work of >> specifying a better mechanism. We've already ruled out random primes, >> and short Weierstrass cofactor 1, in some cases in the face of >> determined opposition. What's so special about the minority holding >> out for slow choices of c that we need to appease them also? > > I don't think it's really a minority - things seem more balanced than that > to me, based on my reading of the list. > > A minute ago you said that it was not hard work to specify multiple curves > and algorithms - just a matter of changing some constants! If that's the > case, then great, I'd hope you'd get involved in developing > draft-black-rpgecc-00-.txt and help do that work there, to turn it into > what you think we need to deliver. > > >> >>> >>>> >>>> The CFRG chairs have expressed a preference for adopting a version of >>>> draft-black-rpgecc, instead of a version of >>>> draft-turner-thecurve25519function. Given the above concerns, why do >>>> the chairs believe that adoption of draft-black-rpgecc as a CFRG >>>> document is in the best interests of CFRG and of the Internet as a >>>> whole? >>> >>> See above. In summary: we believe that, with some modifications to >>> enhance >>> security (to which MGN have agreed), and additional work to provide >>> guidance as to how to use these curves in specific algorithms (ECDH and >>> signatures), we can produce a document (or documents) that meet(s) the >>> request from the TLS WG. >> >> And that work has been largely done for Curve25519. >> >> Are the chairs committed to the choice of Curve 25519 at the 256 size >> at this point? Or would they like until Purim for a revised version of >> the generation method, an argument about the generators, some debate >> over picking a different protocol, and further impatience from the >> multiple working groups now blocked on our work? If we can get the >> Curve25519 work out the door, with the promise that the larger curve >> will use a similar protocol, this should buy us more time to consider >> the higher security levels. > > That would be one way of skinning this particular cat. Another way would > be to get involved with draft-black-rpgecc-00-.txt and help push it > forward. That's what the chairs are proposing. > >> >>> >>>> >>>>> I'm also surprised that we aren't using 2^389-21 for the same reasons >>>>> cited for using 2^255-19. We do not need complete agreement to go >>>>> forward. If we want a consensus result we'll still have gratuitous >>>>> incompatibilities and an unforced loss of additional performance, in >>>>> order to get one particular group on board. A process justified as >>>>> being driven by technical criteria has devolved into an openly >>>>> political horse trade, where we're supposed to be happy that the >>>>> 2^255-19 prime is used, and ignore the issues with 2^384-317. >>>> >>>> I second this concern as well. I have seen very little support in the >>>> CFRG for the 384-bit curve specified in draft-black-rpgecc-00, and I >>>> do not believe that the short discussion of 2^389-21 as a modulus for >>>> elliptic-curve cryptography constitutes a consensus of CFRG or shows >>>> that 2^389-21 is technically superior to or has implementation >>>> experience comparable to 2^414-17 or 2^448-2^224-1 as moduli for ECC. >>>> >>> >>> Here I agree with you that the specific prime 2^389-21 has not had much >>> discussion and therefore not gained consensus in CFRG. But I'm not aware >>> of any specific security or implementation concerns about it that would >>> not also apply to other "sparse" primes. Can you point to some? For >>> example, is there any reason to believe it will be any more difficult to >>> make secure against side-channel attacks than other choices at roughly >>> the >>> same security level? Is it the case that the "implementation experience" >>> that you cite for primes 2^414-17 or 2^448-2^224-1, or any other >>> pseudo-Mersenne primes, would NOT transfer to this choice of prime? It >>> would be really helpful to the group if you could be more specific in >>> expressing your concerns here. >> >> One set of concerns is how efficient it will be compared to Ed448. We >> have guesses: there is no substitute for implementations. >> >> Furthermore, the choice of bitlengths is not set in stone. If Ed448 >> could offer the same performance as the 384 bit prime, there would be >> no reason not to go for the larger, effectively free length. It >> probably won't, but until we have working implementations we don't >> know. >> >> Furthermore, accepting the black draft does not mean picking 2^389-21. >> It means picking 2^384-big, where big is sufficiently large to make >> Ed448 approximately as fast, and make vectorized implementations slow. > > Sorry, I mis-wrote here. You are quite right that the draft proposes > 2^384-317. That's what you get when your chairs are working late at night > after long days doing their day jobs.... > > I'd be grateful if the folks from the MGN team could say more on the list > why they chose this particular prime, and give some insight into the > performance impact of choosing it over near neighbours such as 2^389-21. > > Others should chime in too - for example, people should feel free to > repeat performance numbers from earlier in our discussions (they are out > there in the archive somewhere!). > > Please let's collaborate and see if we can swiftly resolve whether there > is a significant performance impact or not. > >> >>> >>>> >>>> I have a further concern regarding the intentional omission of point >>>> addition and scalar multiplication algorithms from the text of >>>> draft-black-rpgecc-00. >>> >>> I expect this *was* intentional on the part of the authors, given my >>> assumption that it was their intention to provide a clean document that >>> focusses on curve generation rather than low level details of their >>> usage >>> in cryptographic primitives. But reading on further in your message, I >>> think you mean to imply something more sinister here. >>> >>>> >>>> Instead of providing such algorithms in the text of the draft, >>>> draft-black-rpgecc-00 lists <https://eprint.iacr.org/2014/130.pdf>, >>>> which contains several scalar multiplication algorithms for those >>>> curves, as an informative reference (listed as [MSR] in the draft). >>>> (I reviewed each of the draft's references (non-RFC references were >>>> accessed on 2014-12-10); no other document listed as a reference >>>> contains a point addition algorithm for Edwards curves, and no other >>>> document that I was able to retrieve contains a scalar multiplication >>>> algorithm for any type of elliptic curve.) >>> >>> Perhaps the draft's authors would consider adding further references to >>> the extensive literature on ECC implementation, particular papers by Dan >>> Bernstein, Tanja Lange, and their co-authors (who have done so much to >>> spur the development of elliptic curve cryptography in its modern form). >>> However, I don't believe that's really the point here - this draft is >>> about specifying curves, not operations for those curves. >> >> And once again, the final product needs to be about providing working >> algorithms. Several issues with original draft for Curve25519 in TLS >> stemmed from the absence of a description of the Curve25519 function >> except in a paper of Daniel J. Bernstein. A document that merely >> contains curves, without the algorithms, does not satisfy the request. > > Agreed. > >> >> Furthermore, we still need to determine what points are sent on what >> model. Our job will not be done if we simply accept the Black et al. >> draft. > > Agreed. No-one was saying this, as far as I recall. Certainly not me. > (Please reread my messages carefully.) > >> >>> >>> However, I'd also point out - and I think this is key - that (based on >>> my >>> own reading of this patent, and heavily caveated by the usual >>> disclaimers >>> about none of us being lawyers) it's perfectly possible to implement the >>> basic arithmetic procedures (point addition, scalar multiplication) and >>> higher level algorithms (ECDH, signatures) for the curves produced by >>> the >>> MGN procedure (as for any other similar curves) without having to use >>> any >>> of the techniques that might be covered by this patent. After all, the >>> curves it produces are Edwards form, or twisted Edwards form, so I would >>> assume that the extensive code that is available under generous open >>> source licences would be directly usable here. >> >> Much of that code assumes that the addition law is complete. On the >> new curves in the recent draft, I believe this assumption is >> satisfied. However, the original NUMS submission presented an >> algorithm that infringed on the patent. While it would be possible to >> avoid the patent, the cited reference and presentation made in April >> suggested an algorithm that ran smack into the patent. The new draft >> makes it substantially easier to avoid the patent, by permitting >> complete addition laws. > > Well, that's good then, no? > >> >> <snip> >>> >>> It's not about rewarding any one or any organisation with anything. >> >> Really? The entire argument for this "compromise" assumes that the >> authors of the NUMS draft have something to offer in return for our >> accepting a slower prime at the 384 bit level. They don't: > > I think the draft does have something to offer: a well-defined, repeatable > process for generating curves that meet all the identified security > criteria. The choice of prime then becomes a performance question (given > the current state-of-the-art in our knowledge about the DLOG problem). > > But you are right to ask what the performance impact is of the particular > choice of prime 2^384-317. Let's try to hash that out with solid numbers. > >> IETF >> working groups (and I imagine IRTF working groups) regularly reach >> conclusions in the face of vocal opposition, in most cases far more >> valid than the objections of Benjamin Black to special primes. For >> example, this working group has decided to proceed with a last call on >> a PAKE that doesn't have a security proof. The TLS WG decided to >> pursue ALPN over NPN, despite concerns about client fingerprinting vs. >> server fingerprinting. I am certain there are more decisions of a >> similar nature to be found. I don't think these are commendable >> actions, but I do think that we should consider the relative merits of >> 2^384-big vs 2^389-21, regardless of the loudness of the supporters of >> one side or the other, and should be aware of what the basis for >> making a decision actually is. > > I agree. I was temporarily confused about which prime was in > draft-black-rpgecc-00-.txt. That was really unhelpful of me. > >> >> Remember that we are effectively committed to recommending Curve25519. >> Any argument about the superior "rigidity" of 2^384-big has to imagine >> someone unwilling to accept 2^389-21 for exactly the same reasons they >> accepted 2^255-19, namely the extremely limited number of primes of >> this shape. > > I agree. (Wow, all this agreement suddenly breaking out!). Above, I've > asked for a discussion on this very point, focussing on the relative > performance of the options 2^389-21 and 2^384-317. Let's see if we can > resolve this quickly. > >> >> If the leadership is committed to compromise for the sake of >> compromise, so be it. But logrolling is not the same as rough >> consensus, and the IETF rules clearly and explicitly point this out. >> Nothing has changed about the relative performance of 2^384-big vs >> Ed448 since April. The choice of 2^389-21 vs. Ed448 is more difficult: >> my instinct suggests the smaller, > > Let's get past instinct to hard numbers. > >> with Ed448 and E521 as options for >> those who desire significantly more security. >> >> Sincerely, >> Watson Ladd > > Likewise, > > Kenny > > >> >>> >>> >>>> >>>> >>>> Robert Ransom >>> >>> Regards, >>> >>> Kenny (on behalf of the chairs) >>> >>> >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >
- [Cfrg] Consensus and a way forward Benjamin Black
- Re: [Cfrg] Consensus and a way forward Watson Ladd
- Re: [Cfrg] Consensus and a way forward Joppe Bos
- Re: [Cfrg] Consensus and a way forward Hannes Tschofenig
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] Consensus and a way forward Ilari Liusvaara
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Adam Langley
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Mike Hamburg
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] Consensus and a way forward Paterson, Kenny
- Re: [Cfrg] Consensus and a way forward Paterson, Kenny
- Re: [Cfrg] Consensus and a way forward Paterson, Kenny
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alexey Melnikov
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Michael Hamburg
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Robert Ransom
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Adam Langley
- Re: [Cfrg] Consensus and a way forward Lochter, Manfred
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Ilari Liusvaara
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Robert Ransom
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Watson Ladd
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Tony Arcieri
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… D. J. Bernstein
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Robert Ransom
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Watson Ladd
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paterson, Kenny
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alyssa Rowan
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Watson Ladd
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Benjamin Black
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Robert Ransom
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paul Hoffman
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alexey Melnikov
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paterson, Kenny
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Alexey Melnikov
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Watson Ladd
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paterson, Kenny
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Harry Halpin
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paul Hoffman
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Watson Ladd
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Tanja Lange
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Salz, Rich
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Tony Arcieri
- Re: [Cfrg] Mishandling twist attacks D. J. Bernstein
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Paterson, Kenny
- Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Conse… Tanja Lange
- Re: [Cfrg] Mishandling twist attacks Paterson, Kenny
- Re: [Cfrg] Mishandling twist attacks D. J. Bernstein
- Re: [Cfrg] Mishandling twist attacks Salz, Rich
- Re: [Cfrg] Mishandling twist attacks Stephen Farrell
- Re: [Cfrg] Mishandling twist attacks Adam Back