Re: [Cfrg] Curve manipulation, revisited

Adam Langley <> Thu, 25 December 2014 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E2261A885E for <>; Thu, 25 Dec 2014 12:51:29 -0800 (PST)
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 PKe4BZ2eQ8fK for <>; Thu, 25 Dec 2014 12:51:28 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD1081A885D for <>; Thu, 25 Dec 2014 12:51:27 -0800 (PST)
Received: by with SMTP id w7so8101603lbi.16 for <>; Thu, 25 Dec 2014 12:51:26 -0800 (PST)
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=mb152uMjxyEvvk4vqmgXeFKtP1AOWLFmNIFQIZz+Raw=; b=MwBPZvPJosNk558ggHmCZboVRW1ecqPl1XNGxs8rmIKEnTzdpmaMNPHrgHvlgiH15O 1o66MaxXcdk2glbApwaRDEdd6Pf3Hi3Ix/rORYarjFysiYH9G5wG1e37PH1oXPKPDYZf fhFCZtDr26N6PlSquzdcjAIwk/2JrYOeBq5149pl7ujTZrkUYwjuuDPN+SOl4Io/2lIb sAxIUE4NFONHTF8PpKBacISaoP8r+dgCWZTTmmQK3+DndMPfqzaAK/N3T1ICbRqYOdcU df1jjYoncBmHH4Akemm+Wklf7P72xMdKsFky2Yckhf/blQNK6JrLuWLuG7dOnFeNdWSF x1ew==
MIME-Version: 1.0
X-Received: by with SMTP id ug7mr40464407lbb.73.1419540685899; Thu, 25 Dec 2014 12:51:25 -0800 (PST)
Received: by with HTTP; Thu, 25 Dec 2014 12:51:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 25 Dec 2014 20:51:25 +0000
X-Google-Sender-Auth: CsTV8UtcMRBxR7-CY-C9kdGuNIo
Message-ID: <>
From: Adam Langley <>
To: Watson Ladd <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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: Thu, 25 Dec 2014 20:51:29 -0000

On Thu, Dec 25, 2014 at 7:33 PM, Watson Ladd <> wrote:
> It's important not to confuse "rigidity" with actually constraining
> the choice of curve meaningfully. The question is not how many curves
> can be generated, but how many curves the user will accept.

Certainly. Indeed, rejecting curve25519 because of "rigidity" appears
to me to imply accepting that:

1) There are numerous, devastating pitfalls in the space of
sensible-looking curves.
2) And yet, nobody has ever caught even a glimpse of them.
3) And yet, they are dense enough that someone could easily steer a
curve into one.
4) And yet, not so dense that one can't steer a "rigid" curve into one.

That seems like codswallop to me, and possibly to Microsoft too.
However, I think it's understandable if Microsoft have a bunch of
customers who do not specialise in cryptography and yet look with
suspicion at every decision Microsoft make in this area, and thus MS
want to make as few as possible. (I wish MS had generally been more
communicative about their motivations on the list so that I didn't
have to guess.)

It would be nice if we didn't have to worry about such shoddy
suspicions. (Microsoft might feel the same.) But, as I mentioned,
failing to reach agreement with Microsoft would be a bad outcome.

> Exactly. It is now the deadline: are we going to miss it because we
> cannot get the 128 bit level out, despite unanimity on what it should
> be?

I would very much welcome it if we could work on trying to get
curve25519 out the door. I'm sure that there are still things that
people can disagree about but everyone appears to be within an isogeny
of a common place.

> Basepoints and isogenies don't change security: if the Microsoft curve
> is isogenous to Curve25519, why not use Curve25519?

At the moment, because of a desire for a single curve-generation
procedure, I think. Adding special cases to steer the output to match
curve25519 is distasteful and looks like rigging the procedure. (Of
course, from a security point of view, that's nonsense. I've also not
seen anyone outside of MS express the opinion that a curve-generation
procedure is even desirable. But, to make progress, people need to try
and understand Microsoft's position.)

(I'll deal with the argument about the value of a large curve in a
different email becasue Davil Gil has a reply on that topic too.)