Re: [Cfrg] Comparing ECC curves

On Wed, Jul 23, 2014 at 4:17 PM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:
> On Wed, Jul 23, 2014 at 6:33 PM, Benjamin Black <b@b3k.us> wrote:
>> On Wed, Jul 23, 2014 at 3:28 PM, Phillip Hallam-Baker
>> <phill@hallambaker.com> 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.

Why will that happen with these curves when it didn't with the NIST
curves vs. RSA?
Yes, I'm aware of patent issues that used to exist, but this was an
unforced error in
standardization: RSA is of a similar vintage.

>
>
> 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.

Not being at IETF 90 I can't comment on the standardization, but I
certainly can comment
on the cryptography. All protocols use ECDH and signatures, and any
twisted Edwards curve
will work for both. The only debate is how to represent points for
ECDH, which exact prime to use,
and the exact curve to use. There are many implemented, functioning
systems using Curve25519
and Ed25519 and friends, without any problems.

(What you propose for email encryption is in fact what ECIES does,
which is what OpenPGP does)

>
> 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]

Point compression can dramatically shrink keys. The patent expires next Tuesday,
and Curve25519 never infringed upon it.

However, DNSSEC still uses RSA, despite ECC existing and making sizes
much smaller.

>
> 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.

That won't happen.

Sincerely,
Watson Ladd
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin