Re: [Cfrg] Curve manipulation, revisited

Watson Ladd <> Tue, 30 December 2014 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91C681A01F6 for <>; Tue, 30 Dec 2014 08:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yRPL-t16hsSA for <>; Tue, 30 Dec 2014 08:06:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E051C1A01E1 for <>; Tue, 30 Dec 2014 08:06:18 -0800 (PST)
Received: by with SMTP id 20so7221600yks.37 for <>; Tue, 30 Dec 2014 08:06:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sHrqZM9o/aKOuXQbFrGfQ2ZoxbuCYFIpwA8cVL0aAxE=; b=B38wFY1F3E77jn+/wuQ+FivmyqebD1w8BjO2ougRgzJfjNrZvLsULx+Z6MJ3MV8tQ8 980+TB4Q6Pl6u3aeHa7VHmo6sruxx+qr2FgnSVrwWVtDKXdFexAppbAW6iT/DTVhyAMz W4uUMSVC9fBAlQvLxDkGGlBJIZKFdw07EfncryzCHgYAV4cohiA9H9lwZxje6/1Dau0N qXmqGEQUiD6NlL9wcltb2c87LB73H2FaJrQFm+Bo4c8VsAHJI98y5hacXUV+iSOE8EMq pxj6e/BMc8e6EYLyCmYFb894prwgFeofdymzbEmfMhjCmeebNg1MC7ZE6hHagmKIlHoS reWg==
MIME-Version: 1.0
X-Received: by with SMTP id 40mr40583339yho.172.1419955578055; Tue, 30 Dec 2014 08:06:18 -0800 (PST)
Received: by with HTTP; Tue, 30 Dec 2014 08:06:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Tue, 30 Dec 2014 11:06:17 -0500
Message-ID: <>
From: Watson Ladd <>
To: Benjamin Black <>
Content-Type: text/plain; charset="UTF-8"
Cc: Adam Langley <>, "" <>
Subject: Re: [Cfrg] Curve manipulation, revisited
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: Tue, 30 Dec 2014 16:06:20 -0000

On Mon, Dec 29, 2014 at 3:36 PM, Benjamin Black <> wrote:
> On Mon, Dec 29, 2014 at 12:25 PM, Watson Ladd <> wrote:
>> I also don't see why this matters: now that Montgomery x form and
>> complete coordinates for signatures are being used, there isn't a
>> difference between the rival proposals on this point.
> Does this mean you find the draft with the additions of x-only and the
> cofactor constraint acceptable?

No, for several reasons.

2^389-21 has significant performance benefits on Haswell, 8-9% over
2^384-big, which performs the same way as Ed448. Our early
measurements were on other platforms, with relatively unoptimized
code, and didn't compare to the NUMS code you released, but to your
performance numbers. Because we used different benchmarking setups,
there was a systemic error in our cycle counts vs. yours. Now that we
remeasured your code with our benchmark, we get better numbers. (We is
misleading: Mike Hamburg did a lot more of the work then I did, and
the suggestion was Ilari Liusivaas. My sole contribution was writing a
terrible first cut, which Mike threw out for the second version)

The easiest way to get good numbers across multiple platforms would be
a SUPERCOP run. I've screwed up enough measurements to know that one
needs the same framework for as many numbers as possible, otherwise
you benchmark the testbench. But the NUMS people have made sure that
won't happen.

If you want ECDSA, use Weierstrass form. It's not ECDSA if you don't.
I get the idea of the FrankenECDSA, but I'd like to know that it would
be actually useful and speed adoption in TLS, and it relies on
implementations that have a generic ECDSA that calls curve specific
multiply functions. Maybe FrankenECDSA is useful: my guess is it
isn't, but I could be convinced. But this doesn't affect what curve to

As for customers, if they don't find Curve25519 acceptable, they won't
find a curve that's Curve25519 with a different basepoint acceptable
unless they really have no idea how things work. At this point you've
already agreed to Curve25519, modulo the basepoint, which doesn't
matter for security, but does matter for implementators. Why have this

Watson Ladd

> b

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin