Re: [Cfrg] Hardware requirements for elliptic curves

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 966911A86F0 for <>; Mon, 15 Sep 2014 08:53:32 -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 Ota-9IxbYK5F for <>; Mon, 15 Sep 2014 08:53:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BA491A6F28 for <>; Mon, 15 Sep 2014 08:43:34 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id s8FFhVn8019774 for <>; Mon, 15 Sep 2014 17:43:32 +0200 (CEST)
Received: (from localhost) by (MSCAN) id 5/; Mon Sep 15 17:43:31 2014
X-P350-Id: 20b848e2303f5dc0
X-Virus-Scanned: by amavisd-new at
From: "Lochter, Manfred" <>
Organization: BSI Bonn
Date: Mon, 15 Sep 2014 17:43:19 +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=1329-ZLsQnt
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 15:53:32 -0000

__________ ursprüngliche Nachricht __________

Von:		Alyssa Rowan <>
Datum:	Montag, 15. September 2014, 14:50:33
Betr.:	Re: [Cfrg] Hardware requirements for elliptic curves

> It just doesn't look like the pendulum's swinging that way, and I can see
> why: the relatively poor performance of Brainpool-class random primes in
> software; the difficulty of securing generic elliptic curve software
> routines against timing side-channels;

Actually I don' t see your point here. Watson's mail was about special primes 
versus random primes. The use of special primes does not harden 
implementations against timing attacks. But the use of special primes makes 
additional SCA countermeasures necessary, thus increasing implementation 

> and the sheer cost-multiplication 
> potential of a proposal to mandate the option of using
> relatively-inefficient crypto near-universally across the web - including
> at CDN scale!?

What is your measure for inefficiency? Cost per Signature? Or time per 
signature? Or something different? Relatively to what?

> I think personally you'd face a massive uphill struggle 
> arguing for random curve support to ever be anything better than MAY. But
> that's something I reckon you should take over to those lists if you
> *really* want to raise it? (I'll bring marshmallows! <g>)

Can we agree on licorice?

> If your hardware is truly securely flexible, then you can adapt with no
> trouble; if it's not flexible enough to securely work with efficient sparse
> primes that also perform well in software, well, you probably need to
> consider at least updating it so it is (how is it with the NIST "Solinas
> primes"? Equally bad, one would have thought? Yet they're the most deployed
> by far...).

This is not a hardware question. Actually the problem is that curves over 
special primes need more SCA countermesures. This is also true for software 
running on a general purpose processor.
In fact the discussion here is not about hardware or software. It is about 
different hardware platforms (e.g. server, smart card) on which ECC is 
running under different attack models. 
> Also, please don't forget: FIPS 140-2 (/3?) evaluations/certifications are
> not exclusive to hardware, and neither are Common Criteria EAL*: both
> happen for certain software implementations.

Oh, really? Then you have a CC protection profile for TLS running in software 
available for review? At which EAL?

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