Re: [Cfrg] big-endian short-Weierstrass please

Tony Arcieri <> Wed, 28 January 2015 23:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 875F71A6FE9 for <>; Wed, 28 Jan 2015 15:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XnGXcaDJJr5H for <>; Wed, 28 Jan 2015 15:32:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9ED0A1A6F20 for <>; Wed, 28 Jan 2015 15:32:31 -0800 (PST)
Received: by with SMTP id h136so21316656oig.9 for <>; Wed, 28 Jan 2015 15:32:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4sSHECBehLI9X3LzHAIy/h54US2N/+SaIGQ7xq0yzJU=; b=GIdggoB+tuvDNvQWRUL4+NlYHOQSkgIk4TeA9voGnwgUWQC7ZvjdoV3d/U/LPhdHcX 9NlFiGUfdBKVwL8qBlzGKCskpSv4yA/YnUuLuChLPCYjTMbOwV94pR0ms0p/qBckTues qqbJ193sh5Rd46scKyiGsWgC7XhM+EdRoh2waQbGBdrlH0mMgnNdwG//+Amj8YFrX4+9 Hs4ZHGkj/ZpHiAu7EUPpYB0n+oXBIxKLUPqbnIt/ysLLYaJG5Q+YtGi4QYKmea4gvI7j xofzxMYMZ4xA8L1TbWviJWYNSkGokWwNY8XW1TZ6xM5jgYlJ2RCBuXCHu0pIUYQ27jW4 QdDw==
X-Received: by with SMTP id q12mr3816378oey.54.1422487950935; Wed, 28 Jan 2015 15:32:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Jan 2015 15:32:10 -0800 (PST)
In-Reply-To: <>
References: <>
From: Tony Arcieri <>
Date: Wed, 28 Jan 2015 15:32:10 -0800
Message-ID: <>
To: Dan Brown <>
Content-Type: multipart/alternative; boundary="089e0115faf2034fa4050dbec945"
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
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: Wed, 28 Jan 2015 23:32:33 -0000

On Tue, Jan 27, 2015 at 7:41 AM, Dan Brown <> wrote:

> I appreciate that currently, TLS is thinking to use Curve25519 a named
> curve, specified by an OID, and then determine all point representations,
> including the internal used ones used in the KDF and signatures, based on
> the named curve.  That should work too for TLS and any easily updatable
> software.
> But I wonder if there are any old implementations of the standards I
> listed above, that accept generic specified short Weierstrass curves, but
> lock together the KDF and raw ECDH operations.  Users stuck with such
> implementations couldn’t gain _*all*_ the benefits of Curve25519, side
> channel resistance or whatever, but surely there’s some residual benefits
> for them to use Curve25519 with a generic representation: maybe the
> rigidity Curve25519, or interoperability with other users with the
> newfangled software, not to mention the blessing of the collective wisdom
> of CFRG.

I *strongly* oppose this entire proposal.

For D-H, Montgomery x-coordinates are way less error prone. Field
arithmetic bugs in Weierstrass implementations are common, and furthermore
old Weierstrass implementations that need to interoperate with Montgomery
x-coordinate representation can convert to Weierstrass. For signatures we
should be using Edwards for similar reasons.

My employer is doing something of this nature I can't disclose and it is
working quite well for us. That is just my personal opinion: I am not
speaking on behalf of my employer.

If you accept that we should be using Montgonery x-coordinates and Edwards
group elements to represent public keys (for D-H and signatures
respectively), then we get to djb's recent arguments that big endian is
more error prone.

Big-endian short-Weierstrass is the the most error-prone representation we
could possibly use, and legacy implementations can easily still use more
modern formats on the wire then convert to the representation they
implement natively.

Tony Arcieri