Re: [Cfrg] Curve selection revisited

[David Jacobson <[e-mail]>]

On 7/25/14 7:48 AM, Paterson, Kenny wrote:
> Ben
>
> Thanks for this helpful message. I've responded in-line below,
> representing the chairs and based on what I've heard on the list and at
> the IETF meeting this week. People on the list should still feel free, of
> course, to argue for other points of view.
>
> On 25/07/2014 01:10, "Benjamin Black" <[e-mail]> wrote:
>
> [snip]
>>
>> 2) Performance must be measured using "production-quality"
>> implementations. By this I mean implementations which employ the sort of
>> techniques/optimizations appropriate for large scale deployment. This is
>> specifically intended to exclude discussion of
>> how simple or fast an implementation _could_ be, in favor of what they
>> actually are in practice. However, the goal is to select curves which
>> strike the best balance between various requirements, not simply the
>> fastest.
>>
> I don't think it's very easy to be concrete about what
> "production-quality" means. I tend to agree with Yoav's comments here
> (http://www.ietf.org/mail-archive/web/cfrg/current/msg04735.html).

I believe that we need to decide what to do about side channel leakage 
resistance.  Performance needs to be measured with the defenses 
deployed.  Of course, the problem is that nobody knows what defenses 
should be deployed and when we have reached "good enough". One common 
defense is no branches on secret data.  Almost certainly we would want 
the benchmarks to be coded this way.  But if the threat model includes 
malicious processes that share a cache with the crypto process, then it 
is  good practice to code so that the stream of memory addresses 
accessed does not depend on secret data.    And then there are various 
blinding techniques with widely varying costs.

This issue is more important if different curves/protocols have 
different sensitivities to leakage or require different leakage 
mitigations.  I don't know whether this is the case.

    --David Jacobson