Re: [Cfrg] Another perspective on the Curve256/255 problem

Phillip Hallam-Baker <> Thu, 31 July 2014 19:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D45071A0022 for <>; Thu, 31 Jul 2014 12:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3oVQOXySb4ce for <>; Thu, 31 Jul 2014 12:37:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BBDA1A000F for <>; Thu, 31 Jul 2014 12:37:25 -0700 (PDT)
Received: by with SMTP id hz20so2425390lab.22 for <>; Thu, 31 Jul 2014 12:37:23 -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:content-transfer-encoding; bh=vdrER5ysWhQ1YSloGHhBLaDHLBP4PDnNUSmK3nuwkUA=; b=WhMnMuTnygttvDDHpF+hGY73jogznwETO8eaP++aZRVJIYyNNoQZwqDdg0r+lJCM1b atjVhMHzPySfNL2zAAU0b/hj/5tV8UdgC+4aSlAYzPb2kLXJxRFKw2SYQXnKcF400qBD AY/AxhwVM+cfzX8R2NDh2UUTGqe5ZfCCIKyguCuz7n1hFh9in9C/AvyFqh8OGi+ojkYp kx4biARkdmDQrOR48dJfHImKSEYMadRxejDdYatx0wBOrQIfJuOKxVrJ3L4UJ82oH+Z9 gw+9Nn1aiJSKAwkkr4MSYBdeUQR0BvSqox/eLmYCdBshDrJZTyULNHP7PoEOft2Pz4jS Ertg==
MIME-Version: 1.0
X-Received: by with SMTP id e1mr347168lbs.81.1406835443480; Thu, 31 Jul 2014 12:37:23 -0700 (PDT)
Received: by with HTTP; Thu, 31 Jul 2014 12:37:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 31 Jul 2014 15:37:23 -0400
X-Google-Sender-Auth: MTf--yXetH5Cr0AzzoI2l1Yaf3U
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Salz, Rich" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] Another perspective on the Curve256/255 problem
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, 31 Jul 2014 19:37:27 -0000

On Thu, Jul 31, 2014 at 1:43 PM, Salz, Rich <> wrote:
>> [I am using WF128 to remind ourselves that this is a 2^128 Work Factor which
>> is what really matters here.]
> I like this notation.
>> So PKIX, S/MIME and OpenPGP should just use WF256. Which means that a
>> TLS stack is going to need the ability to do WF256.
> Can you explain this?  I don't see the "which means" justification, which means I'm missing something.

The browser providers want to limit the number of roots in their trust
stores for good reason. My customers want high security so I
definitely need a WF256 curve. But I am not going to get a WF128
factor root as well unless I give up something else and I don't want
to do that.

So the bottom line is that a TLS stack that wants to support the
WebPKI is going to need a WF256 signature scheme. But it is not clear
that a WF128 scheme is needed.

Its funny the way that when I want to add a feature to a protocol
people push back and when its algorithms I'm the one asking if they
are really necessary.

>> DJB: Speed! Speed! Speed!
> That's not how I would characterize it.  One of Dan's slides said something about removing the friction between security and performance. I wish I wrote it down, it was a brilliant insight.  The first time I've seen a real systems approach to crypto (which probably says more about my ignorance of the field than anything else).  For example, Curve25519 requires the top bit to be set, so that implementers don't expose timing attacks by skipping down until they find the first bit set.

Is there a reason that would only work for that particular curve and
not the NUMS? I wasn't seeing that as a discriminating argument. Its a
good one though.