Re: [Cfrg] ECC reboot (Was: When's the decision?)

"Hallof, Andreas" <> Fri, 17 October 2014 16:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5ACD61A1BAC for <>; Fri, 17 Oct 2014 09:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4l85PrKilhUl for <>; Fri, 17 Oct 2014 09:13:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 581401A1B8E for <>; Fri, 17 Oct 2014 09:13:17 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id E04741600C9; Fri, 17 Oct 2014 18:13:15 +0200 (CEST)
From: "Hallof, Andreas" <>
To: 'Ilari Liusvaara' <>, Johannes Merkle <>
Thread-Topic: [Cfrg] ECC reboot (Was: When's the decision?)
Thread-Index: AQHP6evh/eBHfwmMmUSZVajmnry++pwz6XqAgAB/qXA=
Date: Fri, 17 Oct 2014 16:13:13 +0000
Message-ID: <>
References: <> <> <> <> <20141017094755.GA29915@LK-Perkele-VII>
In-Reply-To: <20141017094755.GA29915@LK-Perkele-VII>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-olx-disclaimer: Done
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TBoneOriginalFrom: "Hallof, Andreas" <>
X-TBoneOriginalTo: 'Ilari Liusvaara' <>, Johannes Merkle <>
X-TBoneOriginalCC: "" <>
X-TBoneDomainSigned: false
Cc: "" <>
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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, 17 Oct 2014 16:13:19 -0000

> And what's wrong with just using Brainpool for implementations that need random primes for extended side channel resistance?
Nothing is wrong about that. 

The point that Mr. Merkle is addressing, is that there is a huge world outside PC/Server-based TLS-Authentication.
I have the impression the current discussion at the cfrg is too narrowly focused on software implementations in unconstrained environments with only global timing SCA.

In the infrastructure surrounding the german eHealth-Card the majority of all TLS-Connection are based on smartcards on one communication-endpoint (the other being a server / non-smartcards).
The same is true for the smartmeter-infrastructure. 

Like it is stated in a result of the current discussion at the cfrg could be that there are two sets of curves.
I have the impression the Brainpool-group would happily accept/(=> switch to) the one set (with random primes), that has the necessary cryptographic properties.
Thus reducing the implementation-costs at smartcards, Web-browsers, servers etc..

> Performance.
If a ECDSA-Brainpool-based-signaturecreation cost around 90 ms on a cheap smartcard, it is of little concern to me if it would be 20% faster or slower.
SCA-resistance is a concern for me.

 Andreas Hallof

Andreas Hallof, Datenschutz und Datensicherheit / Kryptographie

-----Ursprüngliche Nachricht-----
Von: Cfrg [] Im Auftrag von Ilari Liusvaara
Gesendet: Freitag, 17. Oktober 2014 11:48
An: Johannes Merkle
Betreff: Re: [Cfrg] ECC reboot (Was: When's the decision?)

On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote:
> Alyssa Rowan wrote on 16.10.2014 19:38:
> > I can see why they might want that, if VPR is the most convenient 
> > for their implementations - but from what I see from the hesitant 
> > adoption of Brainpool in the wider community,
> this assertion is only true for software implementations. Brainpool 
> curves are used by more than 50 million smart cards rolled out and 
> several vpn solutions (e.g., based on IPSec) widely used within German 
> and EU public authorities.

And what's wrong with just using Brainpool for implementations that need random primes for extended side channel resistance? Not rigid enough? Not standard enough?

For software implementations only needing defenses against software attack (including attacks from different process in the same host/VM) there is plenty wrong with using Brainpool.

If attacker can get enough access to pull off EM attacks against most of the endpoints, one has more severe problems than software vulernable to EM attack.

There is a good reason (singular!) why NIST/NSA curves are used far far more in TLS than Brainpool, despite there being codepoints for both:


Cfrg mailing list