Dear colleagues:
Changes (compared to previous version v19):
- removed the cose iana requests subsections, so as to avoid further
pollution of discussion of this document (which is long overdue to get out).
[Excerpt email RS of Feb 16, 2021, 11.50am EST; see
https://mailarchive.ietf.org/arch/msg/lwip/9SH1J3OZoiwMZ8jx49OhOlZOtAg/ ]
The iana cose "bickering" is about the value of 6 one-word character strings, in an otherwise quite
voluminous, since 137 pages, document, where the value could be "new" or "reuse existing"
(i.e., at most six bits of entropy). The current iana cose request may not be perfect. If it requires
improvement, I can write some text to accommodate this *in parallel* to the IESG review.
On 2020-12-18 9:50 a.m., Rene Struik wrote:
Dear colleagues:
Changes:
- added reference to FIPS 140-2 accreditation requirements
(cross-referenced in Section 4.1 w.r.t., NIST-compliance ECDH25519);
- added references to draft NIST SP 800-186 and draft FIPS 186-5 (not
cross-referenced yet, but NIST SP 800-186 defines short-Weierstrass
version of Curve25519 [dubbed W-25519] and
FIPS 186-5 allows its use; similar for Curve448 [dubbed W-448 there]);
- added Note in Appendix K.1 that checking whether an element is a
square in GF(q) can be done more efficiently than actually computing
those;
- cross-referenced this Note in Appendix I.8 with public key
validation check of compressed points.
The added technical material (on public key validation and square root
checking) is relevant for co-factor ECDH25519, where NIST-compliant
implementations have to check that the received curve point is on the
actual curve. Since ECDH computations do not require the y-coordinate
of a short-Weierstrass point, one can check whether a point is on the
curve this way (~1% cost vs. ~10%).
While this added technical material note is purely informational
(again: service to the community), it helps in understanding that
NIST-compliant implementations do not add more cost than more lenient
once (that do not perform checks).
Best regards, Rene
On 2020-12-17 6:32 p.m., [email protected] wrote:
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-19.txt
Pages : 137
Date : 2020-12-17
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. We also provide extensive background
material that may be useful for implementers of elliptic curve
cryptography.
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-19
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-19
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/
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
