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

Dan Brown <> Thu, 29 January 2015 16:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3FE01A1EF6 for <>; Thu, 29 Jan 2015 08:50:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZROFD7oQLH7t for <>; Thu, 29 Jan 2015 08:50:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E4BD21A1A9B for <>; Thu, 29 Jan 2015 08:50:12 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 29 Jan 2015 11:50:05 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 29 Jan 2015 11:50:04 -0500
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([::1]) with mapi id 14.03.0210.002; Thu, 29 Jan 2015 11:50:04 -0500
From: Dan Brown <>
To: "''" <>, "''" <>
Thread-Topic: [Cfrg] big-endian short-Weierstrass please
Thread-Index: AdA6QfeHnVWfJGNlTzek7rmrn4E15gBEvvUAAAkmA5D///TDAIAACxgA//+0JACAAW5uAIAAUxDQ
Date: Thu, 29 Jan 2015 16:50:04 +0000
Message-ID: <>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0071_01D03BB9.B84E1D60"
MIME-Version: 1.0
Archived-At: <>
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: Thu, 29 Jan 2015 16:50:15 -0000

> -----Original Message-----
> From: Cfrg [] On Behalf Of Daniel Kahn Gillmor
> Sent: Thursday, January 29, 2015 11:30 AM
> To:
> Subject: Re: [Cfrg] big-endian short-Weierstrass please
> On Wed 2015-01-28 18:38:49 -0500, Blumenthal, Uri - 0558 - MITLL wrote:
> > The problem is - reasonably-vetted by who? NIST? DJB? Yourself? All of
> > the above?
> If this lengthy process we're involved in doesn't turn out to be reasonable
> vetting by a multistakeholder group, i'll be sorely disappointed.
> > Attractiveness of the ability to select a custom curve is similar to
> > that of PGP Web of Trust: you can make a choice for yourself, rather
> > than being forced into what other experts (or “experts” :) decide for you.
> This is different from the PGP Web of Trust.  If i'm communicating with a new
> peer using TLS, and they want to use MagicCurveX that i've never seen before,
> my TLS client is not going to be able to evaluate it properly, certainly not before
> the TLS handshake expires.
> Anyone can of course decide what curves are worth using, and can apply their
> own analysis with their peers to come to that decision.  But if you're
> communicating with the arbitrary outside world, there needs to be some
> broader consensus about which curves to commonly use.

[DB] Isn't TLS 1.3 proposing a DH group negotiation mechanism, where peers could configure their supported set of (EC)DHE group, then at run-time find something in the intersection of their supported curves?  Having an option to fully specify a custom curve in this mix is not requiring any peers to support MagicCurveX.  

> The act of naming and identifying the curve doesn't mean it's good, of course;
> We have named codepoints for curves insufficient for modern cryptanalysis, like
> sect163k1.  But you're right, people should be able to use curves internally that
> no one else has to weigh in on.
> fortunately, we can already do that (at least in TLS); we have a range of the
> codepoints set aside for private use (RFC 4492):
>   Values 0xFE00 through 0xFEFF are reserved for private use.

[DB] Wouldn't users of these private values have to then customize their software this?  Well, I guess TLS would work for that.  So, it seems that the advantage of specified curves, is that if a trustworthy WebSiteABC TLS server, elects to use MagicCurveX, then anonymous TLS clients could connect to WebSiteABC, relying on the current trust of the WebSiteABC, and their own software.