Re: [Cfrg] ECC reboot

Alyssa Rowan <> Thu, 23 October 2014 17:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D94D41A8AA9 for <>; Thu, 23 Oct 2014 10:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dK0RJKnjxaEl for <>; Thu, 23 Oct 2014 10:41:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 265591A8AD2 for <>; Thu, 23 Oct 2014 10:41:05 -0700 (PDT)
Message-ID: <>
Date: Thu, 23 Oct 2014 18:41:05 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Cfrg] ECC reboot
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: Thu, 23 Oct 2014 17:41:09 -0000

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.

- --