Dear Erik:
Could you please make sure the lwig curve draft ends up on the iesg
telechat agenda again asap?
I think we should (and easily can) get this draft done before there is
another IESG roster change (due to AD changes in March). Next week, it
will be precisely one year this draft was first put on the iesg telechat
agenda (Feb 18, 2021, to be precise). Let us make sure we do not need
candles to "celebrate" one year of zero progress.
Thanks for your help!
Apologies for sending this message via the mailing list: however, for
some reason, none of my offline email messages sent to you since January
13, 2022 seemed to have reached you (or, at least, have been replied
to). I did see other emails from the [email protected] address, so
presume that address still works (if this assumption is incorrect,
please let me know).
Rene
On 2022-01-21 6:32 p.m., Rene Struik wrote:
Dear colleagues:
I updated the lwig curve draft, so as to take into account (1) another
crypto review panel review this draft was subjected to by the powers
that be; (2) discussions on ECDSA with the SHA3 family hash functions
that took place on the COSE mailing list and offline Nov-early January.
Changes:
a) Section 7 (Implementation Status): included reference to ANSSI's
(French information security agency) use of lwig curve draft,
including motivations (hooray);
b) Appendix B.1 (Elliptic Curve Nomenclature): made definition of
isomorphic curves in Appendix B.1 more precise, via one-sentence
change (zero impact on draft, but done for completeness);
c) Appendix I (Data Conversions): added Definition of ASCII symbols
(with reference to RFC 20);
d) Appendix Q (ECDSA): corrected numerical examples for ECDSA w/
Wei25519 and SHAKE-128 (Appendix Q.3.2) and ECDSA w/ Wei448 and
SHAKE-256 (Appendix Q.3.3). Here, it turned out that the Python code
in Sage that I used incorrectly implements the FIPS 202 specification
of SHAKE128 and SHAKE256. To do this properly, I implemented all SHA3
functions from scratch on the bit-level and had this vetted
independently via contacts at NIST. To indicate that ECDSA w/ Wei448
and SHAKE256 uses FIPS 202-conformant SHAKE256, I added in Section 4.3
as reference to FIPS 202 "see Section 6.3 of [FIPS 202]"). BTW -
adding ASCII (point c) above) above was motivated by desire to avoid
bit/byte-ordering ambiguity and set the record straight.
I made a few (very few) typographical and cosmetic changes throughout
the document, in an attempt to make the crypto review panel reviewer
happy. (Time will tell.)
I hope this helps.
Best regards, Rene
-------- Forwarded Message --------
Subject: New Version Notification for
draft-ietf-lwig-curve-representations-23.txt
Date: Fri, 21 Jan 2022 14:56:26 -0800
From: [email protected]
To: Rene Struik <[email protected]>
A new version of I-D, draft-ietf-lwig-curve-representations-23.txt
has been successfully submitted by Rene Struik and posted to the
IETF repository.
Name: draft-ietf-lwig-curve-representations
Revision: 23
Title: Alternative Elliptic Curve Representations
Document date: 2022-01-21
Group: lwig
Pages: 150
URL:
https://www.ietf.org/archive/id/draft-ietf-lwig-curve-representations-23.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-23
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 leveraging existing implementations and specifications
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 Secretariat
--
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
