On Tue, Mar 1, 2016 at 8:41 AM, Thomas Baigneres <[email protected]> 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 <[email protected]> wrote: >> >> >> Nathaniel McCallum <[email protected]> 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. 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.
Like https://github.com/npmccallum/python-rubenesque/blob/master/rubenesque/curves/cfrg.py? Oh, you wanted to compare apples to oranges? > > 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 ;-) > > — The Million Dollar Curve Team > > _______________________________________________ > Curves mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/curves -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
