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

[Michael Hamburg <[e-mail]>]

> On Oct 17, 2014, at 9:23 AM, Watson Ladd <[e-mail]> wrote:
> 
> On Fri, Oct 17, 2014 at 9:13 AM, Hallof, Andreas
> <[e-mail] <mailto:[e-mail]>> 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 http://eprint.iacr.org/2014/832 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.

Cheers,
— Mike