Hi Goran:
Please find below some brief feedback on your note:
- the naming wei25519 has been around since the first draft (Nov 13,
2017, i.e., 3 years minus 1 week ago), see [1]. NIST indeed produced two
draft documents, viz. Draft NIST SP 800-186 and Draft FIPS Pub 186-5 (on
October 31, 2019), which generated lots of (to my knowledge still
unresolved) comments during public review. It is hard to refer to that
document, since it is only a draft and unfortunately has quite a few errors.
- earlier versions of the lwig draft have received reviews by the crypto
review panel (Stanislavslav Smyshlyaev), iotdir early-review (Daniel
Migault); the sections on COSE/JOSE code point assignments resulted from
a phone call and various email exchanges with Jim Schaad; the section on
PKIX/CMS was suggested during IETF Last-Call secdir-review (Russ
Housley) and reviewed by him. The document had IETF Last-Call Aug 24,
2020. See, e.g., the status pages [1].
- ECDSA has been around since 1999, has been widely standardized, and
has seen lots of analysis, where ECDSA25519 is simply yet another
instantiation. Signature generation and verification times for
ECDSA25519 should be similar to those of Ed25519 (since timing is
dominated by scalar multiplication, where one could simply use
Montgomery arithmetic [3]). In my personal view, ECDSA25519 may be more
secure than Ed25519 (if only because it is non-deterministic, see
Security section [6]); similar side-channel care has to be taken in
either case.
- As mentioned in the draft, one can easily switch between Wei25519
and Curve25519 (which requires a single field addition or subtraction
only, i.e., <.01%, see Appendix E.2 [7]). As mentioned in the draft, one
could use Wei25519.-3 with an existing generic implementation that
hardcodes the domain parameter a=-3, but needs to compute an isogeny and
dual isogeny for this (adding 5-10% cost, see Appendix G.2 [8]]) and a
~9.5kB table (see Section 5.3 [4]). However, if one already has generic
hardware support, one may still have a significant win (see Section 6 [5]).
- The isogeny for Wei25519.-3 has odd degree l=47, which is co-prime
with the order of the curve, so is in fact invertible. With Wei448.-3,
the isogeny has degree l=2, so is not invertible; however, this does not
really matter, since it is invertible with correctly generated
public-private key pairs (which have prime/odd order) and the factor two
is absorbed with co-factor ECDH, where h=4 then.
I hope this helps.
(*) For ease of tracking, it would help if iana related comments are
flagged in the subject line (e.g., include (iana) in the beginning hereof).
Best regards, Rene
Ref with hyperlinks:
[1]
https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00
[2] https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
[3]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
[4]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3
[5]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6
[6]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8
[7]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2
[8]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2
On 2020-11-06 11:19 a.m., Göran Selander wrote:
Hi,
Apologies for cross-posting LWIG and COSE. I had a brief look at
draft-ietf-lwig-curve-representations-13 and noticed it registers a
lot of new COSE(andJOSE, PKIX, and CMS)algorithms.Has this draft been
discussed in COSE(JOSE/CURDLE)? If not, perhaps it should be before
being progressed?
* The draft needs to manage the overlap with NIST SP 800-186, which
should be referenced and mappings, name of curves, etc. aligned.
The draft defines Wei25519 and Wei448. It is unclear if these are
identical to W-25519, W-448 as defined in NIST SP 800-186. We
probably would not want two slightly different definitions and/or
names, multiple COSE code points, etc.
* The draft registers the COSE algorithm "ECDSA25519" as "ECDSA with
SHA-256 and curve Wei25519". That is not how the other COSE
signature algorithms work. They work like PKIX where the curve is
given by the public key. Also, why cannot W-25519 be used with the
existing ES256 signature algorithm?
* The draft registers the COSE algorithm "ECDH25519". There are no
COSE ECDH algorithms for P-256, why is anECDH algorithm for
W-25519 be needed?
Other questions. I may have missed it, but
* is it described what are the expected security properties of
ECDSA25519(including mapping) compared to Ed25519? For example
w.r.t. side channel attacks?
* has any performance measurements been made comparing
ECDSA25519(including mapping) and Ed25519?
* similar questions on security and performance with Wei25519.-3
instead of Wei25519. If I understand right, the former mapping is
not reversible, but could benefit from optimized code with
hardcoded domain parameters.
* ANSI X9.62-2005 was withdrawn in 2015 and is behind a paywall, is
this reference necessary?
Göran
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
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
