Re: [Cfrg] On the use of Montgomery form curves for key agreement

Watson Ladd <> Tue, 02 September 2014 02:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6B3191A6F6B for <>; Mon, 1 Sep 2014 19:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rDB7hLsQINY5 for <>; Mon, 1 Sep 2014 19:05:44 -0700 (PDT)
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 F1FF81A6F66 for <>; Mon, 1 Sep 2014 19:05:43 -0700 (PDT)
Received: by with SMTP id q200so3755875ykb.9 for <>; Mon, 01 Sep 2014 19:05:43 -0700 (PDT)
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=4faFKXfRkERIPFbebL1Ya0FVICVZpxeiY2KieYg6x7Y=; b=Ejsa45QCQmd3QyNBPtufRhGehFPW0BEvVZf8QFNN+QaabmAOnjQbcaIfLxhJjR93I4 1MJlg3NifYYixNjlHWEurn+R96vQegdFYCyt3ipjwesMO5pH7cRontIcRs6zLnoS9UMT r9V0E8rrcSuLNsGSj6DpxAuH9+3HCteloHxX6sIlNN2OONeI0slFmUs0HWRmrAHSUZ61 //xq2vvVWFgMIb6PHja3UWdh0xTGeaFj1uX6WAIkqQDETmP+nEeTqIYvcOmSu14t08LC kwIwAX9rdmhRVVjB/z7/rMjeU3D3qVVGp+T4d6fmhlfUdmuW28C+1eYbIxXadCW4OJpI uKUA==
MIME-Version: 1.0
X-Received: by with SMTP id b10mr19299625yhg.91.1409623543296; Mon, 01 Sep 2014 19:05:43 -0700 (PDT)
Received: by with HTTP; Mon, 1 Sep 2014 19:05:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 01 Sep 2014 19:05:43 -0700
Message-ID: <>
From: Watson Ladd <>
To: Benjamin Black <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Cfrg] On the use of Montgomery form curves for key agreement
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, 02 Sep 2014 02:05:45 -0000

On Mon, Sep 1, 2014 at 6:50 PM, Benjamin Black <> wrote:
> On Mon, Sep 1, 2014 at 6:06 PM, Watson Ladd <> wrote:
>> >
>> > Alternatively and for the record, it seems to me that it would be
>> > perfectly reasonable for CFRG to decide to specify only Edwards curves
>> > (*not* twisted, just plain Edwards curves) as Mike Hamburg and others have
>> > suggested, and leave *all* of the optimizations as implementation choices.
>> > So whether someone wants to use twisted Edwards curves, the Montgomery
>> > ladder, some other improvement, etc., would be completely up to them.
>> Which is the case anyway: your code could implement Weierstrass
>> coordinates and interop with X25519. But leaving the choice of
>> coordinates open isn't a possibility.
>> The question we need to answer is what goes on the wire? That needs to
>> have an answer. And how the computations take place is largely
>> irrelevant, although we do need to address security considerations,
>> some of which our choice of coordinates and curve influence. What's
>> the difference between specifying twisted Edwards and Edwards from
>> this perspective?
> The various working groups and standards bodies have already answered the
> question of what goes on the wire. The TLS request was for new curves. As we
> all seem to agree implementers are and should be free to use whatever form
> they wish internally as long as the external representation is fixed, there
> is general support for specifying curves in Edwards form, and existing
> protocols all define X/Y coordinates on the wire, then I see an opportunity
> for broad consensus here.

The standards define short Weierstrass coordinates as what goes on the
wire, not arbitrary pairs X,Y. Furthermore, things like the
representability of the identity, small order points, etc. introduce
enough differences from existing practice that one has to check
carefully how well the specs deal with them.

Watson Ladd