Return-Path: 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 91DA01B2AA7 for ; Thu, 22 Oct 2015 21:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 0L5qP_cdERPv for ; Thu, 22 Oct 2015 21:07:14 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8691A6F7A for ; Thu, 22 Oct 2015 21:07:14 -0700 (PDT) Received: by igbni9 with SMTP id ni9so27422386igb.1 for ; Thu, 22 Oct 2015 21:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AhAclRYx4DkGIGBDqdTcGbT1M9+5igIXwRdkTGHpElg=; b=0wgKYO5Tt8ErQjRRvZ1veGt0wX/NvMG35tffV1zatckiK81cOfqMqABr5afLtYeg0G rZ7s8JDPdz2YYVAGBp3wukn0nSEYoFyOevo6JyF8+kfCMTI7L7m8AvaiT+DIVp83FEbi OmYiOFUTTLO4jInzN2bXHd7nrfxiF4QHNs0UArSl4d8uVwFip6g+xmgEDDX05yGq0u1b DQ9shaZzAsmbzHdYJ/Y0tauDS/6lDHtSaYLXntMmurg4Jfe1RlTp4iPX/k1JdUzunnm2 sqA3DFwQkqYSj3wlNgdQPs+Qfc5w3l8nbnvhrv+oswI3j4qI7rkYUNc50MTG9fiogxq5 iHqg== X-Received: by 10.50.66.141 with SMTP id f13mr1966302igt.51.1445573234031; Thu, 22 Oct 2015 21:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.39.133 with HTTP; Thu, 22 Oct 2015 21:06:54 -0700 (PDT) In-Reply-To: <95750F19-2233-4CE9-BD91-6B1AA0C91F16@taoeffect.com> References: <95750F19-2233-4CE9-BD91-6B1AA0C91F16@taoeffect.com> From: Tony Arcieri Date: Thu, 22 Oct 2015 21:06:54 -0700 Message-ID: To: Tao Effect Content-Type: multipart/alternative; boundary=047d7bdc0dd21c857a0522bdbf63 Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] =?utf-8?q?=22Abandoning_ECC=22_=E2=80=94_Any_replies_to_?= =?utf-8?q?=22A_riddle_wrapped_in_a_curve=22=3F?= X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 04:07:16 -0000 --047d7bdc0dd21c857a0522bdbf63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, I think some context and basic fact-checking is in order. I read the Koblitz paper[1] before Matt Green blogged about it and have been discussing it with several people found it rather interesting, however much of what it describes is about the early history of ECC (particularly in the 1990s) and the "verifiably random" process used by NIST for generating their curves. I'd say Brainpool used a similar process, but it turns out if you actually tried to verify their curves they screwed up[2]. I am not sure why you are quoting the phrase "Abandoning ECC" in the subject line of your email as it appears in neither the Matt Green blog post or the Koblitz paper, and if you actually read the Koblitz paper, hypothetical claims we should "abandon ECC altogether" (actually in the paper) are countered by phrasing like "This scenario is highly implausible for several reasons" and claims that it is "preferable to use other curves (either the Edwards curves recommended by Bernstein-Lange [5, 6], or the curves being promoted by the Microsoft group [10], or perhaps some others)" which is exactly what the CFRG is doing. The "rigid" curve generation guidelines described in draft-irtf-cfrg-curves were the subject of a painful, rather long bikeshedding debate, however I think the result is a foundation for trust in next-generation ECC standards which are not susceptible to the sorts of attacks discussed in the Koblitz paper, and in fact the paper specifically calls out curves generated in this fashion as being such. The larger concern cited by both the Koblitz paper and Matt Green's blog post is that the NSA feels it is urgent to move to post-quantum cryptography. I'll quote Matt Green: "despite the fact that quantum computers seem to be a long ways off and reasonable quantum-resistant replacement algorithms are nowhere to be seen, NSA decided to make this announcement publicly and not quietly behind the scenes. Weirder still, if you haven=E2=80=99t yet upgraded to Suite B, you = are now being urged not to. In practice, that means some firms will stay with algorithms like RSA rather than transitioning to ECC at all. And RSA is also vulnerable to quantum attacks." This is a legitimate concern, and perhaps ECC is not long for this world, but if the threat is large quantum computers which can break the ECC algorithms we use today, RSA and all other "pre-quantum" algorithms will be affected too. And per Matt Green: the post-quantum algorithms are not only slow but we are still not certain of their security properties. If anything, I hope the takeaway for the CFRG is after the current ECC standardization work is done, perhaps it would be prudent to move onto evaluating post-quantum algorithms and standardizing them for use in e.g. TLS. I suspect this is probably already on the chairs' roadmap. [1]: https://eprint.iacr.org/2015/1018.pdf [2]: http://bada55.cr.yp.to/brainpool.html --047d7bdc0dd21c857a0522bdbf63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Hi Greg,

I think some context and basic fact-checking is in order.
<= div class=3D"gmail_signature">
I re= ad the Koblitz paper[1] before Matt Green blogged about it and have been di= scussing it with several people found it rather interesting, however much o= f what it describes is about the early history of ECC (particularly in the = 1990s) and the "verifiably random" process used by NIST for gener= ating their curves. I'd say Brainpool used a similar process, but it tu= rns out if you actually tried to verify their curves they screwed up[2].

= I am not sure why you are quoting the phrase "Abandoning ECC" in = the subject line of your email as it appears in neither the Matt Green blog= post or the Koblitz paper, and if you actually read the Koblitz paper, hyp= othetical claims we should "abandon ECC altogether" (actually in = the paper) are countered by phrasing like "This scenario is highly imp= lausible for several reasons" and claims that it is "preferable t= o use other curves (either the Edwards curves recommended by Bernstein-Lang= e [5, 6], or the curves being promoted by the Microsoft group [10], or perhaps some others)" w= hich is exactly what the CFRG is doing. The=C2=A0"rigid" curve ge= neration guidelines described in draft-irtf-cfrg-curves were the subject of= a painful, rather long bikeshedding debate, however I think the result is = a foundation for trust in next-generation ECC standards which are not susce= ptible to the sorts of attacks discussed in the Koblitz paper, and in fact = the paper specifically calls out curves generated in this fashion as being = such.

The larger concern cited by both the Koblitz paper and Matt Green&#= 39;s blog post is that the NSA feels it is urgent to move to post-quantum c= ryptography. I'll quote Matt Green:

"despite the fact that quantum computers seem to be a long = ways off and reasonable quantum-resistant replacement algorithms are nowher= e to be seen, NSA decided to make this announcement publicly and not quietl= y behind the scenes. Weirder still, if you haven=E2=80=99t yet upgraded to = Suite B, you are now being urged not to. In practice, that means some firms= will stay with algorithms like RSA rather than transitioning to ECC at all= . And RSA is also vulnerable to quantum attacks."

This is a legitimate conce= rn, and perhaps ECC is not long for this world, but if the threat is large = quantum computers which can break the ECC algorithms we use today, RSA and = all other "pre-quantum" algorithms will be affected too. And per = Matt Green: the post-quantum algorithms are not only slow but we are still = not certain of their security properties.
<= br>
If anything, I hope the takeaway for th= e CFRG is after the current ECC standardization work is done, perhaps it wo= uld be prudent to move onto evaluating post-quantum algorithms and standard= izing them for use in e.g. TLS. I suspect this is probably already on the c= hairs' roadmap.

[1]: https://eprint.iacr.org/2015/1018.pdf=C2= =A0
[2]:=C2=A0http://bada55.cr.yp.to/brainpool.html
--047d7bdc0dd21c857a0522bdbf63--