Re: [COSE] draft-ietf-lwig-curve-representations-13

[Rene Struik <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]