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 <pinte...@gmail.com> wrote: > > > Nathaniel McCallum <npmccal...@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. 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 ;-) — The Million Dollar Curve Team _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves
