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

Phillip Hallam-Baker <> Thu, 29 January 2015 23:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 727A71A8893 for <>; Thu, 29 Jan 2015 15:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e05Rl06_YHSU for <>; Thu, 29 Jan 2015 15:33:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 552F71A1B18 for <>; Thu, 29 Jan 2015 15:33:30 -0800 (PST)
Received: by with SMTP id pv20so20842523lab.7 for <>; Thu, 29 Jan 2015 15:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qJ2NmXwsDk9F2ZwqXFOOo2FO2NVDZfh/SJPhdNfUvJ8=; b=GU0WcsjhLdYmHckiNCg5KHxYMAgZq7RRO8atpDzF9h8cN+x0Pw/HYCBT258SVa9qGh 9+mPWwGKXrzk56Y1ZvjRCwOeHZ9m+DePcduNGHWfjXGD0qobqfT5nwH+Nq8uMkvrt2SF vPes6IsqCpwKty8Adlmcu8PmvUMs8R/kLvNsBlCLiMT4RGbFQSslUP/GsFwwVBLCFiga PB4COH/rTPtMCEJ/o2X2Dk62IxNzCaG7UDxgqcVGqrXiYtSqIlwbFTitkleY3PT5eYei KfK6QNdQF3MBPvGVeP1ydNs6DSu3St4ekvR4064s6t5/3C/VFxAYW6UHhJspn9QGw5fi CtnA==
MIME-Version: 1.0
X-Received: by with SMTP id yd2mr3771009lbb.1.1422574408742; Thu, 29 Jan 2015 15:33:28 -0800 (PST)
Received: by with HTTP; Thu, 29 Jan 2015 15:33:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <20150128231006.GJ3110@localhost> <> <> <> <> <> <> <> <> <>
Date: Thu, 29 Jan 2015 18:33:28 -0500
X-Google-Sender-Auth: g75Zekt-aT_o5qnEP-FymoNlzyY
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Blumenthal, Uri - 0558 - MITLL" <>
Content-Type: multipart/alternative; boundary="089e0112c86c4cbec6050dd2eaf7"
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: Thu, 29 Jan 2015 23:33:32 -0000

On Thu, Jan 29, 2015 at 4:28 PM, Blumenthal, Uri - 0558 - MITLL <> wrote:

> That seems irrelevant. Some people will never be convinced of some things
>> that most other people agree to.
> What is being argued against here is making room for DIY curves.
> My point is that the only way to come up with an informed decision to use
> someone else's curves is to apply a vast amount of domain specific
> expertise plus really trust the supplier to not have something up their
> sleeves.
> Unless that “somebody else” is your boss, or somebody you have informed
> reasons to trust.
> Some people (and organizations *:*) tend to trust “their” experts, and
> not trust “other” experts as much. As an example – why didn’t NSA adopt
> Russian GOST, and why didn’t Russians adopt AES? Probably not because they
> question the competence of the other side? :-)

And such people are more than welcome to make use of the existing extension
features in TLS 1.x.

If you think you have the ability to do this for yourselfs then do it.

However I should point out that for TLS 2 I think a very different approach
should be taken.

* Exactly one preferred (MUST) and one backup algorithm (SHOULD) defined in
the protocol with an algorithm numbering scheme that allows only 255 values
for each. The objective being to keep algorithm changes to once a decade.
This would require us to rev the TLS major version at least once every
other millennia.

* All other crypto to be identified by ASN.1 OID on a 'its your funeral'

The rationale for this is that the IETF currently has three types of

1) Those that we have vetted and trust.
2) Those that we have assigned numbers to
3) Those that we have not

The problem in my view is that people seem to think that algorithms of type
2 are somehow different than type 3 and this is really not the case. We do
not have the bandwidth to validate vanity crypto and algorithms like GOST
are mandated by governments who murder their citizens on the streets of
London with polonium laced teapots. So I really don't feel like giving any
accreditation to such folk.

So lets just have two types of crypto algorithm: Those we are really
confident of and those we make no comment on.

> There should be a set of “universally” accepted curves, so that when you
> want to talk to a complete stranger – both of you would use what the
> “community” considers cryptographically OK (which belongs to that small
> commonly shared set). But that’s only half of use cases.

No, actually that is 100% of the uses for the Internet. All other cases are
'network' security and that is not our problem.

One of the problems with IP everywhere is that we have ended up in a
situation where it is assumed that we have a duty to solve every type of
networking problem.

I think providing security advice to people who don't want to follow our
security advice is the first thing to stop trying to do.