Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

["Dan Harkins" <[e-mail]>]

On Tue, January 27, 2015 9:07 am, Watson Ladd wrote:
>
> My SPAKE2 draft contains specified M&N, generated by a C program
> Nathan McCullum sent me. I've been unable to determine what that
> program does in anything more than the vaguest terms because OpenSSL
> internals are opaque, but users do not need to generate their own
> points.

  Yes, it's opaque to you, the application writer. That's the point! But
to have curve25519 as a special case then you'd have to pry into the
opacity of the code and figure out what's going on.

  So to allow Nathan McCullum to send you a chunk of code that
should work with any curve supported by OpenSSL, and have it just
work without you knowing any opaque internals, it requires a
canonical conversion of bitstring to integer to field element and
back.

  If, as you say, users do not need to generate their own points then
they're gonna have to have a registry of M and N for all curves. And
to import a bitstring (for instance from the appendix of your draft)
into code requires converting that bitstring into an element. And
without the canonical conversion then you need to know about the
opaque internals.

  Thank you for illustrating my point so well!

  Dan.