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

Michael Hamburg <> Fri, 17 October 2014 17:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B549F1A0250 for <>; Fri, 17 Oct 2014 10:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.556
X-Spam-Level: *
X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Zn4ruvq3dIO for <>; Fri, 17 Oct 2014 10:59:07 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA4791A00BF for <>; Fri, 17 Oct 2014 10:59:04 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 2DE573AA49; Fri, 17 Oct 2014 10:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1413568622; bh=24tiFTSPzSiXNJ5PDq1ZWVRZnb3VRbVb+oynUmc1R20=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ReyyuwoJM0i4W2rWkF84S9LgGPadKty6MpuubqNcJk6Xq29k++InVMKHHRv/hbf1F e/rdRFASrk6eNjgeYeKWidMd+w8j83f8LeeYGHf7ZMv+ZvvFdZS4OvhZbNSTgWN1kR fS8qahq7gQKx9TOt6qVgfAiYTVll4H0DLs4DIyVM=
Content-Type: multipart/alternative; boundary="Apple-Mail=_74CD0DDC-CD6C-4C27-AB29-CBF89A8F8A4F"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Michael Hamburg <>
In-Reply-To: <>
Date: Fri, 17 Oct 2014 10:58:59 -0700
Message-Id: <>
References: <> <> <> <> <20141017094755.GA29915@LK-Perkele-VII> <> <>
To: Watson Ladd <>
X-Mailer: Apple Mail (2.1990.1)
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 17:59:08 -0000

> On Oct 17, 2014, at 9:23 AM, Watson Ladd <> wrote:
> On Fri, Oct 17, 2014 at 9:13 AM, Hallof, Andreas
> < <>> wrote:
>>> 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..
> What sort of decision do you think we are going to make? We obviously
> cannot remove curves. So Brainpool will remain in TLS. The question is
> about curves which make software implementations easier and faster.
> Why does hardware matter for the choice we are going to make?

I agree: what’s even the point of this tangent?

Lochter et al’s paper asks for curves which have exactly the same properties as the Brainpool curves.  This is mostly motivated by legacy constraints, with one secure hardware argument tossed in.  It also asks the CFRG not to do anything which would cause current Brainpool users to flee that standard.

It is eminently clear that Lochter et al are asking for the Brainpool curves to be included in any new standard.  Why would we just reroll the constants when the entire motivation for the exercise is legacy compatibility?

It’s also clear that enough of this forum cares about software performance that VPR cofactor-1 curves will not be the only curves chosen.

So is the thrust of this whole argument “have your special curves, but make Brainpool mandatory to implement”?  If so, just say so, and let the forum discuss it separately, and unblock the discussion of new curves.

— Mike