Re: [Cfrg] ECC reboot

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 23 October 2014 14:43 UTC

Return-Path: <hallam@gmail.com>
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 CE6201A9134 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 07:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEfw8CI6QcF5 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 07:43:23 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417E41A90F5 for <cfrg@irtf.org>; Thu, 23 Oct 2014 07:43:23 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id 10so959795lbg.32 for <cfrg@irtf.org>; Thu, 23 Oct 2014 07:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=81ubOhXcNyMjxnj0+Gnn/mlj6U8Ib/DmKYS7+4PMShs=; b=UPjc6aoi7knAAjWJozhAyIN6Sk8LiBkDT6954fdtwS5IC5GZ86+VX/K1yWGgew+uYq VfSpUMP7YwA0fKdWAY/OXvlECrizryFipy+QAznVpPGxmr4jkAGSQs+yeCV8uXU7pRiE UcLa4CwCcss9wZjHfTkznQmEl/XhL2tccxrBj79b3ZYpb9ZnZXmXhPE0AF8Pu3OhSksm 7YCgCMb9Z/5JYswrjChsTr9R+KqGYPZEKpAxpvi9yn+Wp5N9rmMSFo1DK0CrPyqmBsV0 UEZZd6BlRs2fTF7+cS0vxd7z+g8xBHHOjNQvDLafiFqoSot9yWlDooGq7RzkBTj00xlC 64qg==
MIME-Version: 1.0
X-Received: by 10.112.125.33 with SMTP id mn1mr3528491lbb.99.1414075401370; Thu, 23 Oct 2014 07:43:21 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.66.196 with HTTP; Thu, 23 Oct 2014 07:43:21 -0700 (PDT)
In-Reply-To: <5448DBE2.10107@comodo.com>
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>
Date: Thu, 23 Oct 2014 10:43:21 -0400
X-Google-Sender-Auth: GBzReJ1X96JKI5xdAU47GNZA5Ls
Message-ID: <CAMm+LwhBr885gknAHrNk84Vya5RhczDTAja3eECdLRThAB9RGw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: multipart/alternative; boundary=089e0116136afc05d705061815f6
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/KmLmzg_5-s__7NpZwfCqUZAtlls
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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 14:43:26 -0000

On Thu, Oct 23, 2014 at 6:43 AM, Rob Stradling <rob.stradling@comodo.com>
wrote:

> On 20/10/14 14:05, Alyssa Rowan wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 20 October 2014 10:40:47 BST, Rob Stradling <rob.stradling@comodo.com>
>> wrote:
>>
>>  When we generated our ECC root CA keys in 2008, secp384r1 seemed like
>>> the best choice.  secp521r1 wasn't in Suite B, and it seemed likely that
>>> Suite B compliance would be a requirement for some of our customers.
>>>
>>
>> Why not secp256r1? (I'm guessing the big reason was because the TS
>> profile required ≈WF192 and you wanted one root to be suitable for both
>> profiles if you could?)
>>
>
> That was certainly part of the reason.  The other part was that a
> competitor had already chosen secp384r1, so it seemed safest to follow
> suit.  :-)
>
>  It's a bit early to say, but (open question to all) if we picked one
>> curve at ≈WF128, would you in principle be comfortable with having roots of
>> that strength?
>>
>
> 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."
>
> The various browser root programs place limits on the total number of
> roots per CA.  So whilst a ≈WF128 root could be useful, I think there's a
> very good chance that we won't have the option to embed both ≈WF128 and
> ≈WF<paranoid> roots.


Just to clarify here since the nomenclature tends to switch between WF and
bits.

I think we will end up at 512 bits which is actually rather more than
 ≈WF256 but is considered ≈WF256 because the rule of thumb is to halve.

Perhaps if we call it P512?

Marketing might seem a trivial issue but what we are talking about here is
how do we make the ECC story an easy one to explain to the non technical
and how do we come to one choice for the industry that has a good chance of
sticking.


I can form a really good argument for P512 and either P256 or P255 that
won't get any objections from the non-technical and the only complaints
from technical folk will be on performance grounds:


* WF 128 is generally considered to be sufficient unless the algorithm
itself is compromised by a new attack

* WF 256 is the largest work factor currently supported by industry
standard algorithms.

* P256 is a very round number
* P255 is almost P256 and can be considered an established algorithm

* The field has generally favored bit sizes that are a power of 2. Using
powers of 2 provides maximum compatibility with general purpose hardware
which has progressed from 8 to 16 to 32 to 64 bits for general arithmetic
operations with some architectures supporting 128 bit floats and 512 bit
integers. Data paths are up to 512 bits.

* Going just above a power of 2 means a more complicated implementation. In
particular code optimizations are now different depending on whether we are
on a 32 or 64 bit machine.


If we get into discussion of performance then we are on a slippery slope.
We have admitted that we are accepting a tradeoff for a start. And we have
to explain that it is the work factor ratio that is important and all sorts
of things.

The objective here is to arrive at a set of curves that everyone is
confident are secure and do not appear to be odd in any way.

Curve 255 is being widely used because the implementation is so short, the
speed is probably secondary.

To implement P512 fast I would write a 512 bit fixed size bignum library.

To implement P521 fast I would have to write a 544 or 576 bit bignum
library depending on the architecture.

Those 9 extra bits are actually a heap of extra complexity.