Re: [TLS] Using Brainpool curves in TLS

Manuel Pégourié-Gonnard <> Wed, 16 October 2013 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D5A911E82A8 for <>; Wed, 16 Oct 2013 07:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cZ+Gij3K4Q8U for <>; Wed, 16 Oct 2013 07:25:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D43911E826F for <>; Wed, 16 Oct 2013 07:25:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id EB4B316153; Wed, 16 Oct 2013 16:25:11 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8EF40260A6; Wed, 16 Oct 2013 16:25:10 +0200 (CEST)
Message-ID: <>
Date: Wed, 16 Oct 2013 16:25:10 +0200
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: Tom Ritter <>, Johannes Merkle <>
References: <> <> <01b901cec9a0$004e12b0$00ea3810$> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
OpenPGP: id=98EED379; url=
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Patrick Pelletier <>, "" <>
Subject: Re: [TLS] Using Brainpool curves in TLS
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2013 14:25:33 -0000

On 16/10/2013 15:32, Tom Ritter wrote:
> I'm not sure I agree with them fully, but I also don't have very much
> context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3)
> instead of pi and e - what makes those constants more trustworthy?")
I think the point is not that sqrt(2) and sqrt(3) would be better constants that
pi, e, or any other constant. It's just that there are a few bits of freedom in
the choice of parameters, which makes the curve "not fully rigid".

This is obviously not a security concern unless you believe there is a class of
weak curves with quite high density, which would IMO be very bad news for ECC in
general, not only these particular curves.

Which is probably why the authors of the page chose a nice green color and check
symbol for both "fully rigid" and "somewhat rigid", as opposed to the
frightening red color of the other classe of curves.