[Cryptography] Many curves versus one curve

[David Leon Gil]

>
> Cc: "cryptography at metzdowd.com <javascript:;>" <cryptography at metzdowd.com
> <javascript:;>>
> Subject: Re: [Cryptography] IETF discussion on new ECC curves.
> Message-ID: <683EFDEB-06A0-4248-8579-CDCF17CAEF34 at gmail.com <javascript:;>
> >
>
> Does it make sense to have a small set of curves that everyone uses?  Or
> would it be better to have every application or even every user generate
> their own curve, using some process that would convince skeptics that the
> curves had been generated randomly?
>
> --John


I think that Mike Hamburg has been working on a Sage(?) script to select a
curve satisfying the SafeCurves criteria deterministically from a random
seed. (He mentioned this on another list.)

It makes most sense on a per-application basis -- the computational cost of
verifying these conditions is fairly high.[*]

However. Some EC primitives lose some of their nice properties if users can
select arbitrary curves (even over a single prime field). E.g., ECDSA is
not subject to key-share attacks if all users use the same curve; it is, if
arbitrary curves are permitted. (Koblitz and Menezes discuss this in their
'Another look' papers.)

So current uses of EC might need reëxamination.

-dlg

PS, or, taking the other side: There is, by the way, a good
counter-argument to the 'just increase the bit-length' argument djb uses
for single curves:

Suppose that an unknown fraction of elliptic curves has some undesirable
property. By using a large number of curves, we decrease the variance of
our risk in expectation. Under a minimax cost model, this is a big gain. (A
certainty of small loss, rather than a small chance of catastrophe.)

[*] For applications that are extremely length-constrained -- e.g., some
embedded devices -- provisioning with a per-device curve is the most
feasible way of increasing security. I, personally, would like a
standardized process for this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140809/e0e7da17/attachment.html>