Re: [Cfrg] draft-agl-cfrgcurve-00 point format (was: options)

Alyssa Rowan <> Sat, 10 January 2015 12:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86E9A1A875B for <>; Sat, 10 Jan 2015 04:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id evJGMsKmJtck for <>; Sat, 10 Jan 2015 04:34:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 954131A1EED for <>; Sat, 10 Jan 2015 04:34:57 -0800 (PST)
Message-ID: <>
Date: Sat, 10 Jan 2015 12:35:26 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Cfrg] draft-agl-cfrgcurve-00 point format (was: options)
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: Sat, 10 Jan 2015 12:35:00 -0000

Hash: SHA512

On 09/01/2015 20:51, Andrey Jivsov wrote:

> Hello Stephen. I agree in general that fewer options is a good 
> thing.

Agreed there too.

> A single format across security strengths and algorithm types means
> fewer options.

Now, the upstream WG asking for these curves has actually already
covered this point (if you'll excuse the pun!).

The TLS WG discussed point compression specifically¹ and thought there
was value for TLS 1.3.

In Hawaii² they decided to use uncompressed points for existing NIST &
Brainpool curves (due to the inertia you noted, and the now-expired
patent, essentially nobody used compressed points with the NIST &
Brainpool curves) - but to allow new curves (i.e. us) to define their
own wire format individually, which is what is done in the draft, and
that this could be compressed. (X25519, as Curve25519, was in fact
specifically raised within that discussion³.) So…

> …the point representation negotiation defined in TLS…

…is being removed from TLS 1.3. And we can do pretty much what we want.

> (If you like Montgomery ladder, just ignore the other 32 bytes 
> representing the y; one shouldn't care about 32 bytes in a ~4Kb TLS
> handshake).

"Ignore it if you like" is just an option (to ignore it) in a fancy hat.
Drawback: fingerprinting. An attacker can tell which ignore y and which
don't (and therefore which might have omitted or screwed up a vital
validation step).

I also note patent US6563928 appears (to me, and others) to claim on
point validation to avoid small-subgroup attacks⁴ in some contexts. Dan
Brown disclosed this patent previously on the list, querying whether it
may impact twist security⁵. It expires (I believe) mid-May 2015 - and I
(again) do not specifically address its applicability or validity here,
merely note the concerns.

djb, in Curve25519, specifically used the point format from Miller
[1986], and deliberately doesn't compute y. So…

> …the de-facto standard on the Internet is to use uncompressed 
> point.

…the de-facto standard for _this curve_ is to use _compressed_ point, as
in the draft. It:

• is simpler as it doesn't need a (critical) point validation check;
• seems to have clearer IPR, because that check may have patent claims;
• is slightly smaller; and,
• is already supported by all the widely-deployed code for this curve.

No sale on a change there, as far as I'm concerned: I don't see the
significant benefit.

> I would say that I care about 10% because Curve25519 Montgomery 
> ladder is ~60% faster than P-256 on modern x86.

Um, perhaps I just haven't had enough tea this morning to follow what
you mean here?

I'm also not sure the performance gap is that wide anymore, see Intel's
nistz256 contribution to OpenSSL.


Footnotes (for easy reference):

[1] <>


[3] <>

[4] US6563928, Menezes-Qu-Vanstone, Certicom

[5] <>
although you may find it easier to read
<> and
down. Short answer: no.

[6] <>

- --