Re: [Cfrg] ECC reboot
Alyssa Rowan <akr@akr.io> Thu, 23 October 2014 17:41 UTC
Return-Path: <akr@akr.io>
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 D94D41A8AA9 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 10:41:08 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 dK0RJKnjxaEl for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 10:41:05 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265591A8AD2 for <cfrg@irtf.org>; Thu, 23 Oct 2014 10:41:05 -0700 (PDT)
Message-ID: <54493DB1.5070204@akr.io>
Date: Thu, 23 Oct 2014 18:41:05 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <54400E9F.5020905@akr.io> <CAMm+LwhVKBfcfrXUKmVXKsiAMRSTV+ws+u07grmxkfnR2oYJoQ@mail.gmail.com> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <m3r3y6z3z8.fsf@carbon.jhcloos.org> <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com>
In-Reply-To: <CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/gBdBnCKTFSHmH42MimDk-aSs5uk
Subject: Re: [Cfrg] ECC reboot
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: Thu, 23 Oct 2014 17:41:09 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 23/10/2014 15:27, Watson Ladd wrote: >> I'm inclined to agree with my colleague PHB, who wrote recently: >> "The Web PKI will almost certainly be based exclusively on the >> ~512 level curve. The roots certainly will." > Previously, when given a choice of curves, the one with size 384 or > thereabouts was picked. Now you are saying you want the biggest > possible curve, regardless of the performance impact. Not wishing to speak for Rob, but what I _think_ he means here is simply that if there was one curve picked, he'd use it in principle; but given the choice between two curves (a strong fast curve, and a paranoid curve), he'd probably be tempted to go for the paranoid one for the roots? Seems sensible to me: they're the Web PKI roots, after all. They're much longer-lived signing keys than servers, and they will in practice be under sustained, well-funded attack from nation state adversaries. Under those circumstances, the more paranoid level may seem appropriate, but a server key would probably far rather plump for the strong fast curve. I echo your concerns about verification performance and secp384r1, but that _is_ a particularly ugly baby. We can do better than that, even if we pick a curve which is more secure, which is indeed the selling point of Curve41417 and/or Ed448-Goldilocks. (I actually wonder how a well-optimised E-521 would do, even. I guess we'll find out.) Future reference note: May be useful to have state-of-the-art implementations of NIST secp256r1, NIST secp384r1, NIST secp521r1 in the performance shootout as anchors? The way the sign/verify workload is on ECDSA works out well for many servers (where sign's the bottleneck) but it's a little unfortunate for roots (where verify is). > How long do you think it would take to make an HSM that supports > our choice? Depends: from what I've seen a few HSMs are flexible enough to run whatever we choose. (I'll refrain from discussion of specific vendors: it is for them to speak up if they wish.) By the way, as a matter of practicality, would we perhaps be looking at some kind of hybrid transition period where existing ECDSA-P384-SHA384 roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity certificates? How would the choice of end-entity algorithms be restrained by the signing algorithms and curves used on the roots, or not? (I appreciate that may not really be a question for here, but for upstream in TLS or PKIX.) > Is this a matter of grab an ARM chip, add some custom firmware, > bypass caps, and epoxy (say ~ 6 months), or is it a more involved > process? Yes, you _could_ indeed do that. It depends what you want out of it; whether that's a _good_ approach is another question entirely. (Epoxy doesn't really do a lot of good, by the way! <g>) But it's _certifying_ one that's the ridiculously involved process, as Philip raises. The big challenge in making a commodity security device today is not cryptography, but bureaucracy! However, I have an inkling that those who mistrust the NIST curves may not entirely trust the NIST certifications for _exactly_ the same reasons - so in practice, I wonder about its actual relevance, or the relevance of other certifications. (Besides, we're not picking NIST-approved curves here.) Transparency and open verifiability will probably be way more important in practice to what we're doing here than any government/other existing certifications. An openly-verifiable HSM would be highly desirable. > (I'm also unsure of how ECDSA handles cofactors. Will check this) I think djb posted about that one? Picking a new curve but using an old, relatively-fragile signature scheme when we know we could do better and safer now that the Schnorr patent expired seems a little silly to me, too. That's a discussion for a future date, however. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUST2xAAoJEOyEjtkWi2t6NeUQAKjXFfzlgMXOCeNBBSHoD7BI 7nrTiMTM+iGqj+5F0xwQ4KRJTmd9hf6y+MbLAv7HZGDNdVcrNOJPomnj8bQu35dd cK+C7R/Jr/JDdAC5/TOychR8IEpkfwsI5fLYwkoYHL4vwNSQ8ENAt2oGst3D3Tm3 bRKjve0vw9TzGLcn8sdEo83dkfvxW8WJjJrZ44U5gP9MElVio7yqmk4XZrw4ZIoV fAgmWXgpTciIP7yaoHkHo19JMbFkRnpmcraIcqaScf4XOUEMvF0LwyYGxkh8QiQD Cp3cPvatef+mWUoDuhvFNIVwBGJJYD/8RGlXVqWdbC/NidgUpCsHg4DYbBhLlTLT i0DTr9u1QsRGkuRa9CZuXFxAyN9jFiorYqz+F4CnCgrhWm4VYPjPT3XxZYtLshkP txVNKsrxv6N6GCa3yEjkOIdnjdZxY2p7aoa8hqz6irvWNgOORw8nVn/ZTPz3NDVj 2jDixxj1QfBWHp0VAaYv6/xt2kZTXYXcY7/vHFHoMF43O/C5n6qWgYiTmdyg3GZJ /W/Q+lYXYVgSZYSRGYFB2HfltzxJkZc0ZXFX7A2bqRcvMrnwoqn+YjI2uC1jYZXv rlTK+VZN90VtbmuFy2i+gFLpysNIHz5C1SEL9xEtYq4kOoeles14uKtVWLhwsmQ5 61tjNSHkFEAdCn17o2mL =PGsM -----END PGP SIGNATURE-----
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Paterson, Kenny
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Johannes Merkle
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Paterson, Kenny
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Ilari Liusvaara
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Andy Lutomirski
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Ilari Liusvaara
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Johannes Merkle
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Ilari Liusvaara
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Johannes Merkle
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Hallof, Andreas
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Manuel Pégourié-Gonnard
- Re: [Cfrg] ECC reboot (Was: When's the decision?) David Leon Gil
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Hallof, Andreas
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Watson Ladd
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Michael Hamburg
- Re: [Cfrg] ECC reboot (Was: When's the decision?) David Leon Gil
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Phillip Hallam-Baker
- Re: [Cfrg] Hardware requirements, Brainpool (was:… Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Michael Hamburg
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Stephen Farrell
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Watson Ladd
- Re: [Cfrg] ECC reboot James Cloos
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Phillip Hallam-Baker
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Benjamin Black
- Re: [Cfrg] ECC reboot Benjamin Black
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Michael Hamburg
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Watson Ladd
- Re: [Cfrg] ECC reboot Rob Stradling
- Re: [Cfrg] ECC reboot Alyssa Rowan
- [Cfrg] W3C WebCrypto WG Liasioning [was Re: ECC r… Harry Halpin
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Lochter, Manfred
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Ilari Liusvaara
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Lochter, Manfred
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Tanja Lange
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Lochter, Manfred
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Alyssa Rowan
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Johannes Merkle
- Re: [Cfrg] ECC reboot Rob Stradling
- Re: [Cfrg] ECC reboot (Was: When's the decision?) Ilari Liusvaara
- Re: [Cfrg] ECC reboot Watson Ladd
- Re: [Cfrg] ECC reboot Phillip Hallam-Baker
- Re: [Cfrg] ECC reboot Phillip Hallam-Baker
- Re: [Cfrg] ECC reboot Alyssa Rowan
- Re: [Cfrg] ECC reboot Andy Lutomirski
- Re: [Cfrg] ECC reboot Phillip Hallam-Baker
- Re: [Cfrg] ECC reboot Andy Lutomirski
- Re: [Cfrg] ECC reboot Ilari Liusvaara
- Re: [Cfrg] ECC reboot Michael Hamburg
- Re: [Cfrg] ECC reboot Rob Stradling
- Re: [Cfrg] ECC reboot Phillip Hallam-Baker
- Re: [Cfrg] ECC reboot Andy Lutomirski
- Re: [Cfrg] ECC reboot Watson Ladd
- Re: [Cfrg] ECC reboot Samuel Neves
- Re: [Cfrg] ECC reboot Michael Hamburg
- Re: [Cfrg] ECC reboot Michael Hamburg
- Re: [Cfrg] ECC reboot Ilari Liusvaara