Re: [Lwip] Call for adoption of draft-struik-lwig-curve-representations-02

[Mohit Sethi <[e-mail]>]

Hi Nikolas,

Thank you for your feedback on the draft. Is any of the two libraries 
open source?

I personally think that it would be nice to see some performance numbers 
in the draft.

For example, is an implementation supporting both the curves with the 
same underlying primitives slower than two separate implementations? And 
how much code space or memory can be saved by re-using some of the 
underlying primitives?

--Mohit


On 08/19/2018 08:08 PM, Nikolas Rösener wrote:
> Hi,
>
> my name is Nikolas Rösener - I am student at the Universität Bremen 
> currently writing my masters thesis on the topic of the performance of 
> curve model transformations.
>
> In my opinion draft-struik-lwig-curve-representations-02 already 
> presents a great summary of the possible transformations for the 
> Curve25519-family of curves. I implemented the transformations in two 
> different libraries, as part of my performance evaluation, and had no 
> problems following the formulae in the draft.
>
> In retrospect, I found that the following additional information would 
> have been very useful if I had attempted to implement the 
> transformations as part of a serious cryptographic primitive:
>
> - Test Vectors
> - Recommendations for (the relevance of) dealing with the special 
> cases (point-at-infinity etc.)
> - Usages with co-factor Diffie-Hellmann (NIST SP 800-56a)
> - Usages with ECDSA (FIPS Pub 186-4)
>
> I had some further discussions with Rene on topics related to 
> retrofitting existing implementations with conversions (doing generic 
> modular reduction, providing transformation formulae for different 
> point formats, providing algorithms for recovering coordinates...). 
> The relevance of these of course depends on the direction the draft is 
> taking.
>
> Oh, and - personal preference - but I also think it makes quite a 
> difference to the ease and speed of implementing an ecc algorithm if 
> it is provided as three-operand-code in addition to the mathematic 
> formula (like e.g. https://hyperelliptic.org/EFD/). The former reduces 
> cognitive load and risk of manual errors.
>
> Best regards,
> Nikolas Rösener
>
>
> _______________________________________________
> Lwip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lwip