[curves] Million Dollar Curve

[Nathaniel McCallum]

On Tue, 2016-03-01 at 17:41 +0100, Thomas Baigneres wrote:
> Hello Krisztián,
> 
> we were watching the discussion on Million Dollar Curve and felt the
> need to react to your message because we do not agree with some of
> your views.
> 
> 
> > 
> > On 24 Feb 2016, at 23:36, Krisztián Pintér <pinterkr at gmail.com>
> > wrote:
> > 
> > 
> > Nathaniel McCallum <npmccallum at redhat.com> wrote:
> > 
> > > 
> > >     – a potential weakness because Curve25519 uses a very
> > > specific
> > >       prime field.
> > as well as every other curve on the planet. even nist curves use
> > special primes.
> > 
> > > 
> > > applications where speed is paramount, Curve25519 is probably the
> > > best
> > not where it is paramount. this wording suggests that for most
> > applications, speed is not an issue. the world is very different
> > than
> > this picture. namely:
> > 
> > * we don't want a whole bunch of curves. we want only a handful,
> > ideally two, one regular size and one larger. adding more curves is
> > a
> > disservice.
> We believe that, in general, relying on a single solution for
> cryptography always increases the risk. In case one solution gets
> attacked, it’s better to have a backup plan at hand than having to
> find one in a hurry. We agree that if Curve25519 ever gets attacked,
> it is likely that many other curves (including Million Dollar Curve)
> will also suffer from this attack, but you never know. 
> 
> > 
> > * speed is pretty much always and issue if one participant is a
> > busy
> > server.
> We agree that for busy servers speed is an issue. Still, most “busy”
> servers on the planet still use RSA over ECC. And the gap between
> RSA2048 and Million Dollar Curve is much bigger than between Million
> Dollar Curve and Curve25519.
> 
> > 
> > * we definitely want code simplicity. good curves are designed to
> > have
> > simple and safe implementations. curve-specific implementations are
> > always simpler. less potential for errors, less code to audit.
> We suppose that this matter was already extensively discussed on this
> mailing list during the “random” vs. “optimized” feud. Our opinion is
> that a generic implementation of an Edwards Curve (like Million
> Dollar Curve) is much simpler than an optimized implementation of
> Curve25519. Of course this generic implementation can directly be
> used for Curve25519 too, but people implementing Curve25519 will most
> certainly want to optimize the code. In the end, they will have a
> much more complex and error prone code.

... and unauditable.

>  As an example, you can have a look at Nathaniel McCallum’s
> straightforward implementation of Million Dollar Curve
> (https://github.com/npmccallum/python-
> rubenesque/blob/master/rubenesque/curves/mdc.py) and compare it to
> any optimized implementation of Curve25519.
> 
> For the record, we do believe Curve25519 is a great work and we will
> ourselves continue to use it as a backup plan for Million Dollar
> Curve ;-)