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

From: Peter Gutmann <[email-masked]>
Date: Tue, 27 Jan 2015 11:44:46 +0000

Stephen Farrell <[email-masked]> writes:

>You didn't say why. Why is it a bad idea? What is the downside?

The fact that it's one more piece of special-case code to add, debug, and test
when we've already got perfectly-functional, debugged, and tested code, some
of it in active use for twenty years or more, to do it present everywhere that
uses bignums.

(Another issue is that using a nonstandard form for representing the values is
bound to cause interop problems in the future when the 25519 form is the
opposite to what everything else does.  Look at the mess that occurred during
the AES competition with different endiannesses used in various algorithms,
until the problems were pointed out at the second AES conference by someone
who'd actually implemented things from the spec ("Implementation Experience
with AES Candidate Algorithms") and NIST revised the requirements).

If the "spec" for 25519 is going to be "the standard is to blindly do whatever
djb's code does" then there's no need for a spec or any CFRG involvement, just
provide a link to djb's code, since that'll be the spec.  It's decent code,
I'm not complaining about it, but the CFRG shouldn't be pretending to be
setting any standard if it's just "do whatever this code happens to do".  The
code then becomes the spec.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Jan 2015 11:59:28 +0000

Hiya,

> of it in active use for twenty years or more, to do it present everywhere that

It would be a special case, yes, and there is a small downside
there I guess.

I'm not sure how much implementation and deployment of current
25519 ought weigh against that, but its a trade-off, not a
slam dunk, esp as the special-case code is not at all special
in this case. (Remembering to do it is special I guess, but
what you do is not a deal, and if you get it wrong your first
test vector check will tell you immediately.)

> with AES Candidate Algorithms") and NIST revised the requirements).

I'd think that a change from the current (albeit smallish) amount
of deployed stuff is more likely to result in interop issues actually
since some code won't be updated no matter what an RFC says. But
again, I don't see a showstopper argument there either way.

FWIW, I don't own relevant code here, but I'd go with the current
implementations myself as I don't think the special case is a real
problem. Confusion and having to go and change existing code are
IMO bigger downsides in this particular case. Not by much, but then
this particular choice is not hugely important, as we all I hope
agree.

> code then becomes the spec.

The series of humongous mail threads this RG has gone through just
to get to this point makes it clear that "blindly do" etc. is just
incorrect.

S.

> 
> Peter.
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
> 
>