Re: [Cfrg] ECC reboot

Phillip Hallam-Baker <> Thu, 23 October 2014 15:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C5BC41AC3A2 for <>; Thu, 23 Oct 2014 08:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2ZojD7YcfrN for <>; Thu, 23 Oct 2014 08:10:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D8241A8F49 for <>; Thu, 23 Oct 2014 08:09:17 -0700 (PDT)
Received: by with SMTP id pv20so1012560lab.20 for <>; Thu, 23 Oct 2014 08:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lPLJGUGiJyYUCzco7TtJd1qBHxSVWs6dCDC0VyBfbmc=; b=Rqk/KQjE02eoRus7CWyFDNv5mR7tKhyl36O4IUC3x97GtkU+kEl8J16cr1/90UhZoR rqD1Fx2sgGQme9uxwJ81Lb95KXIL6jeTsdcMqnwkr9otYNry6kd444Zx9cjIe103cjFP yIaywMW6gJAp2c71B4Me0GRgnrmGvlRevoFmIY+5mnMxiI6XRY4fVhgJfq0LXmYV0DCS Kkl4zx5JDoKUsOV3PX0XUeQp1VZfAgUMA5icYiptL6INcfSNEfLUJ5bAE045LVLNihUN 5U7aodx7azB1IHcnINrKYRoRllwRPlDTJrq0Akz39N/04YK97nm5zg13Loz1xWddknZ/ jFhA==
MIME-Version: 1.0
X-Received: by with SMTP id 10mr5987387laj.4.1414076956293; Thu, 23 Oct 2014 08:09:16 -0700 (PDT)
Received: by with HTTP; Thu, 23 Oct 2014 08:09:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 23 Oct 2014 11:09:16 -0400
X-Google-Sender-Auth: XNCAmOPzHj4RsCPGSUJRDYa1DP4
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary=089e013c65bcaa438405061872f2
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: Thu, 23 Oct 2014 15:10:15 -0000

On Thu, Oct 23, 2014 at 10:27 AM, Watson Ladd <> wrote:
> > In principle, yes, but...
> >
> >> What about if we picked two: one fast secure curve at 128 and one at
> some
> >> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which
> would
> >> you perhaps consider using when? Would you have one root at each level,
> or a
> >> shared root at the paranoid level?
> >
> >
> > 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. I've heard
> complaints that P384 is already painfully slow to verify on mobile.
> It's a lot more sensible to pick Goldilocks: just as fast as what you
> have now, but a few hundred bits bigger.

That really depends on your mobile. Whatever numbers are picked there will
always be a significant number of devices being made that are not suited to
doing repeated public key operations. There are more 8 bit devices being
made today than at any time in the past.

But equally important, nobody is looking at ECC as a fast alternative to
RSA2048 in consumer oriented devices any more. Commodity processors are
cheap enough and low power enough to do RSA2048 without breaking sweat.

> If you really needed 512, you would have already done it. So the fact
> that you haven't tells me that you don't actually need a 512 or 521
> length root key and are perfectly fine with anything above 384 in
> length. The performance of verification is an issue for some clients
> already: we don't need to make it worse.

We don't really 'need' ECC at all. Unless something happens to RSA2048 that
is unexpected, TLS is almost certainly fine for quite a few years yet.

Given the mess the NSA has created here, we have to put clear water between
our new curves and the old. It is not enough for me to be satisfied that
the system is secure. Its the general Internet population that has to be
confident that they are safe from having their crypto cracked.

How long do you think it would take to make an HSM that supports our
> choice? 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?

Vastly more involved and producing the hardware and software for the HSM is
at most 25% of the effort required.

The requirement is for a certified HSM, not just something that we are
confident is secure. This is an area where we are likely to require
assistance from NIST because they have the only widely used certification

As a practical matter it is much easier for the NIST people to add a new
512 bit curve to their stable than to add in an additional 384 curve whose
advantage over the previous curves is being demonstrably free of perfidy by