draft-ietf-lwig-curve-representations-15.txt   draft-ietf-lwig-curve-representations-16.txt 
lwig R. Struik lwig R. Struik
Internet-Draft Struik Security Consultancy Internet-Draft Struik Security Consultancy
Intended status: Standards Track December 2, 2020 Intended status: Standards Track December 9, 2020
Expires: June 5, 2021 Expires: June 12, 2021
Alternative Elliptic Curve Representations Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-15 draft-ietf-lwig-curve-representations-16
Abstract Abstract
This document specifies how to represent Montgomery curves and This document specifies how to represent Montgomery curves and
(twisted) Edwards curves as curves in short-Weierstrass form and (twisted) Edwards curves as curves in short-Weierstrass form and
illustrates how this can be used to carry out elliptic curve illustrates how this can be used to carry out elliptic curve
computations using existing implementations of, e.g., ECDSA and ECDH computations using existing implementations of, e.g., ECDSA and ECDH
using NIST prime curves. We also provide extensive background using NIST prime curves. We also provide extensive background
material that may be useful for implementers of elliptic curve material that may be useful for implementers of elliptic curve
cryptography. cryptography.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2021. This Internet-Draft will expire on June 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Fostering Code Reuse with New Elliptic Curves . . . . . . . . 5 1. Fostering Code Reuse with New Elliptic Curves . . . . . . . . 5
2. Specification of Wei25519 . . . . . . . . . . . . . . . . . . 6 2. Specification of Wei25519 . . . . . . . . . . . . . . . . . . 6
3. Use of Representation Switches . . . . . . . . . . . . . . . 6 3. Use of Representation Switches . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Implementation of X25519 . . . . . . . . . . . . . . . . 7 4.1. Implementation of X25519, Specification of ECDH25519 . . 7
4.2. Implementation of Ed25519 . . . . . . . . . . . . . . . . 8 4.2. Implementation of Ed25519 . . . . . . . . . . . . . . . . 9
4.3. Specification of ECDSA25519 . . . . . . . . . . . . . . . 8 4.3. Specification of ECDSA25519 . . . . . . . . . . . . . . . 9
4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others) . . . 9 4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others) . . . 10
5. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Representation Conventions . . . . . . . . . . . . . . . 10 5.2. Representation Conventions . . . . . . . . . . . . . . . 11
5.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 10 5.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 11
6. Implementation Considerations . . . . . . . . . . . . . . . . 11 6. Implementation Considerations . . . . . . . . . . . . . . . . 12
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
10. Using Wei25519 and Wei448 with COSE and JOSE . . . . . . . . 14 10. Using Wei25519 and Wei448 with COSE and JOSE . . . . . . . . 15
10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE . . . 15 10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE . . . 16
10.1.1. Encoding of Short-Weierstrass Curves with COSE . . . 15 10.1.1. Encoding of Short-Weierstrass Curves with COSE . . . 16
10.1.2. Encoding of Short-Weierstrass Curves with JOSE . . . 16 10.1.2. Encoding of Short-Weierstrass Curves with JOSE . . . 17
10.2. Using ECDSA25519 and ECDSA448 with COSE and JOSE . . . . 17 10.2. Using ECDSA25519 and ECDSA448 with COSE and JOSE . . . . 18
10.2.1. Encoding of ECDSA Instantiations with COSE . . . . . 17 10.2.1. Encoding of ECDSA Instantiations with COSE . . . . . 18
10.2.2. Encoding of ECDSA Instantiations with JOSE . . . . . 18 10.2.2. Encoding of ECDSA Instantiations with JOSE . . . . . 19
10.3. Using ECDH25519 and ECDH448 with COSE and JOSE . . . . . 19 10.3. Using ECDH25519 and ECDH448 with COSE and JOSE . . . . . 20
10.3.1. Encoding of co-factor ECDH with COSE . . . . . . . . 20 10.3.1. Encoding of co-factor ECDH with COSE . . . . . . . . 21
10.3.2. Encoding of co-factor ECDH with JOSE . . . . . . . . 20 10.3.2. Encoding of co-factor ECDH with JOSE . . . . . . . . 22
11. Using Wei25519 and Wei448 with PKIX and CMS . . . . . . . . . 21 11. Using Wei25519 and Wei448 with PKIX and CMS . . . . . . . . . 22
11.1. Encoding of Short-Weierstrass Curves with PKIX . . . . . 21 11.1. Encoding of Short-Weierstrass Curves with PKIX . . . . . 22
11.2. Encoding of ECDSA Instantiations with PKIX . . . . . . . 21 11.2. Encoding of ECDSA Instantiations with PKIX . . . . . . . 22
11.3. Encoding of co-factor ECDH and Other Algorithms with 11.3. Encoding of co-factor ECDH and Other Algorithms with
PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 21 PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.4. Encoding of Elliptic-Curve-Based Algorithms with CMS . . 22 11.4. Encoding of Elliptic-Curve-Based Algorithms with CMS . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12.1. OIDs for Use with PKIX and CMS . . . . . . . . . . . . . 22 12.1. OIDs for Use with PKIX and CMS . . . . . . . . . . . . . 24
12.2. COSE/JOSE IANA Considerations for Wei25519 . . . . . . . 23 12.2. COSE/JOSE IANA Considerations for Wei25519 . . . . . . . 24
12.2.1. COSE Elliptic Curves Registration . . . . . . . . . 23 12.2.1. COSE Elliptic Curves Registration . . . . . . . . . 24
12.2.2. COSE Algorithms Registration (1/2) . . . . . . . . . 23 12.2.2. COSE Algorithms Registration (1/2) . . . . . . . . . 24
12.2.3. COSE Algorithms Registration (2/2) . . . . . . . . . 23 12.2.3. COSE Algorithms Registration (2/2) . . . . . . . . . 25
12.2.4. JOSE Elliptic Curves Registration . . . . . . . . . 24 12.2.4. JOSE Elliptic Curves Registration . . . . . . . . . 25
12.2.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 24 12.2.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 26
12.2.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 25 12.2.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 26
12.3. COSE/JOSE IANA Considerations for Wei448 . . . . . . . . 25 12.3. COSE/JOSE IANA Considerations for Wei448 . . . . . . . . 26
12.3.1. COSE Elliptic Curves Registration . . . . . . . . . 25 12.3.1. COSE Elliptic Curves Registration . . . . . . . . . 26
12.3.2. COSE Algorithms Registration (1/2) . . . . . . . . . 26 12.3.2. COSE Algorithms Registration (1/2) . . . . . . . . . 27
12.3.3. COSE Algorithms Registration (2/2) . . . . . . . . . 26 12.3.3. COSE Algorithms Registration (2/2) . . . . . . . . . 27
12.3.4. JOSE Elliptic Curves Registration . . . . . . . . . 26 12.3.4. JOSE Elliptic Curves Registration . . . . . . . . . 28
12.3.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 27 12.3.5. JOSE Algorithms Registration (1/2) . . . . . . . . . 28
12.3.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 27 12.3.6. JOSE Algorithms Registration (2/2) . . . . . . . . . 29
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Some (Non-Binary) Elliptic Curves . . . . . . . . . 33 Appendix A. Some (Non-Binary) Elliptic Curves . . . . . . . . . 34
A.1. Curves in Short-Weierstrass Form . . . . . . . . . . . . 33 A.1. Curves in Short-Weierstrass Form . . . . . . . . . . . . 34
A.2. Montgomery Curves . . . . . . . . . . . . . . . . . . . . 33 A.2. Montgomery Curves . . . . . . . . . . . . . . . . . . . . 35
A.3. Twisted Edwards Curves . . . . . . . . . . . . . . . . . 33 A.3. Twisted Edwards Curves . . . . . . . . . . . . . . . . . 35
Appendix B. Elliptic Curve Nomenclature and Finite Fields . . . 34 Appendix B. Elliptic Curve Nomenclature and Finite Fields . . . 35
B.1. Elliptic Curve Nomenclature . . . . . . . . . . . . . . . 34 B.1. Elliptic Curve Nomenclature . . . . . . . . . . . . . . . 35
B.2. Finite Fields . . . . . . . . . . . . . . . . . . . . . . 36 B.2. Finite Fields . . . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Elliptic Curve Group Operations . . . . . . . . . . 37 Appendix C. Elliptic Curve Group Operations . . . . . . . . . . 38
C.1. Group Laws for Weierstrass Curves . . . . . . . . . . . . 37 C.1. Group Laws for Weierstrass Curves . . . . . . . . . . . . 38
C.2. Group Laws for Montgomery Curves . . . . . . . . . . . . 38 C.2. Group Laws for Montgomery Curves . . . . . . . . . . . . 39
C.3. Group Laws for Twisted Edwards Curves . . . . . . . . . . 39 C.3. Group Laws for Twisted Edwards Curves . . . . . . . . . . 40
Appendix D. Relationships Between Curve Models . . . . . . . . . 40 Appendix D. Relationships Between Curve Models . . . . . . . . . 41
D.1. Mapping between Twisted Edwards Curves and Montgomery 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 Curves . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix E. Curve25519 and Cousins . . . . . . . . . . . . . . . 42 D.2. Mapping between Montgomery Curves and Weierstrass Curves 42
E.1. Curve Definition and Alternative Representations . . . . 42 D.3. Mapping between Twisted Edwards Curves and Weierstrass
E.2. Switching between Alternative Representations . . . . . . 42 Curves . . . . . . . . . . . . . . . . . . . . . . . . . 43
E.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 44 Appendix E. Curve25519 and Cousins . . . . . . . . . . . . . . . 43
Appendix F. Further Mappings . . . . . . . . . . . . . . . . . . 46 E.1. Curve Definition and Alternative Representations . . . . 43
F.1. Isomorphic Mapping between Twisted Edwards Curves . . . . 46 E.2. Switching between Alternative Representations . . . . . . 44
F.2. Isomorphic Mapping between Montgomery Curves . . . . . . 46 E.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 45
F.3. Isomorphic Mapping between Weierstrass Curves . . . . . . 47 Appendix F. Further Mappings . . . . . . . . . . . . . . . . . . 47
F.4. Isogenous Mapping between Weierstrass Curves . . . . . . 48 F.1. Isomorphic Mapping between Twisted Edwards Curves . . . . 47
Appendix G. Further Cousins of Curve25519 . . . . . . . . . . . 50 F.2. Isomorphic Mapping between Montgomery Curves . . . . . . 48
G.1. Further Alternative Representations . . . . . . . . . . . 50 F.3. Isomorphic Mapping between Weierstrass Curves . . . . . . 49
G.2. Further Switching . . . . . . . . . . . . . . . . . . . . 50 F.4. Isogenous Mapping between Weierstrass Curves . . . . . . 50
G.3. Further Domain Parameters . . . . . . . . . . . . . . . . 51 Appendix G. Further Cousins of Curve25519 . . . . . . . . . . . 51
G.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 52 G.1. Further Alternative Representations . . . . . . . . . . . 51
G.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 52 G.2. Further Switching . . . . . . . . . . . . . . . . . . . . 51
G.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 59 G.3. Further Domain Parameters . . . . . . . . . . . . . . . . 52
Appendix H. Point Compression . . . . . . . . . . . . . . . . . 65 G.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 54
H.1. Point Compression for Weierstrass Curves . . . . . . . . 65 G.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 54
H.2. Point Compression for Montgomery Curves . . . . . . . . . 66 G.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 60
H.3. Point Compression for Twisted Edwards Curves . . . . . . 67 Appendix H. Point Compression . . . . . . . . . . . . . . . . . 66
Appendix I. Data Conversions . . . . . . . . . . . . . . . . . . 68 H.1. Point Compression for Weierstrass Curves . . . . . . . . 67
I.1. Strings and String Operations . . . . . . . . . . . . . . 68 H.2. Point Compression for Montgomery Curves . . . . . . . . . 68
I.2. Conversion between Bit Strings and Integers (BS2I, I2BS) 69 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, I.3. Conversion between Octet Strings and Integers (OS2I,
I2OS) . . . . . . . . . . . . . . . . . . . . . . . . . . 69 I2OS) . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.4. Conversion between Octet Strings and Bit Strings (OS2BS, I.4. Conversion between Octet Strings and Bit Strings (OS2BS,
BS2OS) . . . . . . . . . . . . . . . . . . . . . . . . . 69 BS2OS) . . . . . . . . . . . . . . . . . . . . . . . . . 71
I.5. Conversion between Field Elements and Octet Strings 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 I.6. Conversion between Elements of Z mod n and Octet Strings
(ZnE2OS, OS2ZnE) . . . . . . . . . . . . . . . . . . . . 70 (ZnE2OS, OS2ZnE) . . . . . . . . . . . . . . . . . . . . 72
I.7. Ordering Conventions . . . . . . . . . . . . . . . . . . 71 I.7. Ordering Conventions . . . . . . . . . . . . . . . . . . 72
I.8. Conversion Between Curve Points and Octet Strings . . . . 72 I.8. Conversion Between Curve Points and Octet Strings . . . . 73
Appendix J. Representation Examples Curve25519 Family Members . 74 Appendix J. Representation Examples Curve25519 Family Members . 76
J.1. Example with Curve25519 . . . . . . . . . . . . . . . . . 75 J.1. Example with Curve25519 . . . . . . . . . . . . . . . . . 76
J.2. Example with Edwards25519 . . . . . . . . . . . . . . . . 77 J.2. Example with Edwards25519 . . . . . . . . . . . . . . . . 79
J.3. Example with Wei25519 . . . . . . . . . . . . . . . . . . 79 J.3. Example with Wei25519 . . . . . . . . . . . . . . . . . . 81
J.4. Example with Wei25519.2 . . . . . . . . . . . . . . . . . 82 J.4. Example with Wei25519.2 . . . . . . . . . . . . . . . . . 83
J.5. Example with Wei25519.-3 . . . . . . . . . . . . . . . . 84 J.5. Example with Wei25519.-3 . . . . . . . . . . . . . . . . 85
Appendix K. Auxiliary Functions . . . . . . . . . . . . . . . . 86 Appendix K. Auxiliary Functions . . . . . . . . . . . . . . . . 87
K.1. Square Roots in GF(q) . . . . . . . . . . . . . . . . . . 86 K.1. Square Roots in GF(q) . . . . . . . . . . . . . . . . . . 88
K.1.1. Square Roots in GF(q), where q = 3 (mod 4) . . . . . 86 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) . . . . . 86 K.1.2. Square Roots in GF(q), where q = 5 (mod 8) . . . . . 88
K.2. Inversion . . . . . . . . . . . . . . . . . . . . . . . . 87 K.2. Inversion . . . . . . . . . . . . . . . . . . . . . . . . 88
K.3. Mappings to Curve Points . . . . . . . . . . . . . . . . 87 K.3. Mappings to Curve Points . . . . . . . . . . . . . . . . 89
K.3.1. Mapping to Points of Weierstrass Curve . . . . . . . 88 K.3.1. Mapping to Points of Weierstrass Curve . . . . . . . 89
K.3.2. Mapping to Points of Montgomery Curve . . . . . . . . 89 K.3.2. Mapping to Points of Montgomery Curve . . . . . . . . 90
K.3.3. Mapping to Points of Twisted Edwards Curve . . . . . 90 K.3.3. Mapping to Points of Twisted Edwards Curve . . . . . 91
K.4. Mappings to High-Order Curve Points . . . . . . . . . . . 90 K.4. Mappings to High-Order Curve Points . . . . . . . . . . . 92
K.4.1. Mapping to High-Order Points of Weierstrass Curve . . 90 K.4.1. Mapping to High-Order Points of Weierstrass Curve . . 92
K.4.2. Mapping to High-Order Points of Montgomery Curve . . 91 K.4.2. Mapping to High-Order Points of Montgomery Curve . . 93
K.4.3. Mapping to High-Order Points of Twisted Edwards Curve 93 K.4.3. Mapping to High-Order Points of Twisted Edwards Curve 94
K.5. Randomized Representation of Curve Points . . . . . . . . 94 K.5. Randomized Representation of Curve Points . . . . . . . . 95
K.6. Completing the Mappings to Curve Points . . . . . . . . . 95 K.6. Completing the Mappings to Curve Points . . . . . . . . . 96
Appendix L. Curve secp256k1 and Friend . . . . . . . . . . . . . 98 Appendix L. Curve secp256k1 and Friend . . . . . . . . . . . . . 99
L.1. Curve Definition and Alternative Representation . . . . . 99 L.1. Curve Definition and Alternative Representation . . . . . 100
L.2. Switching Between Representations . . . . . . . . . . . . 99 L.2. Switching Between Representations . . . . . . . . . . . . 100
L.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 99 L.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 100
L.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 101 L.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 102
L.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 101 L.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 102
L.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 102 L.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 103
Appendix M. Curve448 and Cousins . . . . . . . . . . . . . . . . 102 Appendix M. Curve448 and Cousins . . . . . . . . . . . . . . . . 103
M.1. Curve Definition and Alternative Representations . . . . 102 M.1. Curve Definition and Alternative Representations . . . . 103
M.2. Switching between Alternative Representations . . . . . . 103 M.2. Switching between Alternative Representations . . . . . . 104
M.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 104 M.3. Domain Parameters . . . . . . . . . . . . . . . . . . . . 105
Appendix N. Further Cousins of Curve448 . . . . . . . . . . . . 107 Appendix N. Further Cousins of Curve448 . . . . . . . . . . . . 108
N.1. Further Alternative Representations . . . . . . . . . . . 107 N.1. Further Alternative Representations . . . . . . . . . . . 108
N.2. Further Switching . . . . . . . . . . . . . . . . . . . . 107 N.2. Further Switching . . . . . . . . . . . . . . . . . . . . 108
N.3. Further Domain Parameters . . . . . . . . . . . . . . . . 110 N.3. Further Domain Parameters . . . . . . . . . . . . . . . . 111
N.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 112 N.4. Isogeny Details . . . . . . . . . . . . . . . . . . . . . 113
N.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 112 N.4.1. Isogeny Parameters . . . . . . . . . . . . . . . . . 113
N.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 113 N.4.2. Dual Isogeny Parameters . . . . . . . . . . . . . . . 114
Appendix O. Representation Examples Curve448 Family Members . . 113 Appendix O. Representation Examples Curve448 Family Members . . 114
O.1. Example with Curve448 . . . . . . . . . . . . . . . . . . 114 O.1. Example with Curve448 . . . . . . . . . . . . . . . . . . 115
O.2. Example with Ed448 . . . . . . . . . . . . . . . . . . . 117 O.2. Example with Ed448 . . . . . . . . . . . . . . . . . . . 118
O.3. Example with Wei448 . . . . . . . . . . . . . . . . . . . 120 O.3. Example with Wei448 . . . . . . . . . . . . . . . . . . . 121
O.4. Example with Wei448.1 . . . . . . . . . . . . . . . . . . 123 O.4. Example with Wei448.1 . . . . . . . . . . . . . . . . . . 124
O.5. Example with Wei448.-3 . . . . . . . . . . . . . . . . . 126 O.5. Example with Wei448.-3 . . . . . . . . . . . . . . . . . 127
O.6. Example with Edwards448 . . . . . . . . . . . . . . . . . 128 O.6. Example with Edwards448 . . . . . . . . . . . . . . . . . 129
Appendix P. Random Integers in Z_n . . . . . . . . . . . . . . . 131 Appendix P. Random Integers in Z_n . . . . . . . . . . . . . . . 132
P.1. Conversion to Integers in Z_n via Modular Reduction . . . 132 P.1. Conversion to Integers in Z_n via Modular Reduction . . . 133
P.2. Conversion to Integers in Z_n via Scaling . . . . . . . . 133 P.2. Conversion to Integers in Z_n via Scaling . . . . . . . . 134
P.3. Conversion to Integers in Z_n via the Discard Method . . 134 P.3. Conversion to Integers in Z_n via the Discard Method . . 135
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 134 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 135
1. Fostering Code Reuse with New Elliptic Curves 1. Fostering Code Reuse with New Elliptic Curves
Elliptic curves can be represented using different curve models. Elliptic curves can be represented using different curve models.
Recently, IETF standardized elliptic curves that are claimed to have Recently, IETF standardized elliptic curves that are claimed to have
better performance and improved robustness against "real world" better performance and improved robustness against "real world"
attacks than curves represented in the traditional short-Weierstrass attacks than curves represented in the traditional short-Weierstrass
curve model. These so-called CFRG curves [RFC7748] use the curve model. These so-called CFRG curves [RFC7748] use the
Montgomery curve model and the model of twisted Edwards curves. Montgomery curve model and the model of twisted Edwards curves.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
convert the results back to the original curve (where, in case this convert the results back to the original curve (where, in case this
involves an l-isogeny, one has to take into account the factor l). involves an l-isogeny, one has to take into account the factor l).
This includes use with elliptic-curve based signature schemes and key This includes use with elliptic-curve based signature schemes and key
agreement and key transport schemes. agreement and key transport schemes.
For some examples of curve computations on each of the curves For some examples of curve computations on each of the curves
specified in Appendix E.3 and Appendix G.3, see Appendix J. specified in Appendix E.3 and Appendix G.3, see Appendix J.
4. Examples 4. Examples
4.1. Implementation of X25519 4.1. Implementation of X25519, Specification of ECDH25519
RFC 7748 [RFC7748] specifies the use of X25519, a co-factor Diffie- RFC 7748 [RFC7748] specifies the use of X25519, a co-factor Diffie-
Hellman key agreement scheme, with instantiation by the Montgomery Hellman key agreement scheme, with instantiation by the Montgomery
curve Curve25519. This key agreement scheme was already specified in curve Curve25519. This key agreement scheme was already specified in
Section 6.1.2.2 of NIST SP 800-56a [SP-800-56a] for elliptic curves Section 6.1.2.2 of NIST SP 800-56a [SP-800-56a] for elliptic curves
in short-Weierstrass form. Hence, one can implement X25519 using in short-Weierstrass form. Hence, one can implement X25519 using
existing NIST routines by (1) representing a point of the Montgomery existing NIST routines by (1) representing a point of the Montgomery
curve Curve25519 as a point of the Weierstrass curve Wei25519; (2) curve Curve25519 as a point of the Weierstrass curve Wei25519; (2)
instantiating the co-factor Diffie-Hellman key agreement scheme of instantiating the co-factor Diffie-Hellman key agreement scheme of
the NIST specification with the resulting point and Wei25519 domain the NIST specification with the resulting point and Wei25519 domain
parameters; (3) representing the key resulting from this scheme parameters; (3) representing the key resulting from this scheme
(which is a point of the curve Wei25519 in Weierstrass form) as a (which is a point of the curve Wei25519 in Weierstrass form) as a
point of the Montgomery curve Curve25519. The representation change point of the Montgomery curve Curve25519. The representation change
can be implemented via a simple wrapper and involves a single modular can be implemented via a simple wrapper and involves a single modular
addition (see Appendix E.2). Using this method has the additional addition (see Appendix E.2). Using this method has the additional
advantage that one can reuse the public-private key pair routines, advantage that one can reuse the public-private key pair routines,
domain parameter validation, and other checks that are already part domain parameter validation, and other checks that are already part
of the NIST specifications. A NIST-compliant version of co-factor of the NIST specifications.
Diffie-Hellman key agreement (denoted by ECDH25519) results if one
keeps inputs (key contributions) and outputs (shared key) in the
short-Weierstrass format (and, hence, does not perform Steps (1) and
(3) above).
NOTE: At this point, it is unclear whether this implies that a FIPS- A NIST-compliant version of the co-factor Diffie-Hellman key
accredited module implementing co-factor Diffie-Hellman for, e.g., agreement scheme (denoted by ECDH25519) results if one keeps inputs
P-256 would also extend this accreditation to X25519. (key contributions) and pre-output (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 x-coordinate
of K (if this is an affine point of the curve), represented as a
fixed-size octet string in tight MSB/msb-order 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 co-factor Diffie-Hellman key
agreement scheme (denoted by X25519+) results by incorporating Step
(1), (2), and (3) above, i.e., where one keeps inputs (key
contributions) and pre-output (shared key K) in the Montgomery curve
format, as points of Curve25519, and where one represents all affine
points by their x-coordinate, represented as a fixed-size octet
string in tight LSB/msb-order 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 FIPS-accredited module
implementing the co-factor Diffie-Hellman scheme with, e.g., P-256
would also extend this accreditation to the Montgomery versions
X25519+ or X25519.
4.2. Implementation of Ed25519 4.2. Implementation of Ed25519
RFC 8032 [RFC8032] specifies Ed25519, a "full" Schnorr signature RFC 8032 [RFC8032] specifies Ed25519, a "full" Schnorr signature
scheme, with instantiation by the twisted Edwards curve Edwards25519. scheme, with instantiation by the twisted Edwards curve Edwards25519.
One can implement the computation of the ephemeral key pair for One can implement the computation of the ephemeral key pair for
Ed25519 using an existing Montgomery curve implementation by (1) Ed25519 using an existing Montgomery curve implementation by (1)
generating a public-private key pair (k, R':=k*G') for Curve25519; generating a public-private key pair (k, R':=k*G') for Curve25519;
(2) representing this public-private key as the pair (k, R:=k*G) for (2) representing this public-private key as the pair (k, R:=k*G) for
Ed25519. As before, the representation change can be implemented via Ed25519. As before, the representation change can be implemented via
skipping to change at page 9, line 15 skipping to change at page 9, line 46
can implement these schemes with the same representation conventions can implement these schemes with the same representation conventions
as used with existing NIST specifications, including bit/byte- as used with existing NIST specifications, including bit/byte-
ordering, compression functions, and the like. This allows generic ordering, compression functions, and the like. This allows generic
implementations of ECDSA with the hash function SHA-256 and with the implementations of ECDSA with the hash function SHA-256 and with the
NIST curve P-256 or with the curve Wei25519 specified in this NIST curve P-256 or with the curve Wei25519 specified in this
specification to reuse the same implementation (instantiated with, specification to reuse the same implementation (instantiated with,
respectively, the NIST P-256 elliptic curve domain parameters or with respectively, the NIST P-256 elliptic curve domain parameters or with
the domain parameters of curve Wei25519 specified in Appendix E). We the domain parameters of curve Wei25519 specified in Appendix E). We
denote by ECDSA25519 the instantiation of ECDSA with SHA-256 and with denote by ECDSA25519 the instantiation of ECDSA with SHA-256 and with
curve Wei25519, where the signature (r,s) is represented as the curve Wei25519, where the signature (r,s) is represented as the
right-concatenation of the integers r and s, each represented as right-concatenation of the integers r and s in the interval [1,n-1],
fixed-size strings with tight MSB/msb ordering (see Appendix I). where n is the order of the base point of the curve in question, each
represented as fixed-size octet strings in tight MSB/msb-order using
the Zn2OS mapping of Appendix I.6.
4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others) 4.4. Other Uses (Wei448, ECDH448, ECDSA448, and Others)
Any existing specification of cryptographic schemes using elliptic Any existing specification of cryptographic schemes using elliptic
curves in Weierstrass form and that allows introduction of a new curves in Weierstrass form and that allows introduction of a new
elliptic curve (here: Wei25519) is amenable to similar constructs, elliptic curve (here: Wei25519) is amenable to similar constructs,
thus spawning "offspring" protocols, simply by instantiating these thus spawning "offspring" protocols, simply by instantiating these
using the new curve in short-Weierstrass form, thereby allowing code using the new curve in short-Weierstrass form, thereby allowing code
and/or specifications reuse and, for implementations that so desire, and/or specifications reuse and, for implementations that so desire,
carrying out curve computations "under the hood" on Montgomery curve carrying out curve computations "under the hood" on Montgomery curve
skipping to change at page 9, line 44 skipping to change at page 10, line 31
We illustrate the construction of such offspring protocols for We illustrate the construction of such offspring protocols for
Curve448, another Montgomery curve recently standardized by IETF (see Curve448, another Montgomery curve recently standardized by IETF (see
[RFC7748]). Similar to the case with Curve25519, one can represent [RFC7748]). Similar to the case with Curve25519, one can represent
points of this curve via different curve models, viz. as points of an points of this curve via different curve models, viz. as points of an
Edwards curve (Ed448) or as points of a short-Weierstrass curve Edwards curve (Ed448) or as points of a short-Weierstrass curve
(Wei448). For the specification of Wei448 and its relationship to (Wei448). For the specification of Wei448 and its relationship to
Curve448 and Ed448, see Appendix M. As with ECDH25519, one can now Curve448 and Ed448, see Appendix M. As with ECDH25519, one can now
easily define a NIST-compliant version of co-factor Diffie-Hellman easily define a NIST-compliant version of co-factor Diffie-Hellman
key agreement (denoted by ECDH448), by simply reusing the example of key agreement (denoted by ECDH448), by simply reusing the example of
Section 4.1, but now using the short-Weierstrass curve Wei448, rather Section 4.1, but now using the short-Weierstrass curve Wei448, rather
than Wei25519. Similarly, one can easily specify ECDSA with Wei448 than Wei25519 (with the same representation and bit/byte-ordering
conventions). Similarly, one can easily specify ECDSA with Wei448
and a suitable hash function, by simply reusing the example of and a suitable hash function, by simply reusing the example of
Section 4.3, but now using the short-Weierstrass curve Wei448, rather Section 4.3, but now using the short-Weierstrass curve Wei448, rather
than Wei25519, and picking as hash function SHAKE256 [FIPS-202] with than Wei25519, and picking as hash function SHAKE256 [FIPS-202] with
output size of d=512 bits. We denote by ECDSA448 the resulting output size of d=512 bits. We denote by ECDSA448 the resulting
signature scheme (with the same bit/byte-ordering conventions). signature scheme (with the same representation and bit/byte-ordering
conventions).
NOTE: A Montgomery version of the co-factor Diffie-Hellman 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/byte-ordering 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 5. Caveats
The examples above illustrate how specifying the Weierstrass curve The examples above illustrate how specifying the Weierstrass curve
Wei25519 (or any curve in short-Weierstrass format, for that matter) Wei25519 (or any curve in short-Weierstrass format, for that matter)
may facilitate reuse of existing code and may simplify standards may facilitate reuse of existing code and may simplify standards
development. However, the following caveats apply: development. However, the following caveats apply:
5.1. Wire Format 5.1. Wire Format
skipping to change at page 13, line 26 skipping to change at page 14, line 26
implementation of Wei25519, see <https://github.com/ncme/c25519>. implementation of Wei25519, see <https://github.com/ncme/c25519>.
For support of this curve in tinydtls, see <https://github.com/ncme/ For support of this curve in tinydtls, see <https://github.com/ncme/
tinydtls>. tinydtls>.
According to <https://community.nxp.com/docs/DOC-330199>, an According to <https://community.nxp.com/docs/DOC-330199>, an
implementation of Wei25519 on the Kinets LTC ECC HW platform improves implementation of Wei25519 on the Kinets LTC ECC HW platform improves
the performance by over a factor ten compared to a stand-alone the performance by over a factor ten compared to a stand-alone
implementation of Curve25519 without hardware support. implementation of Curve25519 without hardware support.
The signature scheme ECDSA25519 (see Section 4.3) is supported in The signature scheme ECDSA25519 (see Section 4.3) is supported in
<https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/>. [RFC8928].
8. Security Considerations 8. Security Considerations
The different representations of elliptic curve points discussed in The different representations of elliptic curve points discussed in
this document are all obtained using a publicly known transformation, this document are all obtained using a publicly known transformation,
which is either an isomorphism or a low-degree isogeny. It is well- which is either an isomorphism or a low-degree isogeny. It is well-
known that an isomorphism maps elliptic curve points to equivalent known that an isomorphism maps elliptic curve points to equivalent
mathematical objects and that the complexity of cryptographic mathematical objects and that the complexity of cryptographic
problems (such as the discrete logarithm problem) of curves related problems (such as the discrete logarithm problem) of curves related
via a low-degree isogeny are tightly related. Thus, the use of these via a low-degree isogeny are tightly related. Thus, the use of these
skipping to change at page 14, line 50 skipping to change at page 15, line 50
see Appendix K.6. see Appendix K.6.
10. Using Wei25519 and Wei448 with COSE and JOSE 10. Using Wei25519 and Wei448 with COSE and JOSE
This section defines algorithm encodings and representations enabling This section defines algorithm encodings and representations enabling
the use of the curves Wei25519 and Wei448 and their use with ECDH and the use of the curves Wei25519 and Wei448 and their use with ECDH and
ECDSA with JOSE [RFC7518] and COSE [RFC8152] messages. ECDSA with JOSE [RFC7518] and COSE [RFC8152] messages.
All octet string encodings below use the MSB/msb-ordering conventions All octet string encodings below use the MSB/msb-ordering conventions
as defined in Appendix I.7. For CBOR representation details, we 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 10.1. Using Wei25519 and Wei448 Keys with COSE and JOSE
For Weierstrass curves, the representation of the point at infinity O For Weierstrass curves, the representation of the point at infinity O
is curve-specific (see Appendix H.1). For the short-Weierstrass is curve-specific (see Appendix H.1). For the short-Weierstrass
curve Wei25519, we define O:=(-1,0), whereas for Wei448, we define curve Wei25519, we define O:=(-1,0), whereas for Wei448, we define
O:=(1,0). O:=(1,0).
The encodings below specify the use of short-Weierstrass curves with The encodings below specify the use of short-Weierstrass curves with
COSE (see Section 10.1.1) and JOSE (see Section 10.1.2), where the 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 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). curve Wei25519 and "Wei448" for the curve Wei448).
10.1.1. Encoding of Short-Weierstrass Curves with COSE 10.1.1. Encoding of Short-Weierstrass Curves with COSE
With COSE, points of short-Weierstrass curves are encoded using the With COSE, points of short-Weierstrass curves are encoded using the
"EC2" key type (Section 13.1.1 of [RFC8152]) or the "OKP" key type "EC2" key type (Section 13.1.1 of [RFC8152]) or the "OKP" key type
(Section 7.2 of [I-D.ietf-cose-rfc8152bis-algs]), which are (Section 7.2 of [I-D.ietf-cose-rfc8152bis-algs]), which are
instantiated by setting the "crv" parameter to the (unique) name of instantiated by setting the "crv" parameter to the (unique) name of
the curve in question and the "kty" parameter to "EC2" or "OKP", the curve in question and the "kty" parameter to "EC2" or "OKP",
respectively, where key type-specific settings are as follows: respectively, where key type-specific settings are as follows:
a. With the "EC2" type, each affine point (X, Y) is encoded by a. With the "EC2" type, each affine point (X, Y) is encoded by
setting the parameters "x" and "y" to the octet string setting the parameters "x" and "y" to the octet string
representations of the elements X and Y, respectively, in tight representations of the elements X and Y, respectively, in tight
MSB/msb-order, and converting each to a CBOR byte string. Each MSB/msb-order, and converting each to a CBOR byte string. Each
compressed point (X, t) is encoded by setting the parameter "x" compressed point (X, t) is encoded by setting the parameter "x"
to the octet representation of the element X, in tight MSB/msb- to the octet representation of the element X, in tight MSB/msb-
order, converted to a CBOR byte string, and by setting the 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 whether, respectively, t=0 or t=1. For representation details
and for details on the reverse mappings, see Appendix I.8. (Note and for details on the reverse mappings, see Appendix I.8. (Note
that for affine points this representation is consistent with the that for affine points this representation is consistent with the
"EC2" representation in Section 13.1.1 of [RFC8152].) "EC2" representation in Section 13.1.1 of [RFC8152].)
b. With the "OKP" type, each point is encoded by setting the b. With the "OKP" type, each point is encoded by setting the
parameter "x" to the "squeezed" point representation of this parameter "x" to the "squeezed" point representation of this
point, in MSB/msb-order, and converting this to a CBOR byte point, in MSB/msb-order, and converting this to a CBOR byte
string. For representation details and for details on the string. For representation details and for details on the
reverse mappings, see Appendix I.8. (Note that for affine points reverse mappings, see Appendix I.8. (Note that for affine points
this representation is consistent with the "OKP" representation this representation is consistent with the "OKP" representation
in Section 7.2 of [I-D.ietf-cose-rfc8152bis-algs], which affords in Section 7.2 of [I-D.ietf-cose-rfc8152bis-algs], which affords
a curve-specific octet string encoding.) a curve-specific octet string encoding.)
In either case, if the point is a public key, the parameter "d" In either case, if the point is a public key (i.e., the private key
encodes the corresponding private key, using the octet string is well-defined), the parameter "d" encodes the corresponding private
representation, in tight MSB/msb-order, and converting this to a CBOR key, using the octet string representation, in tight MSB/msb-order,
byte string (see Appendix I.6). and converting this to a CBOR byte string (see Appendix I.6).
For curve points, the "crv" parameter and the parameters referenced For curve points, the "crv" parameter and the parameters referenced
with the applicable key type-specific settings above MUST be present with the applicable key type-specific settings above MUST be present
in the structure, whereas the parameter "d" MUST NOT 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 while for private keys, the parameters "crv" and "d" MUST be present
and the applicable key type-specific parameters of the corresponding and the applicable key type-specific parameters of the corresponding
public-key are RECOMMENDED to be present. public-key are RECOMMENDED to be present.
10.1.2. Encoding of Short-Weierstrass Curves with JOSE 10.1.2. Encoding of Short-Weierstrass Curves with JOSE
skipping to change at page 17, line 48 skipping to change at page 18, line 48
ECDSA scheme defined in Section 4.3 and "ECDSA448" for the scheme 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 defined in Section 4.4). Note that, in this case, the "alg" name
uniquely defines the curve (and, thereby, implicitly the underlying uniquely defines the curve (and, thereby, implicitly the underlying
"crv" parameter) and the underlying hash function. "crv" parameter) and the underlying hash function.
10.2.1. Encoding of ECDSA Instantiations with COSE 10.2.1. Encoding of ECDSA Instantiations with COSE
Instantiations of ECDSA used with COSE use the following encodings of Instantiations of ECDSA used with COSE use the following encodings of
inputs and outputs: inputs and outputs:
a. The message m is the COSE_Sign structure as specified in a. The message m is the COSE Sig_structure as specified in
Section 4.1 of [RFC8152], converted to a bit string, using the Section 4.4 of [RFC8152], converted to the CBOR byte string
OS2BS mapping of Appendix I.4; 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 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 in Section 10.1.1, where the "crv" parameter is set to the unique
name of the curve used with this particular instantiation of name of the curve used with this particular instantiation of
ECDSA; ECDSA;
c. The Cose signature is encoded as the right-concatenation of the c. The Cose signature is encoded as the right-concatenation of the
octet string representations of the coordinates of the signature octet string representations of the coordinates of the signature
pair (r, s), in left-to-right order, where r and s are each pair (r, s), in left-to-right order, where r and s are each
represented as octet strings in tight MSB/msb-order using the represented as octet strings in tight MSB/msb-order using the
skipping to change at page 18, line 32 skipping to change at page 19, line 32
string (each of length l) to, respectively, the integers r and s string (each of length l) to, respectively, the integers r and s
in Z_n, via the strict OS2ZnE mapping of Appendix I.6. 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 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 present, it MUST be set to the (unique) name of this particular
instantiation of ECDSA and the "crv" parameter MUST be set to the instantiation of ECDSA and the "crv" parameter MUST be set to the
(unique) name of the corresponding curve; if the "key_ops" field is (unique) name of the corresponding curve; if the "key_ops" field is
present, it MUST include "sign" when creating an ECDSA signature and present, it MUST include "sign" when creating an ECDSA signature and
it MUST include "verify" when verifying an ECDSA signature. 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 10.2.2. Encoding of ECDSA Instantiations with JOSE
Instantiations of ECDSA used with JOSE use the following encodings of Instantiations of ECDSA used with JOSE use the following encodings of
inputs and outputs: inputs and outputs:
a. The message m is the JWS Signing Input as specified in [RFC7515], a. The message m is the JWS Signing Input as specified in [RFC7515],
converted to a bit string, using the OS2BS mapping of converted to a bit string, using the OS2BS mapping of
Appendix I.4; Appendix I.4;
b. The public key and the private key are encoded as specified in 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 Section 10.1.2, where the "crv" parameter is set to the unique
name of the curve used with this particular instantiation of name of the curve used with this particular instantiation of
ECDSA; ECDSA;
c. The JWS signature is encoded as the right-concatenation of the c. The JWS signature is encoded as the right-concatenation of the
octet string representations of the coordinates of the signature octet string representations of the coordinates of the signature
pair (r, s), in left-to-right order, where r and s are each pair (r, s), in left-to-right order, where r and s are each
represented in tight MSB/msb-order (see Appendix I.7), converted represented as octet strings in tight MSB/msb-order using the
using the base64url encoding. Note that, since we use a tight ZnE2OS mapping of Appendix I.6, converted using the base64url
representation, this right-concatenated octet string has fixed encoding. Note that, since we use a tight representation, this
size 2*l, where the parameter l is uniquely defined by the set right-concatenated octet string has fixed size 2*l, where the
Z_n in question (where n is the (prime) order of the base point parameter l is uniquely defined by the set Z_n in question (where
of the curve in question). The inverse mapping results by n is the (prime) order of the base point of the curve in
checking that the purported encoded signature (after base64url question). The inverse mapping results by checking that the
decoding) has indeed size 2*l, and by converting the left-side purported encoded signature (after base64url decoding) has indeed
and right-side halves of this octet string (each of length l) to, size 2*l, and by converting the left-side and right-side halves
respectively, the integers r and s in Z_n, via the strict OS2ZnE of this octet string (each of length l) to, respectively, the
mapping of Appendix I.6. 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 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 present, it MUST be set to the (unique) name of this particular
instantiation of ECDSA and the "crv" parameter MUST be set to the instantiation of ECDSA and the "crv" parameter MUST be set to the
(unique) name of the corresponding curve; if the "key_ops" field is (unique) name of the corresponding curve; if the "key_ops" field is
present, it MUST include "sign" when creating an ECDSA signature and present, it MUST include "sign" when creating an ECDSA signature and
it MUST include "verify" when verifying an ECDSA signature; if the it MUST include "verify" when verifying an ECDSA signature; if the
JWK _use_ field is present, its value MUST be "sig". JWK _use_ field is present, its value MUST be "sig".
10.3. Using ECDH25519 and ECDH448 with COSE and JOSE 10.3. Using ECDH25519 and ECDH448 with COSE and JOSE
NIST SP 800-56a [SP-800-56a] specifies the co-factor elliptic-curve NIST SP 800-56a [SP-800-56a] specifies the co-factor elliptic-curve
Diffie-Hellman key agreement scheme (co-factor ECDH) and can be Diffie-Hellman key agreement scheme (co-factor ECDH) and can be
instantiated with a suitable elliptic curve in short-Weierstrass form instantiated with a suitable elliptic curve in short-Weierstrass form
(that satisfies particular cryptographic criteria). While this (that satisfies particular cryptographic criteria). While this
completely specifies the internal workings of the key agreement completely specifies the internal workings of the key agreement
scheme in question, this does not uniquely specify the input/output scheme in question, this does not uniquely specify the input/output
formats: formats:
a. The co-factor ECDH scheme is a two-party key agreement scheme a. The co-factor ECDH scheme is a two-party key agreement scheme
that takes as inputs a private key d from one of the parties and that takes as inputs a private key d in the interval [1,n-1] from
a point Q' obtained from the other party and produces a shared one of the parties and a point Q' obtained from the other party
key K:=h*(d*Q'), where h and n are, respectively, the co-factor and produces a shared key K:=h*(d*Q'), where h and n are,
and the order of the base point of the curve in question and respectively, the co-factor and the order of the base point of
where Q' is a point of this curve. If this shared key K is the the curve in question and where Q' is a point of this curve. If
point at infinity O of the curve, the output is an error message; 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 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 is the (raw) shared secret Z, which is the fixed-size octet
of the x-coordinate of K, using the FE2OS mapping of representation of the x-coordinate of K, using the FE2OS mapping
Appendix I.5, represented in tight-MSB/msb-order (see of Appendix I.5, represented in tight-MSB/msb-order (see
Appendix I.7). Appendix I.7).
(NOTE: A subsequent key derivation function (kdf) takes as inputs (NOTE: A subsequent key derivation function (kdf) takes as inputs
the shared secret Z and side information OtherInfo and produces the shared secret Z and side information OtherInfo and produces
as output an octet string of DerivedKeyingMaterial, where details as output an octet string of DerivedKeyingMaterial, where details
depend on the used kdf in question. This step is out of scope.) depend on the used kdf in question. This step is out of scope.)
The inputs and outputs are uniquely determined by specifying the 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. this key agreement scheme.
The encodings below specify the use of instantiations of ECDH with 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 COSE (see Section 10.3.1) and JOSE (see Section 10.3.2), where the
encoding for a specific co-factor ECDH instantiation (i.e., with a encoding for a specific co-factor ECDH instantiation (i.e., with a
specific short-Weierstrass curve) results by setting the "crv" specific short-Weierstrass curve) results by setting the "crv"
parameter to the unique name of the underlying curve in question and parameter to the unique name of the underlying curve in question and
the "alg" parameter to the unique name of the specific key agreement the "alg" parameter to the unique name of the specific key agreement
scheme instantiation (e.g., "ECDH25519" for the co-factor ECDH scheme scheme instantiation (i.e., "ECDH25519" for the co-factor ECDH scheme
defined in Section 4.1 and "ECDH448" for the scheme defined in defined in Section 4.1 and "ECDH448" for the scheme defined in
Section 4.4). Note that, in this case, the "alg" name uniquely Section 4.4). Note that, in this case, the "alg" name uniquely
defines the curve (and, thereby, implicitly the underlying "crv" defines the curve (and, thereby, implicitly the underlying "crv"
parameter). parameter).
10.3.1. Encoding of co-factor ECDH with COSE 10.3.1. Encoding of co-factor ECDH with COSE
Instantiations of co-factor ECDH used with COSE use the following Instantiations of co-factor ECDH used with COSE use the following
encodings of inputs and outputs: encodings of inputs and outputs:
skipping to change at page 22, line 8 skipping to change at page 23, line 25
11.3. Encoding of co-factor ECDH and Other Algorithms with PKIX 11.3. Encoding of co-factor ECDH and Other Algorithms with PKIX
With [RFC5480], the algorithm field in the SubjectPublicKeyInfo With [RFC5480], the algorithm field in the SubjectPublicKeyInfo
structure indicates the algorithm and the elliptic curve domain structure indicates the algorithm and the elliptic curve domain
parameters for a specific curve, where that specification defines parameters for a specific curve, where that specification defines
three algorithm identifiers (viz. id-ecPublicKey, id-ecDH, and id- three algorithm identifiers (viz. id-ecPublicKey, id-ecDH, and id-
ecMQV). Each of these algorithms can be instantiated with suitable ecMQV). Each of these algorithms can be instantiated with suitable
alliptic curves, thereby allowing support for their use with the alliptic curves, thereby allowing support for their use with the
curves Wei25519 and Wei448, where these curves are identified by curves Wei25519 and Wei448, where these curves are identified by
their unique object identifiers id-wei25519 and id-wei448, their unique object identifiers id-Wei25519 and id-Wei448,
respectively, (see Section 11.1) and where all other aspects are respectively, (see Section 11.1) and where all other aspects are
specified in [RFC5480]. specified in [RFC5480].
11.4. Encoding of Elliptic-Curve-Based Algorithms with CMS 11.4. Encoding of Elliptic-Curve-Based Algorithms with CMS
With [RFC5753], elliptic-curve based algorithms should use one of the With [RFC5753], elliptic-curve based algorithms should use one of the
elliptic curve domain parameters specified in [RFC5480], where the elliptic curve domain parameters specified in [RFC5480], where the
unique name of each such curve is identified by the object identifier unique name of each such curve is identified by the object identifier
of this curve defined in that document. Each of these algorithms can of this curve defined in that document. Each of these algorithms can
be instantiated with suitable elliptic curves, thereby allowing be instantiated with suitable elliptic curves, thereby allowing
support for their use with the curves Wei25519 and Wei448, where support for their use with the curves Wei25519 and Wei448, where
these curves are identified by their unique object identifiers id- these curves are identified by their unique object identifiers id-
wei25519 and id-wei448, respectively, (see Section 11.1) and where Wei25519 and id-Wei448, respectively, (see Section 11.1) and where
all other aspects are specified in [RFC5753]. all other aspects are specified in [RFC5753].
12. IANA Considerations 12. IANA Considerations
Code points are requested for curves Wei25519 and Wei448 and their Code points are requested for curves Wei25519 and Wei448 and their
use with ECDSA and co-factor ECDH, using the representation use with ECDSA and co-factor ECDH, using the representation
conventions of this document. conventions of this document.
New code points would be required in case one wishes to specify one New code points would be required in case one wishes to specify one
or more other "offspring" protocols beyond those exemplified in or more other "offspring" protocols beyond those exemplified in
skipping to change at page 26, line 19 skipping to change at page 27, line 36
Name: ECDSA448; Name: ECDSA448;
Value: TBD (Requested value: -48); Value: TBD (Requested value: -48);
Description: ECDSA with SHAKE256 and curve Wei448; Description: ECDSA with SHAKE256 and curve Wei448;
Change Controller: IESG; Change Controller: IESG;
Reference: specified in Section 4.4 of this specification; for Reference: specified in Section 4.4 of this specification; for
encodings, see Section 10.1; encodings, see Section 10.2;
Recommended: Yes. Recommended: Yes.
12.3.3. COSE Algorithms Registration (2/2) 12.3.3. COSE Algorithms Registration (2/2)
This section registers the following value in the IANA "COSE This section registers the following value in the IANA "COSE
Algorithms" registry [IANA.COSE.Algorithms]. Algorithms" registry [IANA.COSE.Algorithms].
Name: ECDH448; Name: ECDH448;
skipping to change at page 29, line 34 skipping to change at page 31, line 10
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <https://www.rfc-editor.org/info/rfc5753>. 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
skipping to change at page 30, line 38 skipping to change at page 32, line 11
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key
Infrastructure: Additional Algorithm Identifiers for Infrastructure: Additional Algorithm Identifiers for
RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019, DOI 10.17487/RFC8692, December 2019,
<https://www.rfc-editor.org/info/rfc8692>. <https://www.rfc-editor.org/info/rfc8692>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography, , June 2009. Standards for Efficient Cryptography, , June 2009.
[SEC2] SEC2, "SEC 2: Elliptic Curve Cryptography, Version 2.0", [SEC2] SEC2, "SEC 2: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography, , January 2010. Standards for Efficient Cryptography, , January 2010.
[SP-800-56a] [SP-800-56a]
NIST SP 800-56a, "Recommendation for Pair-Wise Key NIST SP 800-56a, "Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Log Cryptography, Establishment Schemes Using Discrete Log Cryptography,
Revision 3", US Department of Commerce/National Institute Revision 3", US Department of Commerce/National Institute
skipping to change at page 32, line 10 skipping to change at page 33, line 35
[IANA.JOSE.Curves] [IANA.JOSE.Curves]
IANA, "JSON Web Key Elliptic Curve", IANA, IANA, "JSON Web Key Elliptic Curve", IANA,
https://www.iana.org/assignments/jose/jose.xhtml#web-key- https://www.iana.org/assignments/jose/jose.xhtml#web-key-
elliptic-curve. elliptic-curve.
[Mont-Ladder] [Mont-Ladder]
P.L. Montgomery, "Speeding the Pollard and Elliptic Curve P.L. Montgomery, "Speeding the Pollard and Elliptic Curve
Methods of Factorization", Mathematics of Methods of Factorization", Mathematics of
Computation, Vol. 48, 1987. Computation, Vol. 48, 1987.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[Rosener] N. Rosener, "Evaluating the Performance of Transformations [Rosener] N. Rosener, "Evaluating the Performance of Transformations
Between Curve Representations in Elliptic Curve Between Curve Representations in Elliptic Curve
Cryptography for Constrained Device Security", Cryptography for Constrained Device Security",
M.Sc. Universitat Bremen, August 2018. M.Sc. Universitat Bremen, August 2018.
[SWUmap] E. Brier, J-S. Coron, Th. Icart, D. Madore, H. Randriam, [SWUmap] E. Brier, J-S. Coron, Th. Icart, D. Madore, H. Randriam,
M. Tibouchi, "Efficient Indifferentiable Hashing into M. Tibouchi, "Efficient Indifferentiable Hashing into
Ordinary Elliptic Curves", CRYPTO 2010, Lecture Notes in Ordinary Elliptic Curves", CRYPTO 2010, Lecture Notes in
Computer Science, Vol. 6223, New York: Springer-Verlag, Computer Science, Vol. 6223, New York: Springer-Verlag,
2010. 2010.
skipping to change at page 96, line 37 skipping to change at page 97, line 37
if u2 is a random element of a sufficiently large subset of GF(p) if u2 is a random element of a sufficiently large subset of GF(p)
(see, e.g., [Tibouchi-cleancut]). This allows generating u1 and u2, (see, e.g., [Tibouchi-cleancut]). This allows generating u1 and u2,
e.g., each as random bit strings of length m-1, where m is the bit- e.g., each as random bit strings of length m-1, where m is the bit-
length of p, thereby allowing the pair (u1, u2) -- a random (2*m-2)- length of p, thereby allowing the pair (u1, u2) -- a random (2*m-2)-
bit string -- to be used unaltered in this construction, without the bit string -- to be used unaltered in this construction, without the
need to carry out a reduction modulo p first. Table 2 illustrates need to carry out a reduction modulo p first. Table 2 illustrates
how this can be used to realize randomized representations and how this can be used to realize randomized representations and
completed mappings for each curve in Table 1, where these randomized completed mappings for each curve in Table 1, where these randomized
bit strings have the same byte-length as the (tight) representation bit strings have the same byte-length as the (tight) representation
of affine curve points. (Here, the field elements u1 and u2 are of affine curve points. (Here, the field elements u1 and u2 are
obtained from their bit string representations using the b2O mapping obtained from their bit string representations using the BS2OS
of Appendix I.2 and the (non-strict) OS2FE mapping of Appendix I.5.) mapping of Appendix I.4 and the (non-strict) OS2FE mapping of
For each curve in Table 2, we refer to this version of the default Appendix I.5.) For each curve in Table 2, we refer to this version
completed mapping as being the "clean-cut" default completed mapping. of the default completed mapping as being the "clean-cut" default
completed mapping.
+--------------------------+-----------------+----------------------+ +--------------------------+-----------------+----------------------+
| Curve | left-side | right-side | | Curve | left-side | right-side |
+--------------------------+-----------------+----------------------+ +--------------------------+-----------------+----------------------+
| NIST P-224 [FIPS-186-4] | {u1:224} | {s1:1, s2:1, u2:222} | | NIST P-224 [FIPS-186-4] | {u1:224} | {s1:1, s2:1, u2:222} |
| NIST P-256 [FIPS-186-4] | {s1:1, u1:255} | {s2:1, u2:255} | | NIST P-256 [FIPS-186-4] | {s1:1, u1:255} | {s2:1, u2:255} |
| NIST P-384 [FIPS-186-4] | {u1:384} | {s1:1, s2:1, u2:382} | | NIST P-384 [FIPS-186-4] | {u1:384} | {s1:1, s2:1, u2:382} |
| NIST P-521 [FIPS-186-4] | {s1:1, u1:527} | {s2:1, u2:527} | | NIST P-521 [FIPS-186-4] | {s1:1, u1:527} | {s2:1, u2:527} |
| brainpoolP224r1 | {s1:1, u1:223} | {s2:1, u2:223} | | brainpoolP224r1 | {s1:1, u1:223} | {s2:1, u2:223} |
| [RFC5639] | | | | [RFC5639] | | |
skipping to change at page 97, line 52 skipping to change at page 98, line 52
Table 3 shows an alternative arrangement, tailored towards optimizing Table 3 shows an alternative arrangement, tailored towards optimizing
the efficiency of computing randomized representations of curve the efficiency of computing randomized representations of curve
points (see Appendix K.5), rather than towards avoiding modular points (see Appendix K.5), rather than towards avoiding modular
reductions in the mappings to curve points. (Here, we used reductions in the mappings to curve points. (Here, we used
randomized representations of elements of GF(p), when appropriate, randomized representations of elements of GF(p), when appropriate,
and the bias upper bound 2^{-64} from Table 4.) For each curve in 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 Table 3, we refer to this version of the default completed mapping as
being the "point-randomization-optimized" default completed mapping being the "point-randomization-optimized" default completed mapping
(where both versions coincide if the prime number p is relatively (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 close to a power of two). (Here, the field elements u1 and u2 are
obtained from their bit string representations using the b2O mapping obtained from their bit string representations using the BS2OS
of Appendix I.2 and the (non-strict) OS2FE mapping of Appendix I.5.) mapping of Appendix I.4 and the (non-strict) OS2FE mapping of
Suitability of each of these completed mappings is application- Appendix I.5.) Suitability of each of these completed mappings is
specific (and also depends on the maximum bias one can tolerate). application-specific (and also depends on the maximum bias one can
Further details are out of scope of this document. tolerate). Further details are out of scope of this document.
+--------------------------+-----------------+----------------------+ +--------------------------+-----------------+----------------------+
| Curve | left-side | right-side | | Curve | left-side | right-side |
+--------------------------+-----------------+----------------------+ +--------------------------+-----------------+----------------------+
| NIST P-224 [FIPS-186-4] | {u1:224} | {s1:1, s2:1, u2:222} | | NIST P-224 [FIPS-186-4] | {u1:224} | {s1:1, s2:1, u2:222} |
| NIST P-256 [FIPS-186-4] | {u1:288} | {s1:1, s2:1, u2:222} | | NIST P-256 [FIPS-186-4] | {u1:288} | {s1:1, s2:1, u2:222} |
| NIST P-384 [FIPS-186-4] | {u1:384} | {s1:1, s2:1, u2:382} | | NIST P-384 [FIPS-186-4] | {u1:384} | {s1:1, s2:1, u2:382} |
| NIST P-521 [FIPS-186-4] | {s1:1, u1:527} | {s2:1, u2:527} | | NIST P-521 [FIPS-186-4] | {s1:1, u1:527} | {s2:1, u2:527} |
| brainpoolP224r1 | {s1:1, u1:287} | {s2:1, u2:159} | | brainpoolP224r1 | {s1:1, u1:287} | {s2:1, u2:159} |
| [RFC5639] | | | | [RFC5639] | | |
 End of changes. 38 change blocks. 
208 lines changed or deleted 276 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/