Re: [Cfrg] When's the decision?

Watson Ladd <> Tue, 07 October 2014 04:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0FCA31A911E for <>; Mon, 6 Oct 2014 21:56:59 -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 q2_4o00l_2Bq for <>; Mon, 6 Oct 2014 21:56:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C5211A911B for <>; Mon, 6 Oct 2014 21:56:57 -0700 (PDT)
Received: by with SMTP id t59so2648692yho.15 for <>; Mon, 06 Oct 2014 21:56:56 -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:content-transfer-encoding; bh=ZOmymMqLHIFkPREPhyiAavzLjBKUYPPyJ3Xm2N04HoA=; b=sYngJq3wmqVZklVSz6sMEVfsW1+gjVoATfae4UlonfRPlAhDxKeRvx41VQuFju+2U5 XvNktY0wyMn9E7788ir0v4KhgPiOk/xMUwhNTtn+RJnZTaVWL/FclC5zg/2wwuCXXyLE 3tN9OyuwzJo7G/jA+Mz26Jd8VjyKWIznncfns+0Rt8YlHxeL1t18rQguQsB456JV5kxW obhvDhuvQ77SkEiJA/ixmknb0yNM3Lpqwa304+sykYtkx1IJSPgrnoTIZ7lOnynMWo/q G/vwRLeC3R1tKGfTJN9KfvEd2kKIUHIDEV0TcJ/qPhkRwLdhQOHwf5GeDDzN9emG2k5y AOAA==
MIME-Version: 1.0
X-Received: by with SMTP id t80mr2093468yha.49.1412657816618; Mon, 06 Oct 2014 21:56:56 -0700 (PDT)
Received: by with HTTP; Mon, 6 Oct 2014 21:56:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 6 Oct 2014 21:56:56 -0700
Message-ID: <>
From: Watson Ladd <>
To: David Jacobson <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] When's the decision?
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, 07 Oct 2014 04:56:59 -0000

On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson <> wrote:
> On 10/6/14, 4:28 PM, Watson Ladd wrote:
> On Oct 6, 2014 8:57 AM, "Stephen Farrell" <> wrote:
>> Hiya,
>> On 06/10/14 16:53, Yoav Nir wrote:
>> > They’re all good enough
>> Tend to agree. But CFRG, pretty-please don't pick them all!
> This ignores the significance of choices such as which coordinates to use on
> the wire, whether to use compression, and which signature scheme to use.
> These are not make or break items, and any curve could be used several ways,
> but these issues do not go away with the choice of curve.
>> If you do we'll just have to pick elsewhere (e.g. saag or
>> specific IETF wgs) with less clue immediately involved.
> Agreed: the buck stops here.
>> S.
> I've implemented elliptic curve systems quite a few times.  But never with
> compression.  (The patent just expired.)  Could someone with experience
> implementing compression and with the short list of candidates, comment, for
> each curve, on how much of a hassle compression is to write, how much it
> expands the code, and how much it slows down the computation?

Huh? The choice of formula doesn't have much of an impact. For any
prime not 1 mod 8, a single square root is pretty quick: equivalent to
a single modular exponentiation. Compression doesn't add much time.

Montgomery form never needs compression: the question is whether
Edwards points should be compressed. This reduces the size of
signatures, but isn't as critical for security as
compression/validation of points for use in ECDH.

The code bloat is another addition chain, but you can probably take
advantage of the relation between (p+1)/4 and p-1 when code size is a

Watson Ladd

> If the hassle, code bloat, and slowdown are minor, I suggest we just do
> compressed.  (Rationale:  Compression is always a win so do compressed.
> Keep it simple---no options)
> If the hassle, code bloat, or slowdown are considerable, I suggest we
> require uncompressed and make compressed optional.  (Rationale:  Compression
> is sometimes a win, e.g. for applications were bits on the wire are
> precious, and sometimes a lose.  For guaranteed interoperability there
> should be one variant that is always there, and that one should be the
> simpler, smaller.)
> This probably interacts with the on-the-wire representation.  That will make
> the deciding a bit harder, but such is life.
>    --David Jacobson

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