Re: [Cfrg] normative references

[Manuel Pégourié-Gonnard <[e-mail]>]

On 15/01/2014 22:30, Watson Ladd wrote:
> On Wed, Jan 15, 2014 at 12:50 PM, Paul Lambert <[e-mail]> wrote:
>>
>> We're in the documentation business here - not code libraries. Plus we're
>> supposed to have multiple interoperable different implementations.
> 
> Do you really think everyone implementing P256 does it themselves? Or do they
> take example code from the Internet?
> 
It seems to me that the whole goals of standards is to allow multiple
interoperable implementations, as Paul says. (Besides, they often give much more
information than existing code if you want to modify/extend anything, make
different trade-offs, etc.)

>> Yes ... and why did you leave out Ed25519?       It's being used and should at least be discussed/reviewed/
> 
> It's the same as Curve25519, and not in safecurves. Let's be real
> clear: isogenies don't change anything substantial.

Of course they don't change anything to the DLOG security. But they change
everything on actual computations and representations.

My opinion is you should explain how to compute the isogeny or (inclusive)
include Ed25519 as a "different" curve and explain which formulas to use with
it. I honestly don't know which is the more helpful.

> I'm also going to explain the Montgomery ladder and double-and-add on
> Edwards and that's it. RFC 6090 doesn't talk about
> radix-k either, nor does it explain Shamir's trick, or fun with the
> Brier-Joyce ladder, or w-NAF, etc.

I fully agree that the document should only discuss the most "basic" (and safe)
algorithms for computing the necessary operations. However, if other algorithms
are know that have (potential) security issues (like, not being constant-time,
having special cases) it would be great if the document could point out these
dangers.

> I still don't see why this form is much better than a paragraph
> listing these things.
> 
Much easier to access each piece of information. Almost like an array compared
to a linked list (at least in my opinion).

>> Hex fits better in an RFC ...  decimal would be fine also.
> 
> Six of one, half-dozen of the other.
> 
I'm not sure I understand you comment. Anyway, in my experience, I feel like
I've seen much more (large) constants in hex than in decimal in RFCs.

On the very down-to-earth practical side, hex is more compact, so it means less
line breaks, so easier copy-pasting (yeah, I know, gory details).

Manuel.