Re: [Cfrg] ECC reboot

Ilari Liusvaara <> Fri, 24 October 2014 11:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 707881A8AB5 for <>; Fri, 24 Oct 2014 04:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5cX_tSSgMLG2 for <>; Fri, 24 Oct 2014 04:37:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6FD51A8993 for <>; Fri, 24 Oct 2014 04:37:21 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 92CCF1A2648; Fri, 24 Oct 2014 14:37:18 +0300 (EEST)
Date: Fri, 24 Oct 2014 14:37:18 +0300
From: Ilari Liusvaara <>
To: Alyssa Rowan <>
Message-ID: <20141024113718.GA21089@LK-Perkele-VII>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Cc: "" <>
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: Fri, 24 Oct 2014 11:37:26 -0000

On Thu, Oct 23, 2014 at 06:41:05PM +0100, Alyssa Rowan wrote:
> On 23/10/2014 15:27, Watson Ladd wrote:
> 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.)

There's also 416-bit prime equally fast to Ed448 prime (-> ~7% faster
scalarmult for 16 less bits of security).

> 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?

I think definitely so. I would set CPU budget for high curve at secp384r1.

This should give at least ~190 bits of security, possibly >200.

> 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).

Simple idea: One could cache CA certificate validations (and also sites
using exceptionally long keys).

There shouldn't be THAT many CA certificates out there in open internet
for that to be a serious storage challenge. And while there are undoubtedly
more in private, one typically does not see very much of those.

> > 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.)

I think this is technically possible (dunno if it is a good idea).

> > 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>)

E.g. doesn't stop EM attacks. And apparently even if software is hardened
against software attacks, it tends to be rather vulernable to EM attacks.

I would imagine such software would be written to apply heavy blinding,
at great cost for signing time. But such signing doesn't occur that

> > (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.

Heck, there are even older signature schemes that are easier
(no need for private inversion when signing).