Re: [Cfrg] Progress on curve recommendations for TLS WG

Johannes Merkle <> Fri, 15 August 2014 14:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C04B1A0AE9 for <>; Fri, 15 Aug 2014 07:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.268
X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5t5pE6hNvpyi for <>; Fri, 15 Aug 2014 07:22:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A4A31A0AE5 for <>; Fri, 15 Aug 2014 07:22:45 -0700 (PDT)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id 0B2F21A0080; Fri, 15 Aug 2014 16:22:40 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id w0-bbFquI1rQ; Fri, 15 Aug 2014 16:22:31 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 7AF781A007B; Fri, 15 Aug 2014 16:22:31 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Fri, 15 Aug 2014 16:22:34 +0200
Message-ID: <>
Date: Fri, 15 Aug 2014 16:22:33 +0200
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alyssa Rowan <>,
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Subject: Re: [Cfrg] Progress on curve recommendations for TLS WG
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: Fri, 15 Aug 2014 14:22:47 -0000

Alyssa Rowan wrote on 15.08.2014 14:35:
> Respectfully, deferring choices made in the curve generation process back to ANSI X9.62 (even though it may have
> made sense at the time) doesn't alleviate any potential concerns about lack of rigidity in those choices; it merely
> means they weren't Brainpool's own choices, and no-one thought to question them at the time quite as deeply as they
> do today.
> If X9.62's choices had full, rigid, transparent explanations, perhaps this discussion would have not arisen, and in
> that vein perhaps neither would Brainpool? But they did not (and although Certicom/NSA indeed seem to have
> performed a brute-force seed search for the SECG/NIST curves, we may never be certain what all the parameters of
> that search were): so here we are.

The issue many people on this list (including me) have with the NIST curves is not the curve generation method but the
unexplained seeds. If you mean to imply that the method itself is suspicious, independent of the seeds, then this is a
position I have not yet seen expressed, and I doubt that many people will find it plausible.

Actually, this is the core of the problem with the discussion on rigidity: It is more about sense than about facts. Do
you feel comfortable with this generation procedure or with those constants, or with others? Something that you might
deem very straightforward and rigid may look arbitrary and even suspicious to others. Rigidity can not be measured
objectively. This makes it easy to argue against one or the other approach.

It is important that, whatever curves CFRG selects, anyone can feel comfortable with their rigidity and that there
will be no doubts about their security and the lack of back-doors. The BADA55 paper and the post I was responding to,
though intended to be provocative and entertaining, introduce FUD in that respect and are contra-productive. I am
quite sure that one could also construct a "one in a million curve" using a seed-less approach very similar to
curve25519, but this would only introduce more unjustified discredit and FUD.

We should focus on establishing trust not FUD.