Subject: [Lwip] I-D Action: draft-ietf-lwig-curve-representations-05.txt

From: [email-masked]
Date: Wed, 15 May 2019 12:04:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF.

        Title           : Alternative Elliptic Curve Representations
        Author          : Rene Struik
	Filename        : draft-ietf-lwig-curve-representations-05.txt
	Pages           : 62
	Date            : 2019-05-15

Abstract:
   This document specifies how to represent Montgomery curves and
   (twisted) Edwards curves as curves in short-Weierstrass form and
   illustrates how this can be used to carry out elliptic curve
   computations using existing implementations of, e.g., ECDSA and ECDH
   using NIST prime curves.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-05
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rene Struik <[email-masked]>
Date: Wed, 15 May 2019 15:21:02 -0400

Dear colleagues:

I slightly updated the draft to address Mohit Sethi's comment [1] on 
trade-offs between code reuse and computational efficiency. To this end, 
I added a little section (now Section 6) on "implementation 
considerations" - see[2].

As already suggested in [3], I did not give an explicit computational 
cost comparison, since this is highly device and application dependent 
and alone would not do justice other considerations that come into play 
when deciding on a crypto implementation strategy.

Best regards, Rene

[1]https://mailarchive.ietf.org/arch/msg/lwip/DQ5oYwFusICBx_llv1Wenc1EZCQ
[2]https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-05#section-6
[3] https://mailarchive.ietf.org/arch/msg/lwip/vSnhe1lO03AfLONxHGmixuP4z64

On 5/15/2019 3:04 PM, [email-masked] wrote:
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 16 May 2019 12:25:33 +0000

Hi Rene,

Thanks for addressing the comments. I wasn't looking for exact computational cost comparisons and rather some hints on what to expect if I re-use the underlying implementation of a different curve. Your statement "the overall cost differential is somewhere in the interval [1.00 - 1.25]" is useful (and perhaps sufficient).

I had one remaining suggestion. RFC 7942 (https://tools.ietf.org/html/rfc7942) describes how to improve awareness of running code. Perhaps you could add a section on implementations of Wei25519: https://github.com/ncme/c25519 and that tinydtls https://github.com/ncme/tinydtls now supports Wei25519.

--Mohit

On 5/15/19 10:21 PM, Rene Struik wrote:
Dear colleagues:

I slightly updated the draft to address Mohit Sethi's comment [1] on trade-offs between code reuse and computational efficiency. To this end, I added a little section (now Section 6) on "implementation considerations" - see[2].

As already suggested in [3], I did not give an explicit computational cost comparison, since this is highly device and application dependent and alone would not do justice other considerations that come into play when deciding on a crypto implementation strategy.

Best regards, Rene

[1]https://mailarchive.ietf.org/arch/msg/lwip/DQ5oYwFusICBx_llv1Wenc1EZCQ
[2] https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-05#section-6
[3] https://mailarchive.ietf.org/arch/msg/lwip/vSnhe1lO03AfLONxHGmixuP4z64

On 5/15/2019 3:04 PM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

---

From: Rene Struik <[email-masked]>
Date: Thu, 16 May 2019 12:10:21 -0400

Hi Mohit:

Great suggestion. I just posted an updated document that reflects this.

Best regards, Rene

On 5/16/2019 8:25 AM, Mohit Sethi M wrote:
>
> Hi Rene,
>
> Thanks for addressing the comments. I wasn't looking for exact 
> computational cost comparisons and rather some hints on what to expect 
> if I re-use the underlying implementation of a different curve. Your 
> statement "the overall cost differential is somewhere in the interval 
> [1.00 - 1.25]" is useful (and perhaps sufficient).
>
> I had one remaining suggestion. RFC 7942 
> (https://tools.ietf.org/html/rfc7942) describes how to improve 
> awareness of running code. Perhaps you could add a section on 
> implementations of Wei25519: https://github.com/ncme/c25519 and that 
> tinydtls https://github.com/ncme/tinydtls now supports Wei25519.
>
> --Mohit
>
>> trade-offs between code reuse and computational efficiency. To this 
>> end, I added a little section (now Section 6) on "implementation 
>> cost comparison, since this is highly device and application 
>> dependent and alone would not do justice other considerations that 
>> come into play when deciding on a crypto implementation strategy.
>>
>> Best regards, Rene
>>
>> [3] 
>> https://mailarchive.ietf.org/arch/msg/lwip/vSnhe1lO03AfLONxHGmixuP4z64
>>
>> email:[email-masked]  | Skype: rstruik