 1/draftietflwigcurverepresentations15.txt 20201209 11:13:10.938892819 0800
+++ 2/draftietflwigcurverepresentations16.txt 20201209 11:13:11.074894613 0800
@@ 1,18 +1,18 @@
lwig R. Struik
InternetDraft Struik Security Consultancy
Intended status: Standards Track December 2, 2020
Expires: June 5, 2021
+Intended status: Standards Track December 9, 2020
+Expires: June 12, 2021
Alternative Elliptic Curve Representations
 draftietflwigcurverepresentations15
+ draftietflwigcurverepresentations16
Abstract
This document specifies how to represent Montgomery curves and
(twisted) Edwards curves as curves in shortWeierstrass 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.
@@ 33,21 +33,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at https://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on June 5, 2021.
+ This InternetDraft will expire on June 12, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 56,170 +56,170 @@
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Fostering Code Reuse with New Elliptic Curves . . . . . . . . 5
2. Specification of Wei25519 . . . . . . . . . . . . . . . . . . 6
3. Use of Representation Switches . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
 4.1. Implementation of X25519 . . . . . . . . . . . . . . . . 7
 4.2. Implementation of Ed25519 . . . . . . . . . . . . . . . . 8
 4.3. Specification of ECDSA25519 . . . . . . . . . . . . . . . 8
 4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others) . . . 9
 5. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 5.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 10
 5.2. Representation Conventions . . . . . . . . . . . . . . . 10
 5.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 10
 6. Implementation Considerations . . . . . . . . . . . . . . . . 11
 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
 10. Using Wei25519 and Wei448 with COSE and JOSE . . . . . . . . 14
 10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE . . . 15
 10.1.1. Encoding of ShortWeierstrass Curves with COSE . . . 15
 10.1.2. Encoding of ShortWeierstrass Curves with JOSE . . . 16
 10.2. Using ECDSA25519 and ECDSA448 with COSE and JOSE . . . . 17
 10.2.1. Encoding of ECDSA Instantiations with COSE . . . . . 17
 10.2.2. Encoding of ECDSA Instantiations with JOSE . . . . . 18
 10.3. Using ECDH25519 and ECDH448 with COSE and JOSE . . . . . 19
 10.3.1. Encoding of cofactor ECDH with COSE . . . . . . . . 20
 10.3.2. Encoding of cofactor ECDH with JOSE . . . . . . . . 20
 11. Using Wei25519 and Wei448 with PKIX and CMS . . . . . . . . . 21
 11.1. Encoding of ShortWeierstrass Curves with PKIX . . . . . 21
 11.2. Encoding of ECDSA Instantiations with PKIX . . . . . . . 21
+ 4.1. Implementation of X25519, Specification of ECDH25519 . . 7
+ 4.2. Implementation of Ed25519 . . . . . . . . . . . . . . . . 9
+ 4.3. Specification of ECDSA25519 . . . . . . . . . . . . . . . 9
+ 4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others) . . . 10
+ 5. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.2. Representation Conventions . . . . . . . . . . . . . . . 11
+ 5.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 11
+ 6. Implementation Considerations . . . . . . . . . . . . . . . . 12
+ 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
+ 10. Using Wei25519 and Wei448 with COSE and JOSE . . . . . . . . 15
+ 10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE . . . 16
+ 10.1.1. Encoding of ShortWeierstrass Curves with COSE . . . 16
+ 10.1.2. Encoding of ShortWeierstrass Curves with JOSE . . . 17
+ 10.2. Using ECDSA25519 and ECDSA448 with COSE and JOSE . . . . 18
+ 10.2.1. Encoding of ECDSA Instantiations with COSE . . . . . 18
+ 10.2.2. Encoding of ECDSA Instantiations with JOSE . . . . . 19
+ 10.3. Using ECDH25519 and ECDH448 with COSE and JOSE . . . . . 20
+ 10.3.1. Encoding of cofactor ECDH with COSE . . . . . . . . 21
+ 10.3.2. Encoding of cofactor ECDH with JOSE . . . . . . . . 22
+ 11. Using Wei25519 and Wei448 with PKIX and CMS . . . . . . . . . 22
+ 11.1. Encoding of ShortWeierstrass Curves with PKIX . . . . . 22
+ 11.2. Encoding of ECDSA Instantiations with PKIX . . . . . . . 22
11.3. Encoding of cofactor ECDH and Other Algorithms with
 PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 23
 11.4. Encoding of EllipticCurveBased Algorithms with CMS . . 22
 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
 12.1. OIDs for Use with PKIX and CMS . . . . . . . . . . . . . 22
 12.2. COSE/JOSE IANA Considerations for Wei25519 . . . . . . . 23
 12.2.1. COSE Elliptic Curves Registration . . . . . . . . . 23
 12.2.2. COSE Algorithms Registration (1/2) . . . . . . . . . 23
 12.2.3. COSE Algorithms Registration (2/2) . . . . . . . . . 23
 12.2.4. JOSE Elliptic Curves Registration . . . . . . . . . 24
 12.2.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 24
 12.2.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 25
 12.3. COSE/JOSE IANA Considerations for Wei448 . . . . . . . . 25
 12.3.1. COSE Elliptic Curves Registration . . . . . . . . . 25
 12.3.2. COSE Algorithms Registration (1/2) . . . . . . . . . 26
 12.3.3. COSE Algorithms Registration (2/2) . . . . . . . . . 26
 12.3.4. JOSE Elliptic Curves Registration . . . . . . . . . 26
 12.3.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 27
 12.3.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 27
 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
 14.2. Informative References . . . . . . . . . . . . . . . . . 31
 Appendix A. Some (NonBinary) Elliptic Curves . . . . . . . . . 33
 A.1. Curves in ShortWeierstrass Form . . . . . . . . . . . . 33
 A.2. Montgomery Curves . . . . . . . . . . . . . . . . . . . . 33
 A.3. Twisted Edwards Curves . . . . . . . . . . . . . . . . . 33
 Appendix B. Elliptic Curve Nomenclature and Finite Fields . . . 34
 B.1. Elliptic Curve Nomenclature . . . . . . . . . . . . . . . 34
 B.2. Finite Fields . . . . . . . . . . . . . . . . . . . . . . 36
 Appendix C. Elliptic Curve Group Operations . . . . . . . . . . 37
 C.1. Group Laws for Weierstrass Curves . . . . . . . . . . . . 37
 C.2. Group Laws for Montgomery Curves . . . . . . . . . . . . 38
 C.3. Group Laws for Twisted Edwards Curves . . . . . . . . . . 39
 Appendix D. Relationships Between Curve Models . . . . . . . . . 40
+ 11.4. Encoding of EllipticCurveBased Algorithms with CMS . . 23
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
+ 12.1. OIDs for Use with PKIX and CMS . . . . . . . . . . . . . 24
+ 12.2. COSE/JOSE IANA Considerations for Wei25519 . . . . . . . 24
+ 12.2.1. COSE Elliptic Curves Registration . . . . . . . . . 24
+ 12.2.2. COSE Algorithms Registration (1/2) . . . . . . . . . 24
+ 12.2.3. COSE Algorithms Registration (2/2) . . . . . . . . . 25
+ 12.2.4. JOSE Elliptic Curves Registration . . . . . . . . . 25
+ 12.2.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 26
+ 12.2.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 26
+ 12.3. COSE/JOSE IANA Considerations for Wei448 . . . . . . . . 26
+ 12.3.1. COSE Elliptic Curves Registration . . . . . . . . . 26
+ 12.3.2. COSE Algorithms Registration (1/2) . . . . . . . . . 27
+ 12.3.3. COSE Algorithms Registration (2/2) . . . . . . . . . 27
+ 12.3.4. JOSE Elliptic Curves Registration . . . . . . . . . 28
+ 12.3.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 28
+ 12.3.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 29
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
+ 14.2. Informative References . . . . . . . . . . . . . . . . . 32
+ Appendix A. Some (NonBinary) Elliptic Curves . . . . . . . . . 34
+ A.1. Curves in ShortWeierstrass Form . . . . . . . . . . . . 34
+ A.2. Montgomery Curves . . . . . . . . . . . . . . . . . . . . 35
+ A.3. Twisted Edwards Curves . . . . . . . . . . . . . . . . . 35
+ Appendix B. Elliptic Curve Nomenclature and Finite Fields . . . 35
+ B.1. Elliptic Curve Nomenclature . . . . . . . . . . . . . . . 35
+ B.2. Finite Fields . . . . . . . . . . . . . . . . . . . . . . 37
+ Appendix C. Elliptic Curve Group Operations . . . . . . . . . . 38
+ C.1. Group Laws for Weierstrass Curves . . . . . . . . . . . . 38
+ C.2. Group Laws for Montgomery Curves . . . . . . . . . . . . 39
+ C.3. Group Laws for Twisted Edwards Curves . . . . . . . . . . 40
+ Appendix D. Relationships Between Curve Models . . . . . . . . . 41
D.1. Mapping between Twisted Edwards Curves and Montgomery
 Curves . . . . . . . . . . . . . . . . . . . . . . . . . 40
 D.2. Mapping between Montgomery Curves and Weierstrass Curves 40
 D.3. Mapping between Twisted Edwards Curves and Weierstrass
Curves . . . . . . . . . . . . . . . . . . . . . . . . . 41
 Appendix E. Curve25519 and Cousins . . . . . . . . . . . . . . . 42
 E.1. Curve Definition and Alternative Representations . . . . 42
 E.2. Switching between Alternative Representations . . . . . . 42
 E.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 44
 Appendix F. Further Mappings . . . . . . . . . . . . . . . . . . 46
 F.1. Isomorphic Mapping between Twisted Edwards Curves . . . . 46
 F.2. Isomorphic Mapping between Montgomery Curves . . . . . . 46
 F.3. Isomorphic Mapping between Weierstrass Curves . . . . . . 47
 F.4. Isogenous Mapping between Weierstrass Curves . . . . . . 48
 Appendix G. Further Cousins of Curve25519 . . . . . . . . . . . 50
 G.1. Further Alternative Representations . . . . . . . . . . . 50
 G.2. Further Switching . . . . . . . . . . . . . . . . . . . . 50
 G.3. Further Domain Parameters . . . . . . . . . . . . . . . . 51
 G.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 52
 G.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 52
 G.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 59
 Appendix H. Point Compression . . . . . . . . . . . . . . . . . 65
 H.1. Point Compression for Weierstrass Curves . . . . . . . . 65
 H.2. Point Compression for Montgomery Curves . . . . . . . . . 66
 H.3. Point Compression for Twisted Edwards Curves . . . . . . 67
 Appendix I. Data Conversions . . . . . . . . . . . . . . . . . . 68
 I.1. Strings and String Operations . . . . . . . . . . . . . . 68
 I.2. Conversion between Bit Strings and Integers (BS2I, I2BS) 69
+ D.2. Mapping between Montgomery Curves and Weierstrass Curves 42
+ D.3. Mapping between Twisted Edwards Curves and Weierstrass
+ Curves . . . . . . . . . . . . . . . . . . . . . . . . . 43
+ Appendix E. Curve25519 and Cousins . . . . . . . . . . . . . . . 43
+ E.1. Curve Definition and Alternative Representations . . . . 43
+ E.2. Switching between Alternative Representations . . . . . . 44
+ E.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 45
+ Appendix F. Further Mappings . . . . . . . . . . . . . . . . . . 47
+ F.1. Isomorphic Mapping between Twisted Edwards Curves . . . . 47
+ F.2. Isomorphic Mapping between Montgomery Curves . . . . . . 48
+ F.3. Isomorphic Mapping between Weierstrass Curves . . . . . . 49
+ F.4. Isogenous Mapping between Weierstrass Curves . . . . . . 50
+ Appendix G. Further Cousins of Curve25519 . . . . . . . . . . . 51
+ G.1. Further Alternative Representations . . . . . . . . . . . 51
+ G.2. Further Switching . . . . . . . . . . . . . . . . . . . . 51
+ G.3. Further Domain Parameters . . . . . . . . . . . . . . . . 52
+ G.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 54
+ G.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 54
+ G.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 60
+ Appendix H. Point Compression . . . . . . . . . . . . . . . . . 66
+ H.1. Point Compression for Weierstrass Curves . . . . . . . . 67
+ H.2. Point Compression for Montgomery Curves . . . . . . . . . 68
+ H.3. Point Compression for Twisted Edwards Curves . . . . . . 68
+ Appendix I. Data Conversions . . . . . . . . . . . . . . . . . . 69
+ I.1. Strings and String Operations . . . . . . . . . . . . . . 69
+ I.2. Conversion between Bit Strings and Integers (BS2I, I2BS) 70
I.3. Conversion between Octet Strings and Integers (OS2I,
 I2OS) . . . . . . . . . . . . . . . . . . . . . . . . . . 69
+ I2OS) . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.4. Conversion between Octet Strings and Bit Strings (OS2BS,
 BS2OS) . . . . . . . . . . . . . . . . . . . . . . . . . 69
+ BS2OS) . . . . . . . . . . . . . . . . . . . . . . . . . 71
I.5. Conversion between Field Elements and Octet Strings
 (FE2OS, OS2FE) . . . . . . . . . . . . . . . . . . . . . 70
+ (FE2OS, OS2FE) . . . . . . . . . . . . . . . . . . . . . 71
I.6. Conversion between Elements of Z mod n and Octet Strings
 (ZnE2OS, OS2ZnE) . . . . . . . . . . . . . . . . . . . . 70
 I.7. Ordering Conventions . . . . . . . . . . . . . . . . . . 71
 I.8. Conversion Between Curve Points and Octet Strings . . . . 72
 Appendix J. Representation Examples Curve25519 Family Members . 74
 J.1. Example with Curve25519 . . . . . . . . . . . . . . . . . 75
 J.2. Example with Edwards25519 . . . . . . . . . . . . . . . . 77
 J.3. Example with Wei25519 . . . . . . . . . . . . . . . . . . 79
 J.4. Example with Wei25519.2 . . . . . . . . . . . . . . . . . 82
 J.5. Example with Wei25519.3 . . . . . . . . . . . . . . . . 84
 Appendix K. Auxiliary Functions . . . . . . . . . . . . . . . . 86
 K.1. Square Roots in GF(q) . . . . . . . . . . . . . . . . . . 86
 K.1.1. Square Roots in GF(q), where q = 3 (mod 4) . . . . . 86
 K.1.2. Square Roots in GF(q), where q = 5 (mod 8) . . . . . 86
 K.2. Inversion . . . . . . . . . . . . . . . . . . . . . . . . 87
 K.3. Mappings to Curve Points . . . . . . . . . . . . . . . . 87
 K.3.1. Mapping to Points of Weierstrass Curve . . . . . . . 88
 K.3.2. Mapping to Points of Montgomery Curve . . . . . . . . 89
 K.3.3. Mapping to Points of Twisted Edwards Curve . . . . . 90
 K.4. Mappings to HighOrder Curve Points . . . . . . . . . . . 90
 K.4.1. Mapping to HighOrder Points of Weierstrass Curve . . 90
 K.4.2. Mapping to HighOrder Points of Montgomery Curve . . 91
 K.4.3. Mapping to HighOrder Points of Twisted Edwards Curve 93
 K.5. Randomized Representation of Curve Points . . . . . . . . 94
 K.6. Completing the Mappings to Curve Points . . . . . . . . . 95
 Appendix L. Curve secp256k1 and Friend . . . . . . . . . . . . . 98
 L.1. Curve Definition and Alternative Representation . . . . . 99
 L.2. Switching Between Representations . . . . . . . . . . . . 99
 L.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 99
 L.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 101
 L.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 101
 L.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 102
 Appendix M. Curve448 and Cousins . . . . . . . . . . . . . . . . 102
 M.1. Curve Definition and Alternative Representations . . . . 102
 M.2. Switching between Alternative Representations . . . . . . 103
 M.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 104
 Appendix N. Further Cousins of Curve448 . . . . . . . . . . . . 107
 N.1. Further Alternative Representations . . . . . . . . . . . 107
 N.2. Further Switching . . . . . . . . . . . . . . . . . . . . 107
 N.3. Further Domain Parameters . . . . . . . . . . . . . . . . 110
 N.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 112
 N.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 112
 N.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 113
 Appendix O. Representation Examples Curve448 Family Members . . 113
 O.1. Example with Curve448 . . . . . . . . . . . . . . . . . . 114
 O.2. Example with Ed448 . . . . . . . . . . . . . . . . . . . 117
 O.3. Example with Wei448 . . . . . . . . . . . . . . . . . . . 120
 O.4. Example with Wei448.1 . . . . . . . . . . . . . . . . . . 123
 O.5. Example with Wei448.3 . . . . . . . . . . . . . . . . . 126
 O.6. Example with Edwards448 . . . . . . . . . . . . . . . . . 128
 Appendix P. Random Integers in Z_n . . . . . . . . . . . . . . . 131
 P.1. Conversion to Integers in Z_n via Modular Reduction . . . 132
 P.2. Conversion to Integers in Z_n via Scaling . . . . . . . . 133
 P.3. Conversion to Integers in Z_n via the Discard Method . . 134
 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 134
+ (ZnE2OS, OS2ZnE) . . . . . . . . . . . . . . . . . . . . 72
+ I.7. Ordering Conventions . . . . . . . . . . . . . . . . . . 72
+ I.8. Conversion Between Curve Points and Octet Strings . . . . 73
+ Appendix J. Representation Examples Curve25519 Family Members . 76
+ J.1. Example with Curve25519 . . . . . . . . . . . . . . . . . 76
+ J.2. Example with Edwards25519 . . . . . . . . . . . . . . . . 79
+ J.3. Example with Wei25519 . . . . . . . . . . . . . . . . . . 81
+ J.4. Example with Wei25519.2 . . . . . . . . . . . . . . . . . 83
+ J.5. Example with Wei25519.3 . . . . . . . . . . . . . . . . 85
+ Appendix K. Auxiliary Functions . . . . . . . . . . . . . . . . 87
+ K.1. Square Roots in GF(q) . . . . . . . . . . . . . . . . . . 88
+ K.1.1. Square Roots in GF(q), where q = 3 (mod 4) . . . . . 88
+ K.1.2. Square Roots in GF(q), where q = 5 (mod 8) . . . . . 88
+ K.2. Inversion . . . . . . . . . . . . . . . . . . . . . . . . 88
+ K.3. Mappings to Curve Points . . . . . . . . . . . . . . . . 89
+ K.3.1. Mapping to Points of Weierstrass Curve . . . . . . . 89
+ K.3.2. Mapping to Points of Montgomery Curve . . . . . . . . 90
+ K.3.3. Mapping to Points of Twisted Edwards Curve . . . . . 91
+ K.4. Mappings to HighOrder Curve Points . . . . . . . . . . . 92
+ K.4.1. Mapping to HighOrder Points of Weierstrass Curve . . 92
+ K.4.2. Mapping to HighOrder Points of Montgomery Curve . . 93
+ K.4.3. Mapping to HighOrder Points of Twisted Edwards Curve 94
+ K.5. Randomized Representation of Curve Points . . . . . . . . 95
+ K.6. Completing the Mappings to Curve Points . . . . . . . . . 96
+ Appendix L. Curve secp256k1 and Friend . . . . . . . . . . . . . 99
+ L.1. Curve Definition and Alternative Representation . . . . . 100
+ L.2. Switching Between Representations . . . . . . . . . . . . 100
+ L.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 100
+ L.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 102
+ L.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 102
+ L.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 103
+ Appendix M. Curve448 and Cousins . . . . . . . . . . . . . . . . 103
+ M.1. Curve Definition and Alternative Representations . . . . 103
+ M.2. Switching between Alternative Representations . . . . . . 104
+ M.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 105
+ Appendix N. Further Cousins of Curve448 . . . . . . . . . . . . 108
+ N.1. Further Alternative Representations . . . . . . . . . . . 108
+ N.2. Further Switching . . . . . . . . . . . . . . . . . . . . 108
+ N.3. Further Domain Parameters . . . . . . . . . . . . . . . . 111
+ N.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 113
+ N.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 113
+ N.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 114
+ Appendix O. Representation Examples Curve448 Family Members . . 114
+ O.1. Example with Curve448 . . . . . . . . . . . . . . . . . . 115
+ O.2. Example with Ed448 . . . . . . . . . . . . . . . . . . . 118
+ O.3. Example with Wei448 . . . . . . . . . . . . . . . . . . . 121
+ O.4. Example with Wei448.1 . . . . . . . . . . . . . . . . . . 124
+ O.5. Example with Wei448.3 . . . . . . . . . . . . . . . . . 127
+ O.6. Example with Edwards448 . . . . . . . . . . . . . . . . . 129
+ Appendix P. Random Integers in Z_n . . . . . . . . . . . . . . . 132
+ P.1. Conversion to Integers in Z_n via Modular Reduction . . . 133
+ P.2. Conversion to Integers in Z_n via Scaling . . . . . . . . 134
+ P.3. Conversion to Integers in Z_n via the Discard Method . . 135
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 135
1. Fostering Code Reuse with New Elliptic Curves
Elliptic curves can be represented using different curve models.
Recently, IETF standardized elliptic curves that are claimed to have
better performance and improved robustness against "real world"
attacks than curves represented in the traditional shortWeierstrass
curve model. These socalled CFRG curves [RFC7748] use the
Montgomery curve model and the model of twisted Edwards curves.
@@ 313,47 +313,73 @@
convert the results back to the original curve (where, in case this
involves an lisogeny, one has to take into account the factor l).
This includes use with ellipticcurve based signature schemes and key
agreement and key transport schemes.
For some examples of curve computations on each of the curves
specified in Appendix E.3 and Appendix G.3, see Appendix J.
4. Examples
4.1. Implementation of X25519
+4.1. Implementation of X25519, Specification of ECDH25519
RFC 7748 [RFC7748] specifies the use of X25519, a cofactor Diffie
Hellman key agreement scheme, with instantiation by the Montgomery
curve Curve25519. This key agreement scheme was already specified in
Section 6.1.2.2 of NIST SP 80056a [SP80056a] for elliptic curves
in shortWeierstrass form. Hence, one can implement X25519 using
existing NIST routines by (1) representing a point of the Montgomery
curve Curve25519 as a point of the Weierstrass curve Wei25519; (2)
instantiating the cofactor DiffieHellman key agreement scheme of
the NIST specification with the resulting point and Wei25519 domain
parameters; (3) representing the key resulting from this scheme
(which is a point of the curve Wei25519 in Weierstrass form) as a
point of the Montgomery curve Curve25519. The representation change
can be implemented via a simple wrapper and involves a single modular
addition (see Appendix E.2). Using this method has the additional
advantage that one can reuse the publicprivate key pair routines,
domain parameter validation, and other checks that are already part
 of the NIST specifications. A NISTcompliant version of cofactor
 DiffieHellman key agreement (denoted by ECDH25519) results if one
 keeps inputs (key contributions) and outputs (shared key) in the
 shortWeierstrass format (and, hence, does not perform Steps (1) and
 (3) above).
+ of the NIST specifications.
 NOTE: At this point, it is unclear whether this implies that a FIPS
 accredited module implementing cofactor DiffieHellman for, e.g.,
 P256 would also extend this accreditation to X25519.
+ A NISTcompliant version of the cofactor DiffieHellman key
+ agreement scheme (denoted by ECDH25519) results if one keeps inputs
+ (key contributions) and preoutput (shared key K) in the short
+ Weierstrass format (and, hence, does not perform Steps (1) and (3)
+ above), where the actual output (shared secret Z) is the xcoordinate
+ of K (if this is an affine point of the curve), represented as a
+ fixedsize octet string in tight MSB/msborder using the FE2OS
+ mapping of Appendix I.5, and where the output is an error indicator
+ otherwise (i.e., if K is the point at infinity O of the curve).
+
+ NOTE 1: A Montgomery version of the cofactor DiffieHellman key
+ agreement scheme (denoted by X25519+) results by incorporating Step
+ (1), (2), and (3) above, i.e., where one keeps inputs (key
+ contributions) and preoutput (shared key K) in the Montgomery curve
+ format, as points of Curve25519, and where one represents all affine
+ points by their xcoordinate, represented as a fixedsize octet
+ string in tight LSB/msborder using the FE2OS mapping of
+ Appendix I.5, where the actual output (shared secret Z) is the
+ representation of the shared key K as defined above (if this is an
+ affine point of the curve), and where the output is an error
+ indicator otherwise (i.e., if K is the point at infinity O of the
+ curve). The scheme X25519, as specified in [RFC7748], is compatible
+ with a more lenient version of this X25519+ scheme, whereby it does
+ not mandate rejection of shared keys in the small subgroup (which are
+ instead represented as if these were the point (0,0) of order two)
+ and where it also accepts a shared key if all points are points of
+ the quadratic twist of Curve25519, rather than of Curve25519 itself
+ (for definitions of these terms, see Appendix B.1).
+
+ NOTE 2: At this point, it is unclear whether a FIPSaccredited module
+ implementing the cofactor DiffieHellman scheme with, e.g., P256
+ would also extend this accreditation to the Montgomery versions
+ X25519+ or X25519.
4.2. Implementation of Ed25519
RFC 8032 [RFC8032] specifies Ed25519, a "full" Schnorr signature
scheme, with instantiation by the twisted Edwards curve Edwards25519.
One can implement the computation of the ephemeral key pair for
Ed25519 using an existing Montgomery curve implementation by (1)
generating a publicprivate key pair (k, R':=k*G') for Curve25519;
(2) representing this publicprivate key as the pair (k, R:=k*G) for
Ed25519. As before, the representation change can be implemented via
@@ 382,22 +408,24 @@
can implement these schemes with the same representation conventions
as used with existing NIST specifications, including bit/byte
ordering, compression functions, and the like. This allows generic
implementations of ECDSA with the hash function SHA256 and with the
NIST curve P256 or with the curve Wei25519 specified in this
specification to reuse the same implementation (instantiated with,
respectively, the NIST P256 elliptic curve domain parameters or with
the domain parameters of curve Wei25519 specified in Appendix E). We
denote by ECDSA25519 the instantiation of ECDSA with SHA256 and with
curve Wei25519, where the signature (r,s) is represented as the
 rightconcatenation of the integers r and s, each represented as
 fixedsize strings with tight MSB/msb ordering (see Appendix I).
+ rightconcatenation of the integers r and s in the interval [1,n1],
+ where n is the order of the base point of the curve in question, each
+ represented as fixedsize octet strings in tight MSB/msborder using
+ the Zn2OS mapping of Appendix I.6.
4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others)
Any existing specification of cryptographic schemes using elliptic
curves in Weierstrass form and that allows introduction of a new
elliptic curve (here: Wei25519) is amenable to similar constructs,
thus spawning "offspring" protocols, simply by instantiating these
using the new curve in shortWeierstrass form, thereby allowing code
and/or specifications reuse and, for implementations that so desire,
carrying out curve computations "under the hood" on Montgomery curve
@@ 411,26 +439,40 @@
We illustrate the construction of such offspring protocols for
Curve448, another Montgomery curve recently standardized by IETF (see
[RFC7748]). Similar to the case with Curve25519, one can represent
points of this curve via different curve models, viz. as points of an
Edwards curve (Ed448) or as points of a shortWeierstrass curve
(Wei448). For the specification of Wei448 and its relationship to
Curve448 and Ed448, see Appendix M. As with ECDH25519, one can now
easily define a NISTcompliant version of cofactor DiffieHellman
key agreement (denoted by ECDH448), by simply reusing the example of
Section 4.1, but now using the shortWeierstrass curve Wei448, rather
 than Wei25519. Similarly, one can easily specify ECDSA with Wei448
+ than Wei25519 (with the same representation and bit/byteordering
+ conventions). Similarly, one can easily specify ECDSA with Wei448
and a suitable hash function, by simply reusing the example of
Section 4.3, but now using the shortWeierstrass curve Wei448, rather
than Wei25519, and picking as hash function SHAKE256 [FIPS202] with
output size of d=512 bits. We denote by ECDSA448 the resulting
 signature scheme (with the same bit/byteordering conventions).
+ signature scheme (with the same representation and bit/byteordering
+ conventions).
+
+ NOTE: A Montgomery version of the cofactor DiffieHellman key
+ agreement scheme (denoted by X448+) results by reusing the
+ description of X25519+ in Section 4.1, but now using the Montgomery
+ curve Curve448, rather than Curve25519 (with the same checks and
+ representation and bit/byteordering conventions). The scheme X448,
+ as specified in [RFC7748], is compatible with a more lenient version
+ of this X448+ scheme, whereby it does not mandate rejection of shared
+ keys in the small subgroup (which are instead again represented as if
+ these were the point (0,0) of order two) and where it also accepts a
+ shared key if all points are points of the quadratic twist of
+ Curve448, rather than of Curve448 itself.
5. Caveats
The examples above illustrate how specifying the Weierstrass curve
Wei25519 (or any curve in shortWeierstrass format, for that matter)
may facilitate reuse of existing code and may simplify standards
development. However, the following caveats apply:
5.1. Wire Format
@@ 583,21 +625,21 @@
implementation of Wei25519, see .
For support of this curve in tinydtls, see .
According to , an
implementation of Wei25519 on the Kinets LTC ECC HW platform improves
the performance by over a factor ten compared to a standalone
implementation of Curve25519 without hardware support.
The signature scheme ECDSA25519 (see Section 4.3) is supported in
 .
+ [RFC8928].
8. Security Considerations
The different representations of elliptic curve points discussed in
this document are all obtained using a publicly known transformation,
which is either an isomorphism or a lowdegree isogeny. It is well
known that an isomorphism maps elliptic curve points to equivalent
mathematical objects and that the complexity of cryptographic
problems (such as the discrete logarithm problem) of curves related
via a lowdegree isogeny are tightly related. Thus, the use of these
@@ 655,70 +697,70 @@
see Appendix K.6.
10. Using Wei25519 and Wei448 with COSE and JOSE
This section defines algorithm encodings and representations enabling
the use of the curves Wei25519 and Wei448 and their use with ECDH and
ECDSA with JOSE [RFC7518] and COSE [RFC8152] messages.
All octet string encodings below use the MSB/msbordering conventions
as defined in Appendix I.7. For CBOR representation details, we
 refer to [RFC7049]; for base64url encodings, we refer to [RFC4648].
+ refer to [RFC8949]; for base64url encodings, we refer to [RFC4648].
10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE
For Weierstrass curves, the representation of the point at infinity O
is curvespecific (see Appendix H.1). For the shortWeierstrass
curve Wei25519, we define O:=(1,0), whereas for Wei448, we define
O:=(1,0).
The encodings below specify the use of shortWeierstrass curves with
COSE (see Section 10.1.1) and JOSE (see Section 10.1.2), where the
encoding for a specific curve results by setting the "crv" parameter
 to the unique name of the curve in question (e.g., "Wei25519" for the
+ to the unique name of the curve in question (i.e., "Wei25519" for the
curve Wei25519 and "Wei448" for the curve Wei448).
10.1.1. Encoding of ShortWeierstrass Curves with COSE
With COSE, points of shortWeierstrass curves are encoded using the
"EC2" key type (Section 13.1.1 of [RFC8152]) or the "OKP" key type
(Section 7.2 of [ID.ietfcoserfc8152bisalgs]), which are
instantiated by setting the "crv" parameter to the (unique) name of
the curve in question and the "kty" parameter to "EC2" or "OKP",
respectively, where key typespecific settings are as follows:
a. With the "EC2" type, each affine point (X, Y) is encoded by
setting the parameters "x" and "y" to the octet string
representations of the elements X and Y, respectively, in tight
MSB/msborder, and converting each to a CBOR byte string. Each
compressed point (X, t) is encoded by setting the parameter "x"
to the octet representation of the element X, in tight MSB/msb
order, converted to a CBOR byte string, and by setting the
 parameter "y" to the CBOR False or CBOR True value, depending on
+ parameter "y" to the CBOR false or CBOR true value, depending on
whether, respectively, t=0 or t=1. For representation details
and for details on the reverse mappings, see Appendix I.8. (Note
that for affine points this representation is consistent with the
"EC2" representation in Section 13.1.1 of [RFC8152].)
b. With the "OKP" type, each point is encoded by setting the
parameter "x" to the "squeezed" point representation of this
point, in MSB/msborder, and converting this to a CBOR byte
string. For representation details and for details on the
reverse mappings, see Appendix I.8. (Note that for affine points
this representation is consistent with the "OKP" representation
in Section 7.2 of [ID.ietfcoserfc8152bisalgs], which affords
a curvespecific octet string encoding.)
 In either case, if the point is a public key, the parameter "d"
 encodes the corresponding private key, using the octet string
 representation, in tight MSB/msborder, and converting this to a CBOR
 byte string (see Appendix I.6).
+ In either case, if the point is a public key (i.e., the private key
+ is welldefined), the parameter "d" encodes the corresponding private
+ key, using the octet string representation, in tight MSB/msborder,
+ and converting this to a CBOR byte string (see Appendix I.6).
For curve points, the "crv" parameter and the parameters referenced
with the applicable key typespecific settings above MUST be present
in the structure, whereas the parameter "d" MUST NOT be present,
while for private keys, the parameters "crv" and "d" MUST be present
and the applicable key typespecific parameters of the corresponding
publickey are RECOMMENDED to be present.
10.1.2. Encoding of ShortWeierstrass Curves with JOSE
@@ 796,23 +838,25 @@
ECDSA scheme defined in Section 4.3 and "ECDSA448" for the scheme
defined in Section 4.4). Note that, in this case, the "alg" name
uniquely defines the curve (and, thereby, implicitly the underlying
"crv" parameter) and the underlying hash function.
10.2.1. Encoding of ECDSA Instantiations with COSE
Instantiations of ECDSA used with COSE use the following encodings of
inputs and outputs:
 a. The message m is the COSE_Sign structure as specified in
 Section 4.1 of [RFC8152], converted to a bit string, using the
 OS2BS mapping of Appendix I.4;
+ a. The message m is the COSE Sig_structure as specified in
+ Section 4.4 of [RFC8152], converted to the CBOR byte string
+ ToBeSigned in accordance with the Core Deterministic Encoding
+ Requirements of Section 4.2.1 of [RFC8949]), converted to a bit
+ string using the OS2BS mapping of Appendix I.4;
b. The public key Q and the private key d are encoded as specified
in Section 10.1.1, where the "crv" parameter is set to the unique
name of the curve used with this particular instantiation of
ECDSA;
c. The Cose signature is encoded as the rightconcatenation of the
octet string representations of the coordinates of the signature
pair (r, s), in lefttoright order, where r and s are each
represented as octet strings in tight MSB/msborder using the
@@ 827,97 +871,114 @@
string (each of length l) to, respectively, the integers r and s
in Z_n, via the strict OS2ZnE mapping of Appendix I.6.
When using a COSE key for this algorithm, if the "alg" field is
present, it MUST be set to the (unique) name of this particular
instantiation of ECDSA and the "crv" parameter MUST be set to the
(unique) name of the corresponding curve; if the "key_ops" field is
present, it MUST include "sign" when creating an ECDSA signature and
it MUST include "verify" when verifying an ECDSA signature.
+ NOTE: Care should be taken that signers and verifiers do have a
+ common understanding of message encoding rules, since otherwise
+ signature verification may fail for messages with the same semantics.
+ As an example, if there is ambiguity as to whether to represent the
+ binary digit 0 as the integer 0 or as the CBOR false value
+ (represented as the CBOR bit string b000_00000 or b111_101000,
+ respectively), signing and signature verification may depend on
+ different ToBeSigned strings and, thereby, may fail unexpectedly.
+ This explains the (strong) requirement for deterministic encoding
+ rules above and, thereby, the requirement for strong typing of any
+ CBOR encodings used with signed messages. Further care should be
+ taken that message decoding rules are always unambiguous, since
+ otherwise the semantics of signed messages may not be clear or the
+ unforgeability property of signatures may be jeopardized.
+
10.2.2. Encoding of ECDSA Instantiations with JOSE
Instantiations of ECDSA used with JOSE use the following encodings of
inputs and outputs:
a. The message m is the JWS Signing Input as specified in [RFC7515],
converted to a bit string, using the OS2BS mapping of
Appendix I.4;
b. The public key and the private key are encoded as specified in
Section 10.1.2, where the "crv" parameter is set to the unique
name of the curve used with this particular instantiation of
ECDSA;
c. The JWS signature is encoded as the rightconcatenation of the
octet string representations of the coordinates of the signature
pair (r, s), in lefttoright order, where r and s are each
 represented in tight MSB/msborder (see Appendix I.7), converted
 using the base64url encoding. Note that, since we use a tight
 representation, this rightconcatenated octet string has fixed
 size 2*l, where the parameter l is uniquely defined by the set
 Z_n in question (where n is the (prime) order of the base point
 of the curve in question). The inverse mapping results by
 checking that the purported encoded signature (after base64url
 decoding) has indeed size 2*l, and by converting the leftside
 and rightside halves of this octet string (each of length l) to,
 respectively, the integers r and s in Z_n, via the strict OS2ZnE
 mapping of Appendix I.6.
+ represented as octet strings in tight MSB/msborder using the
+ ZnE2OS mapping of Appendix I.6, converted using the base64url
+ encoding. Note that, since we use a tight representation, this
+ rightconcatenated octet string has fixed size 2*l, where the
+ parameter l is uniquely defined by the set Z_n in question (where
+ n is the (prime) order of the base point of the curve in
+ question). The inverse mapping results by checking that the
+ purported encoded signature (after base64url decoding) has indeed
+ size 2*l, and by converting the leftside and rightside halves
+ of this octet string (each of length l) to, respectively, the
+ integers r and s in Z_n, via the strict OS2ZnE mapping of
+ Appendix I.6.
When using a JOSE key for this algorithm, if the "alg" field is
present, it MUST be set to the (unique) name of this particular
instantiation of ECDSA and the "crv" parameter MUST be set to the
(unique) name of the corresponding curve; if the "key_ops" field is
present, it MUST include "sign" when creating an ECDSA signature and
it MUST include "verify" when verifying an ECDSA signature; if the
JWK _use_ field is present, its value MUST be "sig".
10.3. Using ECDH25519 and ECDH448 with COSE and JOSE
NIST SP 80056a [SP80056a] specifies the cofactor ellipticcurve
DiffieHellman key agreement scheme (cofactor ECDH) and can be
instantiated with a suitable elliptic curve in shortWeierstrass form
(that satisfies particular cryptographic criteria). While this
completely specifies the internal workings of the key agreement
scheme in question, this does not uniquely specify the input/output
formats:
a. The cofactor ECDH scheme is a twoparty key agreement scheme
 that takes as inputs a private key d from one of the parties and
 a point Q' obtained from the other party and produces a shared
 key K:=h*(d*Q'), where h and n are, respectively, the cofactor
 and the order of the base point of the curve in question and
 where Q' is a point of this curve. If this shared key K is the
 point at infinity O of the curve, the output is an error message;
+ that takes as inputs a private key d in the interval [1,n1] from
+ one of the parties and a point Q' obtained from the other party
+ and produces a shared key K:=h*(d*Q'), where h and n are,
+ respectively, the cofactor and the order of the base point of
+ the curve in question and where Q' is a point of this curve. If
+ this shared key K is the point at infinity O of the curve, the
+ output is an error indicator;
b. If the shared key K is an affine point of the curve, the output
 is the (raw) shared secret Z, which is the octet representation
 of the xcoordinate of K, using the FE2OS mapping of
 Appendix I.5, represented in tightMSB/msborder (see
+ is the (raw) shared secret Z, which is the fixedsize octet
+ representation of the xcoordinate of K, using the FE2OS mapping
+ of Appendix I.5, represented in tightMSB/msborder (see
Appendix I.7).
(NOTE: A subsequent key derivation function (kdf) takes as inputs
the shared secret Z and side information OtherInfo and produces
as output an octet string of DerivedKeyingMaterial, where details
depend on the used kdf in question. This step is out of scope.)
The inputs and outputs are uniquely determined by specifying the
 encodings of private keys, curve points, and the error message for
+ encodings of private keys, curve points, and the error indicator for
this key agreement scheme.
The encodings below specify the use of instantiations of ECDH with
COSE (see Section 10.3.1) and JOSE (see Section 10.3.2), where the
encoding for a specific cofactor ECDH instantiation (i.e., with a
specific shortWeierstrass curve) results by setting the "crv"
parameter to the unique name of the underlying curve in question and
the "alg" parameter to the unique name of the specific key agreement
 scheme instantiation (e.g., "ECDH25519" for the cofactor ECDH scheme
+ scheme instantiation (i.e., "ECDH25519" for the cofactor ECDH scheme
defined in Section 4.1 and "ECDH448" for the scheme defined in
Section 4.4). Note that, in this case, the "alg" name uniquely
defines the curve (and, thereby, implicitly the underlying "crv"
parameter).
10.3.1. Encoding of cofactor ECDH with COSE
Instantiations of cofactor ECDH used with COSE use the following
encodings of inputs and outputs:
@@ 995,34 +1056,34 @@
11.3. Encoding of cofactor ECDH and Other Algorithms with PKIX
With [RFC5480], the algorithm field in the SubjectPublicKeyInfo
structure indicates the algorithm and the elliptic curve domain
parameters for a specific curve, where that specification defines
three algorithm identifiers (viz. idecPublicKey, idecDH, and id
ecMQV). Each of these algorithms can be instantiated with suitable
alliptic curves, thereby allowing support for their use with the
curves Wei25519 and Wei448, where these curves are identified by
 their unique object identifiers idwei25519 and idwei448,
+ their unique object identifiers idWei25519 and idWei448,
respectively, (see Section 11.1) and where all other aspects are
specified in [RFC5480].
11.4. Encoding of EllipticCurveBased Algorithms with CMS
With [RFC5753], ellipticcurve based algorithms should use one of the
elliptic curve domain parameters specified in [RFC5480], where the
unique name of each such curve is identified by the object identifier
of this curve defined in that document. Each of these algorithms can
be instantiated with suitable elliptic curves, thereby allowing
support for their use with the curves Wei25519 and Wei448, where
these curves are identified by their unique object identifiers id
 wei25519 and idwei448, respectively, (see Section 11.1) and where
+ Wei25519 and idWei448, respectively, (see Section 11.1) and where
all other aspects are specified in [RFC5753].
12. IANA Considerations
Code points are requested for curves Wei25519 and Wei448 and their
use with ECDSA and cofactor ECDH, using the representation
conventions of this document.
New code points would be required in case one wishes to specify one
or more other "offspring" protocols beyond those exemplified in
@@ 1193,21 +1254,21 @@
Name: ECDSA448;
Value: TBD (Requested value: 48);
Description: ECDSA with SHAKE256 and curve Wei448;
Change Controller: IESG;
Reference: specified in Section 4.4 of this specification; for
 encodings, see Section 10.1;
+ encodings, see Section 10.2;
Recommended: Yes.
12.3.3. COSE Algorithms Registration (2/2)
This section registers the following value in the IANA "COSE
Algorithms" registry [IANA.COSE.Algorithms].
Name: ECDH448;
@@ 1352,24 +1413,20 @@
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, .
 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
 October 2013, .

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, .
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting MandatorytoImplement Algorithms",
@@ 1402,20 +1459,25 @@
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key
Infrastructure: Additional Algorithm Identifiers for
RSASSAPSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019,
.
+ [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
+ Representation (CBOR)", STD 94, RFC 8949,
+ DOI 10.17487/RFC8949, December 2020,
+ .
+
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography, , June 2009.
[SEC2] SEC2, "SEC 2: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography, , January 2010.
[SP80056a]
NIST SP 80056a, "Recommendation for PairWise Key
Establishment Schemes Using Discrete Log Cryptography,
Revision 3", US Department of Commerce/National Institute
@@ 1467,20 +1529,25 @@
[IANA.JOSE.Curves]
IANA, "JSON Web Key Elliptic Curve", IANA,
https://www.iana.org/assignments/jose/jose.xhtml#webkey
ellipticcurve.
[MontLadder]
P.L. Montgomery, "Speeding the Pollard and Elliptic Curve
Methods of Factorization", Mathematics of
Computation, Vol. 48, 1987.
+ [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
+ "AddressProtected Neighbor Discovery for LowPower and
+ Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
+ 2020, .
+
[Rosener] N. Rosener, "Evaluating the Performance of Transformations
Between Curve Representations in Elliptic Curve
Cryptography for Constrained Device Security",
M.Sc. Universitat Bremen, August 2018.
[SWUmap] E. Brier, JS. Coron, Th. Icart, D. Madore, H. Randriam,
M. Tibouchi, "Efficient Indifferentiable Hashing into
Ordinary Elliptic Curves", CRYPTO 2010, Lecture Notes in
Computer Science, Vol. 6223, New York: SpringerVerlag,
2010.
@@ 4506,24 +4573,25 @@
if u2 is a random element of a sufficiently large subset of GF(p)
(see, e.g., [Tibouchicleancut]). This allows generating u1 and u2,
e.g., each as random bit strings of length m1, where m is the bit
length of p, thereby allowing the pair (u1, u2)  a random (2*m2)
bit string  to be used unaltered in this construction, without the
need to carry out a reduction modulo p first. Table 2 illustrates
how this can be used to realize randomized representations and
completed mappings for each curve in Table 1, where these randomized
bit strings have the same bytelength as the (tight) representation
of affine curve points. (Here, the field elements u1 and u2 are
 obtained from their bit string representations using the b2O mapping
 of Appendix I.2 and the (nonstrict) OS2FE mapping of Appendix I.5.)
 For each curve in Table 2, we refer to this version of the default
 completed mapping as being the "cleancut" default completed mapping.
+ obtained from their bit string representations using the BS2OS
+ mapping of Appendix I.4 and the (nonstrict) OS2FE mapping of
+ Appendix I.5.) For each curve in Table 2, we refer to this version
+ of the default completed mapping as being the "cleancut" default
+ completed mapping.
++++
 Curve  leftside  rightside 
++++
 NIST P224 [FIPS1864]  {u1:224}  {s1:1, s2:1, u2:222} 
 NIST P256 [FIPS1864]  {s1:1, u1:255}  {s2:1, u2:255} 
 NIST P384 [FIPS1864]  {u1:384}  {s1:1, s2:1, u2:382} 
 NIST P521 [FIPS1864]  {s1:1, u1:527}  {s2:1, u2:527} 
 brainpoolP224r1  {s1:1, u1:223}  {s2:1, u2:223} 
 [RFC5639]   
@@ 4558,25 +4626,25 @@
Table 3 shows an alternative arrangement, tailored towards optimizing
the efficiency of computing randomized representations of curve
points (see Appendix K.5), rather than towards avoiding modular
reductions in the mappings to curve points. (Here, we used
randomized representations of elements of GF(p), when appropriate,
and the bias upper bound 2^{64} from Table 4.) For each curve in
Table 3, we refer to this version of the default completed mapping as
being the "pointrandomizationoptimized" default completed mapping
(where both versions coincide if the prime number p is relatively
close to a power of two). (Here, the field elements u1 and u2 are
 obtained from their bit string representations using the b2O mapping
 of Appendix I.2 and the (nonstrict) OS2FE mapping of Appendix I.5.)
 Suitability of each of these completed mappings is application
 specific (and also depends on the maximum bias one can tolerate).
 Further details are out of scope of this document.
+ obtained from their bit string representations using the BS2OS
+ mapping of Appendix I.4 and the (nonstrict) OS2FE mapping of
+ Appendix I.5.) Suitability of each of these completed mappings is
+ applicationspecific (and also depends on the maximum bias one can
+ tolerate). Further details are out of scope of this document.
++++
 Curve  leftside  rightside 
++++
 NIST P224 [FIPS1864]  {u1:224}  {s1:1, s2:1, u2:222} 
 NIST P256 [FIPS1864]  {u1:288}  {s1:1, s2:1, u2:222} 
 NIST P384 [FIPS1864]  {u1:384}  {s1:1, s2:1, u2:382} 
 NIST P521 [FIPS1864]  {s1:1, u1:527}  {s2:1, u2:527} 
 brainpoolP224r1  {s1:1, u1:287}  {s2:1, u2:159} 
 [RFC5639]   