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

Benjamin Black <> Tue, 02 September 2014 01:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4F591A6F3E for <>; Mon, 1 Sep 2014 18:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSKAW0OWdWCV for <>; Mon, 1 Sep 2014 18:51:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F36D61A0AF6 for <>; Mon, 1 Sep 2014 18:51:08 -0700 (PDT)
Received: by with SMTP id k48so6185135wev.28 for <>; Mon, 01 Sep 2014 18:51:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nATvutaSJQ0E9SwHDpjN1Blu39cZAWj0phtY6ZZmh9A=; b=NeF6d7XhAKMeXCgPNHCRDevKCf30eYIRRdt2ZEdvE6UplLKXfbRAiLDsPUq7GurKy9 o/iN4nklSzAvh1FOherohqJtxBGtww0UXnXI/B2RrbSluXrYrLs7vRHsDo8XaiN2W3UT TYAaxqe0lUb6ck2aLFg2i9J/qG/ztwbz2+X5yhjciqkR/kNUg7qq2/GDrxJFxIjr1hMY 9Zk3AmmV5o6XvSzVK3uhRMHSMYQchHzlkbEDVZ+QrqtIOG74UROgWRvgUgl4x8aVEDuA i4GcReoCJ0s6c8YuYnFC4iqRlshM02Z1EL6pnZDGWjnTpfyf09jD9pgGVuf6hX2494HV VVaQ==
X-Gm-Message-State: ALoCoQluWjwAmbdUcUBkQWscDdSRiCbNW+/TJ8b6Of7wl5jcwBLjYBZqpWalE0LtwVlrdXB2C+Hb
X-Received: by with SMTP id f18mr17335685wik.24.1409622667517; Mon, 01 Sep 2014 18:51:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 1 Sep 2014 18:50:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Benjamin Black <>
Date: Mon, 01 Sep 2014 18:50:47 -0700
Message-ID: <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary="e89a8f6439c65d779e05020b5ad6"
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 01:51:10 -0000

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.