[curves] The great debate over point formats (Mike Hamburg)
mike at shiftleft.org
Sun Feb 2 10:10:45 PST 2014
On Feb 2, 2014, at 4:22 AM, Paulo S. L. M. Barreto <pbarreto at larc.usp.br> wrote:
> I don't follow you reasoning. My post had nothing to do with, nor did it even
> mention, the Weierstrass form at all. It was a description of a curve in
> Edwards form (with a particularly simple coefficient, and defined over one of
> the NIST primes). I can't see why you thought it implied Weierstrass and an
> ensuing list of disadvantages. Your criticism seems thus misplaced; maybe it
> refers to some other message in the thread (or a different thread)?
This thread forked off of Robert Ransom saying what "a true drop-in replacement for one of the NSA curves" would look like, and me responding to it with such a curve, and you responding to me. The idea was that some implementations could leverage their existing NIST short-Weierstrass arithmetic, and only change b and maybe the point encoding, but new implementations would use Montgomery or Edwards. My post also included the isogenous short Weierstrass curve. So maybe that's why Watson and Robert thought you meant Weierstrass.
Furthermore, P-384 is pretty ugly -- it's a non-64-bit-aligned pentanomial -- and I don't think it makes sense to use that field unless we want some sort of compatibility. That could be with hardware accelerators or arithmetic libraries or something, but earlier in this thread it was suggested for Weierstrass form too.
I agree that there are serious concerns about any compatibility strategy. "Nobody pours new wine into old wineskins," such a compatible design would have most of the problems of both new and old.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Curves