Re: [Cfrg] Hardware requirements for elliptic curves

"Lochter, Manfred" <> Mon, 15 September 2014 10:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C11F1A0B01 for <>; Mon, 15 Sep 2014 03:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.201
X-Spam-Status: No, score=-8.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IO4SErTsWaCK for <>; Mon, 15 Sep 2014 03:53:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADA441A0AFA for <>; Mon, 15 Sep 2014 03:53:44 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id s8FArg65017706 for <>; Mon, 15 Sep 2014 12:53:42 +0200 (CEST)
Received: (from localhost) by (MSCAN) id 5/; Mon Sep 15 12:53:42 2014
X-P350-Id: 20b6296a531a5abe
X-Virus-Scanned: by amavisd-new at
From: "Lochter, Manfred" <>
Organization: BSI Bonn
Date: Mon, 15 Sep 2014 12:53:28 +0200
User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c)
References: <> <> <>
In-Reply-To: <>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <>
X-AntiVirus: checked by Avira MailGate (version:; AVE:; VDF:; host:; id=28090-BMjEr5
Subject: Re: [Cfrg] Hardware requirements for elliptic curves
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: Mon, 15 Sep 2014 10:53:49 -0000


you are right when you assume that Brainpool users can live with what they 
have, if Brainpool-like curves will be mandatory to implement for TLS 1.3.

If this will not be the case  the crucial points are interoperability and 

Assume a server using software optimized code wants to talk to a smart card  
implementation of ECC, supporting random primes.
Which curve will be selected for this communication by TLS? 
I see three possible solutions:

a) The special prime curve is selected. This means that the smart card has to 
be certified (e.g. according to the Common Criteria) for use with this curve. 
Note that certificates usually specify which curve has to be used. 
Adding new curves increases the cost of certification. It has also turned out 
that protection of hardware implementations of ECC over special prime fields 
is more costly.
b) The random prime curve is selected. In this case the software side has to 
provide a second implementation of ECC that supports random primes. This 
leads to a small increase of cost on the software side.
c) Client and server do not support a common curve. In this case  no secure 
communication can be established. This course is counterproductive and should 
not be chosen.

A possible solution would thus be to make at least one curve over a random 
prime field mandatory (for each security level). This solution implies that 
there will be more than one standard curve. 

Manfred Lochter

__________ ursprüngliche Nachricht __________

Von:		Watson Ladd <>
Datum:	Freitag, 12. September 2014, 03:56:54
An:		Torsten Schuetze <>
Kopie:	"" <>
Betr.:	Re: [Cfrg] Hardware requirements for elliptic curves

> So I don't understand why you are asking for something that the
> brainpool curves don't already give you. We are not removing curves
> from TLS, and we already knew that FIPS users were likely to not adopt
> the new curves, so nonsupport isn't an issue. Even if we had only the
> NIST curves, and did nothing, you would be in the same position. There
> is an enormous performance benefit in software for special primes, and
> the sort of side channel attacks that require special blinding don't
> matter on servers, even if the curve is implemented on hardware.
> I think it's clear that the desired properties are different enough
> that there is no way to satisfy everyone.
> Sincerely,
> Watson Ladd
> _______________________________________________
> Cfrg mailing list

Lochter, Manfred
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Referat K21
Godesberger Allee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (0)228 99 9582 5643
Telefax: +49 (0)228 99 10 9582 5643