Re: [Cfrg] Comparing ECC curves

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jul 23, 2014 at 6:33 PM, Benjamin Black <[e-mail]> wrote:
> On Wed, Jul 23, 2014 at 3:28 PM, Phillip Hallam-Baker
> <[e-mail]> wrote:
>>
>>
>> 3) Do we need to consider 2^192 work factor?
>>
>> I can't see any case where I am interested in a work factor of 2^192.
>> Either I am willing to make some concession to performance or I want
>> it gold plated and 2^256. I would quite like to see the 2^192 work
>> factor nuked.
>>
>
> Phillip,
>
> This was our conclusion, as well. If you haven't seen it, here's the NUMS
> TLS draft which only specifies the twisted Edwards curves at 128 and 256 bit
> security levels: http://tools.ietf.org/id/draft-black-tls-numscurves-00.txt

Just trying to push back on the idea we need the options .. :-)

Similarly, I am not interested in a set of curves that is
hyperoptimized for TLS and can't be used for S/MIME. When we were
discussing random curves, changing the curve was pretty much the same
as changing the key. Now that we are doing the close to powers of 2
curves with highly optimized code, changing the curve is like changing
to a whole new algorithm.

As far as the code is concerned it is better to think about them as
choosing between ECDHE-25519 and ECDHE-256p rather than ECDHE with a
named curve. Changing the curve is going to select a different
implementation.


The end product I want from this is a set of backup public key
algorithms that can be made a RECOMMENDED algorithm with a view to
making them a MUST algorithm replacing RSA-2048 at some point in the
future. I want to encourage dedicated hardware support, etc. etc.


This means that I really don't want TLS to go and choose something
that is going to fail if we try to apply it to S/MIME or PGP. We can
use DH for email encryption but only one of the keys can be ephemeral.
The recipient key is going to have to be static.

I would suggest as a way forward here we look at the protocol
requirements for TLS, PKIX and S/MIME as they represent the two poles
of protocol design. I would be rather surprised to find IPSEC, SSH
etc. to have dramatically different requirements to TLS. S/MIME and
PGP on the other had are store and forward which makes them very
different beasts. I would also separate out TLS and PKIX because one
is a single protocol and the other is infrastructure.

[DNSSEC does actually have a different requirement from PKIX, data
size, but that is probably not going to be a deciding factor between
curves]

It would clearly be nuts for the IETF to choose a curve that does not
work well for TLS. But I don't see the differences between the curves
on TLS being so great that we should accept a curve that we can't use
in every reasonable protocol.