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 <[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. > > 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 ;-)
Thomas, can we get some test vectors for MDC? Thanks! _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
