Re: [TLS] Using Brainpool curves in TLS (Martin Rex) Wed, 16 October 2013 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C968811E8220 for <>; Tue, 15 Oct 2013 19:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.957
X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id scq-V94vEVhs for <>; Tue, 15 Oct 2013 19:52:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 002CE21F9D30 for <>; Tue, 15 Oct 2013 19:52:49 -0700 (PDT)
Received: from by (26) with ESMTP id r9G2qgsl016328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 04:52:43 +0200 (MEST)
In-Reply-To: <>
To: Nico Williams <>
Date: Wed, 16 Oct 2013 04:52:42 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
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 02:52:57 -0000

Nico Williams wrote:
> > but it is trivial to introduce backdoors into implementations of them.
> Do you mean that it's easier to backdoor implementations of specific
> EC curves than, say, RSA?  I would think that implementations of...
> just about anything can be backdoored with relative ease.

I assume that he might have meant what is also indicated on the
referenced Web Site
that it is extremely difficult to implement ECC and _NOT_ hang yourself,

It would not surprise me at all if the vast majority of ECC
implementations would be found to be vulnerable to serious
weaknesses, when carefully analyzed, and that the problems found
in the RSA part would be *MUCH* smaller in comparison.