The Messaging Layer Security (MLS) Protocol
draft-ietf-mls-protocol-12
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9420.
|
|
|---|---|---|---|
| Authors | Richard Barnes , Benjamin Beurdouche , Raphael Robert , Jon Millican , Emad Omara , Katriel Cohn-Gordon | ||
| Last updated | 2021-10-11 | ||
| Replaces | draft-barnes-mls-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
TSVART Early review
(of
-16)
by Gorry Fairhurst
On the Right Track
ARTART Early review
(of
-16)
by Rich Salz
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9420 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | benjamin.beurdouche@ens.fr, karthikeyan.bhargavan@inria.fr, cas.cremers@cs.ox.ac.uk, alan@wire.com, singuva@twitter.com, kwonal@mit.edu, ekr@rtfm.com, thyla.van.der@merwe.tech |
draft-ietf-mls-protocol-12
Network Working Group R. Barnes
Internet-Draft Cisco
Intended status: Informational B. Beurdouche
Expires: 14 April 2022 Inria & Mozilla
R. Robert
J. Millican
Facebook
E. Omara
Google
K. Cohn-Gordon
University of Oxford
11 October 2021
The Messaging Layer Security (MLS) Protocol
draft-ietf-mls-protocol-12
Abstract
Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in
delivering messages. Establishing keys to provide such protections
is challenging for group chat settings, in which more than two
clients need to agree on a key but may not be online at the same
time. In this document, we specify a key establishment protocol that
provides efficient asynchronous group key establishment with forward
secrecy and post-compromise security for groups in size ranging from
two to thousands.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/mlswg/mls-protocol (https://github.com/mlswg/mls-
protocol).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Barnes, et al. Expires 14 April 2022 [Page 1]
Internet-Draft MLS October 2021
Internet-Drafts 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 Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 April 2022.
Copyright Notice
Copyright (c) 2021 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/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
5. Ratchet Trees . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Tree Computation Terminology . . . . . . . . . . . . . . 15
5.2. Ratchet Tree Nodes . . . . . . . . . . . . . . . . . . . 17
5.3. Views of a Ratchet Tree . . . . . . . . . . . . . . . . . 18
5.4. Ratchet Tree Evolution . . . . . . . . . . . . . . . . . 19
5.5. Synchronizing Views of the Tree . . . . . . . . . . . . . 21
6. Cryptographic Objects . . . . . . . . . . . . . . . . . . . . 22
6.1. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 23
7. Key Packages . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Key Package IDs . . . . . . . . . . . . . . . . . . . . . 26
7.2. Client Capabilities . . . . . . . . . . . . . . . . . . . 27
7.3. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4. KeyPackage Identifiers . . . . . . . . . . . . . . . . . 27
7.5. Parent Hash . . . . . . . . . . . . . . . . . . . . . . . 28
7.5.1. Using Parent Hashes . . . . . . . . . . . . . . . . . 28
7.5.2. Verifying Parent Hashes . . . . . . . . . . . . . . . 29
7.6. Tree Hashes . . . . . . . . . . . . . . . . . . . . . . . 30
7.7. Group State . . . . . . . . . . . . . . . . . . . . . . . 31
7.8. Update Paths . . . . . . . . . . . . . . . . . . . . . . 32
Barnes, et al. Expires 14 April 2022 [Page 2]
Internet-Draft MLS October 2021
8. Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. External Initialization . . . . . . . . . . . . . . . . . 36
8.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 37
8.3. Secret Tree . . . . . . . . . . . . . . . . . . . . . . . 40
8.4. Encryption Keys . . . . . . . . . . . . . . . . . . . . . 41
8.5. Deletion Schedule . . . . . . . . . . . . . . . . . . . . 42
8.6. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 43
8.7. Resumption Secret . . . . . . . . . . . . . . . . . . . . 44
8.8. State Authentication Keys . . . . . . . . . . . . . . . . 44
9. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Content Authentication . . . . . . . . . . . . . . . . . 47
9.2. Content Encryption . . . . . . . . . . . . . . . . . . . 49
9.3. Sender Data Encryption . . . . . . . . . . . . . . . . . 50
10. Group Creation . . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Required Capabilities . . . . . . . . . . . . . . . . . 52
10.2. Linking a New Group to an Existing Group . . . . . . . . 53
10.2.1. Sub-group Branching . . . . . . . . . . . . . . . . 53
11. Group Evolution . . . . . . . . . . . . . . . . . . . . . . . 53
11.1. Proposals . . . . . . . . . . . . . . . . . . . . . . . 54
11.1.1. Add . . . . . . . . . . . . . . . . . . . . . . . . 54
11.1.2. Update . . . . . . . . . . . . . . . . . . . . . . . 56
11.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . . 56
11.1.4. PreSharedKey . . . . . . . . . . . . . . . . . . . . 57
11.1.5. ReInit . . . . . . . . . . . . . . . . . . . . . . . 57
11.1.6. ExternalInit . . . . . . . . . . . . . . . . . . . . 58
11.1.7. AppAck . . . . . . . . . . . . . . . . . . . . . . . 58
11.1.8. GroupContextExtensions . . . . . . . . . . . . . . . 59
11.1.9. External Proposals . . . . . . . . . . . . . . . . . 60
11.2. Commit . . . . . . . . . . . . . . . . . . . . . . . . . 61
11.2.1. External Commits . . . . . . . . . . . . . . . . . . 68
11.2.2. Welcoming New Members . . . . . . . . . . . . . . . 71
11.3. Ratchet Tree Extension . . . . . . . . . . . . . . . . . 74
12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 75
13. Sequencing of State Changes . . . . . . . . . . . . . . . . . 77
13.1. Server-Enforced Ordering . . . . . . . . . . . . . . . . 78
13.2. Client-Enforced Ordering . . . . . . . . . . . . . . . . 78
14. Application Messages . . . . . . . . . . . . . . . . . . . . 78
14.1. Message Encryption and Decryption . . . . . . . . . . . 79
14.2. Restrictions . . . . . . . . . . . . . . . . . . . . . . 80
14.3. Delayed and Reordered Application messages . . . . . . . 80
15. Security Considerations . . . . . . . . . . . . . . . . . . . 80
15.1. Confidentiality of the Group Secrets . . . . . . . . . . 80
15.2. Authentication . . . . . . . . . . . . . . . . . . . . . 81
15.3. Forward Secrecy and Post-Compromise Security . . . . . . 81
15.4. InitKey Reuse . . . . . . . . . . . . . . . . . . . . . 82
15.5. Group Fragmentation by Malicious Insiders . . . . . . . 82
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
16.1. MLS Ciphersuites . . . . . . . . . . . . . . . . . . . . 83
Barnes, et al. Expires 14 April 2022 [Page 3]
Internet-Draft MLS October 2021
16.2. MLS Extension Types . . . . . . . . . . . . . . . . . . 86
16.3. MLS Proposal Types . . . . . . . . . . . . . . . . . . . 87
16.4. MLS Credential Types . . . . . . . . . . . . . . . . . . 88
16.5. MLS Designated Expert Pool . . . . . . . . . . . . . . . 89
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 90
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
18.1. Normative References . . . . . . . . . . . . . . . . . . 91
18.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. Tree Math . . . . . . . . . . . . . . . . . . . . . 93
Authors&* k_(1,1) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c
6b4f20a4181472aaa9cb8d555526a9ffffffffc71a * I
* k_(1,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c
6b4f20a4181472aaa9cb8d555526a9ffffffffc71e + 0x8ab05f8bdd54cde1909
37e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ff
ffffffe38d * I
* k_(1,3) = 0x171d6541fa38ccfaed6dea691f5fb614cb14b4e7f4e810aa22d610
8f142b85757098e38d0f671c7188e2aaaaaaaa5ed1
The constants used to compute x_den are as follows:
* k_(2,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2
a0f6b0f6241eabfffeb153ffffb9feffffffffaa63 * I
* k_(2,1) = 0xc + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf
6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa9f * I
The constants used to compute y_num are as follows:
* k_(3,0) = 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439
d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 + 0x1530477c7ab4113b59a
4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc
71c71c6d706 * I
* k_(3,1) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b5842
3c50ae15d5c2638e343d9c71c6238aaaaaaaa97be * I
* k_(3,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c
6b4f20a4181472aaa9cb8d555526a9ffffffffc71c + 0x8ab05f8bdd54cde1909
37e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ff
ffffffe38f * I
* k_(3,3) = 0x124c9ad43b6cf79bfbf7043de3811ad0761b0f37a1e26286b0e977
c69aa274524e79097a56dc4bd9e1b371c71c718b10
The constants used to compute y_den are as follows:
* k_(4,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2
a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb + 0x1a0111ea397fe69a4b1
ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9fef
fffffffa8fb * I
* k_(4,1) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2
a0f6b0f6241eabfffeb153ffffb9feffffffffa9d3 * I
Faz-Hernandez, et al. Expires 17 December 2022 [Page 78]
Internet-Draft hash-to-curve June 2022
* k_(4,2) = 0x12 + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512b
f6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa99 * I
Appendix F. Straight-line implementations of deterministic mappings
This section gives straight-line implementations of the mappings of
Section 6. These implementations are generic, i.e., they are defined
for any curve and field. Appendix G gives further implementations
that are optimized for specific classes of curves and fields.
F.1. Shallue-van de Woestijne method
This section gives a straight-line implementation of the Shallue and
van de Woestijne method for any Weierstrass curve of the form given
in Section 6.6. See Section 6.6.1 for information on the constants
used in this mapping.
Note that the constant c3 below MUST be chosen such that sgn0(c3) =
0. In other words, if the square-root computation returns a value cx
such that sgn0(cx) = 1, set c3 = -cx; otherwise, set c3 = cx.
map_to_curve_svdw(u)
Input: u, an element of F.
Output: (x, y), a point on E.
Constants:
1. c1 = g(Z)
2. c2 = -Z / 2
3. c3 = sqrt(-g(Z) * (3 * Z^2 + 4 * A)) # sgn0(c3) MUST equal 0
4. c4 = -4 * g(Z) / (3 * Z^2 + 4 * A)
Steps:
1. tv1 = u^2
2. tv1 = tv1 * c1
3. tv2 = 1 + tv1
4. tv1 = 1 - tv1
5. tv3 = tv1 * tv2
6. tv3 = inv0(tv3)
7. tv4 = u * tv1
8. tv4 = tv4 * tv3
9. tv4 = tv4 * c3
10. x1 = c2 - tv4
11. gx1 = x1^2
12. gx1 = gx1 + A
13. gx1 = gx1 * x1
14. gx1 = gx1 + B
15. e1 = is_square(gx1)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 79]
Internet-Draft hash-to-curve June 2022
16. x2 = c2 + tv4
17. gx2 = x2^2
18. gx2 = gx2 + A
19. gx2 = gx2 * x2
20. gx2 = gx2 + B
21. e2 = is_square(gx2) AND NOT e1 # Avoid short-circuit logic ops
22. x3 = tv2^2
23. x3 = x3 * tv3
24. x3 = x3^2
25. x3 = x3 * c4
26. x3 = x3 + Z
27. x = CMOV(x3, x1, e1) # x = x1 if gx1 is square, else x = x3
28. x = CMOV(x, x2, e2) # x = x2 if gx2 is square and gx1 is not
29. gx = x^2
30. gx = gx + A
31. gx = gx * x
32. gx = gx + B
33. y = sqrt(gx)
34. e3 = sgn0(u) == sgn0(y)
35. y = CMOV(-y, y, e3) # Select correct sign of y
36. return (x, y)
F.2. Simplified SWU method
This section gives a straight-line implementation of the simplified
SWU method for any Weierstrass curve of the form given in
Section 6.6. See Section 6.6.2 for information on the constants used
in this mapping.
This optimized, straight-line procedure applies to any base field.
The sqrt_ratio subroutine is defined in Appendix F.2.1.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 80]
Internet-Draft hash-to-curve June 2022
map_to_curve_simple_swu(u)
Input: u, an element of F.
Output: (x, y), a point on E.
Steps:
1. tv1 = u^2
2. tv1 = Z * tv1
3. tv2 = tv1^2
4. tv2 = tv2 + tv1
5. tv3 = tv2 + 1
6. tv3 = B * tv3
7. tv4 = CMOV(Z, -tv2, tv2 != 0)
8. tv4 = A * tv4
9. tv2 = tv3^2
10. tv6 = tv4^2
11. tv5 = A * tv6
12. tv2 = tv2 + tv5
13. tv2 = tv2 * tv3
14. tv6 = tv6 * tv4
15. tv5 = B * tv6
16. tv2 = tv2 + tv5
17. x = tv1 * tv3
18. (is_gx1_square, y1) = sqrt_ratio(tv2, tv6)
19. y = tv1 * u
20. y = y * y1
21. x = CMOV(x, tv3, is_gx1_square)
22. y = CMOV(y, y1, is_gx1_square)
23. e1 = sgn0(u) == sgn0(y)
24. y = CMOV(-y, y, e1)
25. x = x / tv4
26. return (x, y)
F.2.1. sqrt_ratio subroutines
This section defines three variants of the sqrt_ratio subroutine used
by the above procedure. The first variant can be used with any
field; the others are optimized versions for specific fields.
The routines given in this section depend on the constant Z from the
simplified SWU map. For correctness, sqrt_ratio and
map_to_curve_simple_swu MUST use the same value for Z.
F.2.1.1. sqrt_ratio for any field
Faz-Hernandez, et al. Expires 17 December 2022 [Page 81]
Internet-Draft hash-to-curve June 2022
sqrt_ratio(u, v)
Parameters:
- F, a finite field of characteristic p and order q = p^m.
- Z, the constant from the simplified SWU map.
Input: u and v, elements of F, where v != 0.
Output: (b, y), where
b = True and y = sqrt(u / v) if (u / v) is square in F, and
b = False and y = sqrt(Z * (u / v)) otherwise.
Constants:
1. c1, the largest integer such that 2^c1 divides q - 1.
2. c2 = (q - 1) / (2^c1) # Integer arithmetic
3. c3 = (c2 - 1) / 2 # Integer arithmetic
4. c4 = 2^c1 - 1 # Integer arithmetic
5. c5 = 2^(c1 - 1) # Integer arithmetic
6. c6 = Z^c2
7. c7 = Z^((c2 + 1) / 2)
Procedure:
1. tv1 = c6
2. tv2 = v^c4
3. tv3 = tv2^2
4. tv3 = tv3 * v
5. tv5 = u * tv3
6. tv5 = tv5^c3
7. tv5 = tv5 * tv2
8. tv2 = tv5 * v
9. tv3 = tv5 * u
10. tv4 = tv3 * tv2
11. tv5 = tv4^c5
12. isQR = tv5 == 1
13. tv2 = tv3 * c7
14. tv5 = tv4 * tv1
15. tv3 = CMOV(tv2, tv3, isQR)
16. tv4 = CMOV(tv5, tv4, isQR)
17. for i in (c1, c1 - 1, ..., 2):
18. tv5 = i - 2
19. tv5 = 2^tv5
20. tv5 = tv4^tv5
21. e1 = tv5 == 1
22. tv2 = tv3 * tv1
23. tv1 = tv1 * tv1
24. tv5 = tv4 * tv1
25. tv3 = CMOV(tv2, tv3, e1)
26. tv4 = CMOV(tv5, tv4, e1)
27. return (isQR, tv3)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 82]
Internet-Draft hash-to-curve June 2022
F.2.1.2. optimized sqrt_ratio for q = 3 mod 4
sqrt_ratio_3mod4(u, v)
Parameters:
- F, a finite field of characteristic p and order q = p^m,
where q = 3 mod 4.
- Z, the constant from the simplified SWU map.
Input: u and v, elements of F, where v != 0.
Output: (b, y), where
b = True and y = sqrt(u / v) if (u / v) is square in F, and
b = False and y = sqrt(Z * (u / v)) otherwise.
Constants:
1. c1 = (q - 3) / 4 # Integer arithmetic
2. c2 = sqrt(-Z)
Procedure:
1. tv1 = v^2
2. tv2 = u * v
3. tv1 = tv1 * tv2
4. y1 = tv1^c1
5. y1 = y1 * tv2
6. y2 = y1 * c2
7. tv3 = y1^2
8. tv3 = tv3 * v
9. isQR = tv3 == u
10. y = CMOV(y2, y1, isQR)
11. return (isQR, y)
F.2.1.3. optimized sqrt_ratio for q = 5 mod 8
Faz-Hernandez, et al. Expires 17 December 2022 [Page 83]
Internet-Draft hash-to-curve June 2022
sqrt_ratio_5mod8(u, v)
Parameters:
- F, a finite field of characteristic p and order q = p^m,
where q = 5 mod 8.
- Z, the constant from the simplified SWU map.
Input: u and v, elements of F, where v != 0.
Output: (b, y), where
b = True and y = sqrt(u / v) if (u / v) is square in F, and
b = False and y = sqrt(Z * (u / v)) otherwise.
Constants:
1. c1 = (q - 5) / 8
2. c2 = sqrt(-1)
3. c3 = sqrt(Z / c2)
Steps:
1. tv1 = v^2
2. tv2 = tv1 * v
3. tv1 = tv1^2
4. tv2 = tv2 * u
5. tv1 = tv1 * tv2
6. y1 = tv1^c1
7. y1 = y1 * tv2
8. tv1 = y1 * c2
9. tv2 = tv1^2
10. tv2 = tv2 * v
11. e1 = tv2 == u
12. y1 = CMOV(y1, tv1, e1)
13. tv2 = y1^2
14. tv2 = tv2 * v
15. isQR = tv2 == u
16. y2 = y1 * c3
17. tv1 = y2 * c2
18. tv2 = tv1^2
19. tv2 = tv2 * v
20. tv3 = Z * u
21. e2 = tv2 == tv3
22. y2 = CMOV(y2, tv1, e2)
23. y = CMOV(y2, y1, isQR)
24. return (isQR, y)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 84]
Internet-Draft hash-to-curve June 2022
F.3. Elligator 2 method
This section gives a straight-line implementation of the Elligator 2
method for any Montgomery curve of the form given in Section 6.7.
See Section 6.7.1 for information on the constants used in this
mapping.
Appendix G.2 gives optimized straight-line procedures that apply to
specific classes of curves and base fields, including curve25519 and
curve448 [RFC7748].
map_to_curve_elligator2(u)
Input: u, an element of F.
Output: (s, t), a point on M.
Constants:
1. c1 = J / K
2. c2 = 1 / K^2
Steps:
1. tv1 = u^2
2. tv1 = Z * tv1 # Z * u^2
3. e1 = tv1 == -1 # exceptional case: Z * u^2 == -1
4. tv1 = CMOV(tv1, 0, e1) # if tv1 == -1, set tv1 = 0
5. x1 = tv1 + 1
6. x1 = inv0(x1)
7. x1 = -c1 * x1 # x1 = -(J / K) / (1 + Z * u^2)
8. gx1 = x1 + c1
9. gx1 = gx1 * x1
10. gx1 = gx1 + c2
11. gx1 = gx1 * x1 # gx1 = x1^3 + (J / K) * x1^2 + x1 / K^2
12. x2 = -x1 - c1
13. gx2 = tv1 * gx1
14. e2 = is_square(gx1) # If is_square(gx1)
15. x = CMOV(x2, x1, e2) # then x = x1, else x = x2
16. y2 = CMOV(gx2, gx1, e2) # then y2 = gx1, else y2 = gx2
17. y = sqrt(y2)
18. e3 = sgn0(y) == 1
19. y = CMOV(y, -y, e2 XOR e3) # fix sign of y
20. s = x * K
21. t = y * K
22. return (s, t)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 85]
Internet-Draft hash-to-curve June 2022
Appendix G. Curve-specific optimized sample code
This section gives sample implementations optimized for some of the
elliptic curves listed in Section 8. Sample Sage [SAGE] code for
each algorithm can also be found in the draft repository
[hash2curve-repo].
G.1. Interface and projective coordinate systems
The sample code in this section uses a different interface than the
mappings of Section 6. Specifically, each mapping function in this
section has the following signature:
(xn, xd, yn, yd) = map_to_curve(u)
The resulting affine point (x, y) is given by (xn / xd, yn / yd).
The reason for this modified interface is that it enables further
optimizations when working with points in a projective coordinate
system. This is desirable, for example, when the resulting point
will be immediately multiplied by a scalar, since most scalar
multiplication algorithms operate on projective points.
Projective coordinates are also useful when implementing random
oracle encodings (Section 3). One reason is that, in general, point
addition is faster using projective coordinates. Another reason is
that, for Weierstrass curves, projective coordinates allow using
complete addition formulas [RCB16]. This is especially convenient
when implementing a constant-time encoding, because it eliminates the
need for a special case when Q0 == Q1, which incomplete addition
formulas usually do not handle.
The following are two commonly used projective coordinate systems and
the corresponding conversions:
* A point (X, Y, Z) in homogeneous projective coordinates
corresponds to the affine point (x, y) = (X / Z, Y / Z); the
inverse conversion is given by (X, Y, Z) = (x, y, 1). To convert
(xn, xd, yn, yd) to homogeneous projective coordinates, compute
(X, Y, Z) = (xn * yd, yn * xd, xd * yd).
* A point (X', Y', Z') in Jacobian projective coordinates
corresponds to the affine point (x, y) = (X' / Z'^2, Y' / Z'^3);
the inverse conversion is given by (X', Y', Z') = (x, y, 1). To
convert (xn, xd, yn, yd) to Jacobian projective coordinates,
compute (X', Y', Z') = (xn * xd * yd^2, yn * yd^2 * xd^3, xd *
yd).
Faz-Hernandez, et al. Expires 17 December 2022 [Page 86]
Internet-Draft hash-to-curve June 2022
G.2. Elligator 2
G.2.1. curve25519 (q = 5 (mod 8), K = 1)
The following is a straight-line implementation of Elligator 2 for
curve25519 [RFC7748] as specified in Section 8.5.
This implementation can also be used for any Montgomery curve with K
= 1 over GF(q) where q = 5 (mod 8).
map_to_curve_elligator2_curve25519(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on curve25519.
Constants:
1. c1 = (q + 3) / 8 # Integer arithmetic
2. c2 = 2^c1
3. c3 = sqrt(-1)
4. c4 = (q - 5) / 8 # Integer arithmetic
Steps:
1. tv1 = u^2
2. tv1 = 2 * tv1
3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not
4. x1n = -J # x1 = x1n / xd = -J / (1 + 2 * u^2)
5. tv2 = xd^2
6. gxd = tv2 * xd # gxd = xd^3
7. gx1 = J * tv1 # x1n + J * xd
8. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd
9. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2
10. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2
11. tv3 = gxd^2
12. tv2 = tv3^2 # gxd^4
13. tv3 = tv3 * gxd # gxd^3
14. tv3 = tv3 * gx1 # gx1 * gxd^3
15. tv2 = tv2 * tv3 # gx1 * gxd^7
16. y11 = tv2^c4 # (gx1 * gxd^7)^((p - 5) / 8)
17. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((p - 5) / 8)
18. y12 = y11 * c3
19. tv2 = y11^2
20. tv2 = tv2 * gxd
21. e1 = tv2 == gx1
22. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt
23. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd
24. y21 = y11 * u
25. y21 = y21 * c2
Faz-Hernandez, et al. Expires 17 December 2022 [Page 87]
Internet-Draft hash-to-curve June 2022
26. y22 = y21 * c3
27. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1)
28. tv2 = y21^2
29. tv2 = tv2 * gxd
30. e2 = tv2 == gx2
31. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt
32. tv2 = y1^2
33. tv2 = tv2 * gxd
34. e3 = tv2 == gx1
35. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2
36. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2
37. e4 = sgn0(y) == 1 # Fix sign of y
38. y = CMOV(y, -y, e3 XOR e4)
39. return (xn, xd, y, 1)
G.2.2. edwards25519
The following is a straight-line implementation of Elligator 2 for
edwards25519 [RFC7748] as specified in Section 8.5. The subroutine
map_to_curve_elligator2_curve25519 is defined in Appendix G.2.1.
Note that the sign of the constant c1 below is chosen as specified in
Section 6.8.1, i.e., applying the rational map to the edwards25519
base point yields the curve25519 base point (see erratum [EID4730]).
map_to_curve_elligator2_edwards25519(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on edwards25519.
Constants:
1. c1 = sqrt(-486664) # sgn0(c1) MUST equal 0
Steps:
1. (xMn, xMd, yMn, yMd) = map_to_curve_elligator2_curve25519(u)
2. xn = xMn * yMd
3. xn = xn * c1
4. xd = xMd * yMn # xn / xd = c1 * xM / yM
5. yn = xMn - xMd
6. yd = xMn + xMd # (n / d - 1) / (n / d + 1) = (n - d) / (n + d)
7. tv1 = xd * yd
8. e = tv1 == 0
9. xn = CMOV(xn, 0, e)
10. xd = CMOV(xd, 1, e)
11. yn = CMOV(yn, 1, e)
12. yd = CMOV(yd, 1, e)
13. return (xn, xd, yn, yd)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 88]
Internet-Draft hash-to-curve June 2022
#x27; Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction
DISCLAIMER: This is a work-in-progress draft of MLS and has not yet
seen significant security analysis. It should not be used as a basis
for building production systems.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/mlswg/mls-protocol.
Instructions are on that page as well. Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the MLS mailing list.
A group of users who want to send each other encrypted messages needs
a way to derive shared symmetric encryption keys. For two parties,
this problem has been studied thoroughly, with the Double Ratchet
emerging as a common solution [doubleratchet] [signal]. Channels
implementing the Double Ratchet enjoy fine-grained forward secrecy as
well as post-compromise security, but are nonetheless efficient
enough for heavy use over low-bandwidth networks.
For a group of size greater than two, a common strategy is to
unilaterally broadcast symmetric "sender" keys over existing shared
symmetric channels, and then for each member to send messages to the
group encrypted with their own sender key. Unfortunately, while this
improves efficiency over pairwise broadcast of individual messages
and provides forward secrecy (with the addition of a hash ratchet),
it is difficult to achieve post-compromise security with sender keys.
An adversary who learns a sender key can often indefinitely and
passively eavesdrop on that member's messages. Generating and
distributing a new sender key provides a form of post-compromise
security with regard to that sender. However, it requires
computation and communications resources that scale linearly with the
size of the group.
Barnes, et al. Expires 14 April 2022 [Page 4]
Internet-Draft MLS October 2021
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security. Based on earlier work on "asynchronous
ratcheting trees" [art], the protocol presented here uses an
asynchronous key-encapsulation mechanism for tree structures. This
mechanism allows the members of the group to derive and update shared
keys with costs that scale as the log of the group size.
1.1. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION.
draft-12
* Use the GroupContext to derive the joiner_secret (*)
* Make PreSharedKeys non optional in GroupSecrets (*)
* Update name for this particular key (*)
* Truncate tree size on removal (*)
* Use HPKE draft-08 (*)
* Clarify requirements around identity in MLS groups (*)
* Signal the intended wire format for MLS messages (*)
* Inject GroupContext as HPKE info instead of AAD (*)
* Clarify extension handling and make extension updatable (*)
* Improve extensibility of Proposals (*)
* Constrain proposal in External Commit (*)
* Remove the notion of a 'leaf index' (*)
* Add group_context_extensions proposal ID (*)
* Add RequiredCapabilities extension (*)
* Use cascaded KDF instead of concatenation to consolidate PSKs (*)
* Use key package hash to index clients in message structs (*)
* Don't require PublicGroupState for external init (*)
Barnes, et al. Expires 14 April 2022 [Page 5]
Internet-Draft MLS October 2021
* Make ratchet tree section clearer.
* Handle non-member sender cases in MLSPlaintextTBS
* Clarify encoding of signatures with NIST curves
* Remove OPEN ISSUEs and TODOs
* Normalize the description of the zero vector
draft-11
* Include subtree keys in parent hash (*)
* Pin HPKE to draft-07 (*)
* Move joiner secret to the end of the first key schedule epoch (*)
* Add an AppAck proposal
* Make initializations of transcript hashes consistent
draft-10
* Allow new members to join via an external Commit (*)
* Enable proposals to be sent inline in a Commit (*)
* Re-enable constant-time Add (*)
* Change expiration extension to lifetime extension (*)
* Make the tree in the Welcome optional (*)
* PSK injection, re-init, sub-group branching (*)
* Require the initial init_secret to be a random value (*)
* Remove explicit sender data nonce (*)
* Do not encrypt to joiners in UpdatePath generation (*)
* Move MLSPlaintext signature under the confirmation tag (*)
* Explicitly authenticate group membership with MLSPLaintext (*)
* Clarify X509Credential structure (*)
Barnes, et al. Expires 14 April 2022 [Page 6]
Internet-Draft MLS October 2021
* Remove uneeded interim transcript hash from GroupInfo (*)
* IANA considerations
* Derive an authentication secret
* Use Extract/Expand from HPKE KDF
* Clarify that application messages MUST be encrypted
draft-09
* Remove blanking of nodes on Add (*)
* Change epoch numbers to uint64 (*)
* Add PSK inputs (*)
* Add key schedule exporter (*)
* Sign the updated direct path on Commit, using "parent hashes" and
one signature per leaf (*)
* Use structured types for external senders (*)
* Redesign Welcome to include confirmation and use derived keys (*)
* Remove ignored proposals (*)
* Always include an Update with a Commit (*)
* Add per-message entropy to guard against nonce reuse (*)
* Use the same hash ratchet construct for both application and
handshake keys (*)
* Add more ciphersuites
* Use HKDF to derive key pairs (*)
* Mandate expiration of ClientInitKeys (*)
* Add extensions to GroupContext and flesh out the extensibility
story (*)
* Rename ClientInitKey to KeyPackage
draft-08
Barnes, et al. Expires 14 April 2022 [Page 7]
Internet-Draft MLS October 2021
* Change ClientInitKeys so that they only refer to one ciphersuite
(*)
* Decompose group operations into Proposals and Commits (*)
* Enable Add and Remove proposals from outside the group (*)
* Replace Init messages with multi-recipient Welcome message (*)
* Add extensions to ClientInitKeys for expiration and downgrade
resistance (*)
* Allow multiple Proposals and a single Commit in one MLSPlaintext
(*)
draft-07
* Initial version of the Tree based Application Key Schedule (*)
* Initial definition of the Init message for group creation (*)
* Fix issue with the transcript used for newcomers (*)
* Clarifications on message framing and HPKE contexts (*)
draft-06
* Reorder blanking and update in the Remove operation (*)
* Rename the GroupState structure to GroupContext (*)
* Rename UserInitKey to ClientInitKey
* Resolve the circular dependency that draft-05 introduced in the
confirmation MAC calculation (*)
* Cover the entire MLSPlaintext in the transcript hash (*)
draft-05
* Common framing for handshake and application messages (*)
* Handshake message encryption (*)
* Convert from literal state to a commitment via the "tree hash" (*)
* Add credentials to the tree and remove the "roster" concept (*)
Barnes, et al. Expires 14 April 2022 [Page 8]
Internet-Draft MLS October 2021
* Remove the secret field from tree node values
draft-04
* Updating the language to be similar to the Architecture document
* ECIES is now renamed in favor of HPKE (*)
* Using a KDF instead of a Hash in TreeKEM (*)
draft-03
* Added ciphersuites and signature schemes (*)
* Re-ordered fields in UserInitKey to make parsing easier (*)
* Fixed inconsistencies between Welcome and GroupState (*)
* Added encryption of the Welcome message (*)
draft-02
* Removed ART (*)
* Allowed partial trees to avoid double-joins (*)
* Added explicit key confirmation (*)
draft-01
* Initial description of the Message Protection mechanism. (*)
* Initial specification proposal for the Application Key Schedule
using the per-participant chaining of the Application Secret
design. (*)
* Initial specification proposal for an encryption mechanism to
protect Application Messages using an AEAD scheme. (*)
* Initial specification proposal for an authentication mechanism of
Application Messages using signatures. (*)
* Initial specification proposal for a padding mechanism to
improving protection of Application Messages against traffic
analysis. (*)
Barnes, et al. Expires 14 April 2022 [Page 9]
Internet-Draft MLS October 2021
* Inversion of the Group Init Add and Application Secret derivations
in the Handshake Key Schedule to be ease chaining in case we
switch design. (*)
* Removal of the UserAdd construct and split of GroupAdd into Add
and Welcome messages (*)
* Initial proposal for authenticating handshake messages by signing
over group state and including group state in the key schedule (*)
* Added an appendix with example code for tree math
* Changed the ECIES mechanism used by TreeKEM so that it uses nonces
generated from the shared secret
draft-00
* Initial adoption of draft-barnes-mls-protocol-01 as a WG item.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Client: An agent that uses this protocol to establish shared
cryptographic state with other clients. A client is defined by
the cryptographic keys it holds.
Group: A collection of clients with shared cryptographic state.
Member: A client that is included in the shared state of a group,
hence has access to the group's secrets.
Key Package: A signed object describing a client's identity and
capabilities, and including a hybrid public-key encryption (HPKE
[I-D.irtf-cfrg-hpke]) public key that can be used to encrypt to
that client.
Initialization Key (InitKey): A key package that is prepublished by
a client, which other clients can use to introduce the client to a
new group.
Signature Key: A signing key pair used to authenticate the sender of
a message.
Barnes, et al. Expires 14 April 2022 [Page 10]
Internet-Draft MLS October 2021
Terminology specific to tree computations is described in Section 5.
We use the TLS presentation language [RFC8446] to describe the
structure of protocol messages.
3. Basic Assumptions
This protocol is designed to execute in the context of a Service
Provider (SP) as described in [I-D.ietf-mls-architecture]. In
particular, we assume the SP provides the following services:
* A signature key provider which allows clients to authenticate
protocol messages in a group.
* A broadcast channel, for each group, which will relay a message to
all members of a group. For the most part, we assume that this
channel delivers messages in the same order to all participants.
(See Section 13 for further considerations.)
* A directory to which clients can publish key packages and download
key packages for other participants.
4. Protocol Overview
The goal of this protocol is to allow a group of clients to exchange
confidential and authenticated messages. It does so by deriving a
sequence of secrets and keys known only to members. Those should be
secret against an active network adversary and should have both
forward secrecy and post-compromise security with respect to
compromise of any members.
We describe the information stored by each client as _state_, which
includes both public and private data. An initial state is set up by
a group creator, which is a group containing only itself. The
creator then sends _Add_ proposals for each client in the initial set
of members, followed by a _Commit_ message which incorporates all of
the _Adds_ into the group state. Finally, the group creator
generates a _Welcome_ message corresponding to the Commit and sends
this directly to all the new members, who can use the information it
contains to set up their own group state and derive a shared secret.
Members exchange Commit messages for post-compromise security, to add
new members, and to remove existing members. These messages produce
new shared secrets which are causally linked to their predecessors,
forming a logical Directed Acyclic Graph (DAG) of states.
The protocol algorithms we specify here follow. Each algorithm
specifies both (i) how a client performs the operation and (ii) how
other clients update their state based on it.
Barnes, et al. Expires 14 April 2022 [Page 11]
Internet-Draft MLS October 2021
There are three major operations in the lifecycle of a group:
* Adding a member, initiated by a current member;
* Updating the leaf secret of a member;
* Removing a member.
Each of these operations is "proposed" by sending a message of the
corresponding type (Add / Update / Remove). The state of the group
is not changed, however, until a Commit message is sent to provide
the group with fresh entropy. In this section, we show each proposal
being committed immediately, but in more advanced deployment cases an
application might gather several proposals before committing them all
at once.
Before the initialization of a group, clients publish InitKeys (as
KeyPackage objects) to a directory provided by the Service Provider.
Group
A B C Directory Channel
| | | | |
| KeyPackageA | | | |
|------------------------------------------------->| |
| | | | |
| | KeyPackageB | | |
| |-------------------------------->| |
| | | | |
| | | KeyPackageC | |
| | |--------------->| |
| | | | |
When a client A wants to establish a group with B and C, it first
initializes a group state containing only itself and downloads
KeyPackages for B and C. For each member, A generates an Add and
Commit message adding that member, and broadcasts them to the group.
It also generates a Welcome message and sends this directly to the
new member (there's no need to send it to the group). Only after A
has received its Commit message back from the server does it update
its state to reflect the new member's addition.
Upon receiving the Welcome message, the new member will be able to
read and send new messages to the group. Messages received before
the client has joined the group are ignored.
Barnes, et al. Expires 14 April 2022 [Page 12]
Internet-Draft MLS October 2021
Group
A B C Directory Channel
| | | | |
| KeyPackageB, KeyPackageC | |
|<-------------------------------------------| |
|state.init() | | | |
| | | | |
| | | | Add(A->AB) |
| | | | Commit(Add) |
|--------------------------------------------------------------->|
| | | | |
| Welcome(B) | | | |
|------------->|state.join() | | |
| | | | |
| | | | Add(A->AB) |
| | | | Commit(Add) |
|<---------------------------------------------------------------|
|state.add(B) | | | |
| | | | |
| | | | |
| | | | Add(AB->ABC) |
| | | | Commit(Add) |
|--------------------------------------------------------------->|
| | | | |
| | Welcome(C) | | |
|---------------------------->|state.join() | |
| | | | |
| | | | Add(AB->ABC) |
| | | | Commit(Add) |
|<---------------------------------------------------------------|
|state.add(C) |<------------------------------------------------|
| |state.add(C) | | |
| | | | |
Subsequent additions of group members proceed in the same way. Any
member of the group can download a KeyPackage for a new client and
broadcast an Add message that the current group can use to update
their state, and a Welcome message that the new client can use to
initialize its state and join the group.
To enforce the forward secrecy and post-compromise security of
messages, each member periodically updates their leaf secret. Any
member can update this information at any time by generating a fresh
KeyPackage and sending an Update message followed by a Commit
message. Once all members have processed both, the group's secrets
will be unknown to an attacker that had compromised the sender's
prior leaf secret.
Barnes, et al. Expires 14 April 2022 [Page 13]
Internet-Draft MLS October 2021
Update messages should be sent at regular intervals of time as long
as the group is active, and members that don't update should
eventually be removed from the group. It's left to the application
to determine an appropriate amount of time between Updates.
Group
A B ... Z Directory Channel
| | | | |
| | Update(B) | | |
| |------------------------------------------->|
| Commit(Upd) | | | |
|---------------------------------------------------------->|
| | | | |
| | | | Update(B) |
| | | | Commit(Upd) |
|<----------------------------------------------------------|
|state.upd(B) |<-------------------------------------------|
| |state.upd(B) |<----------------------------|
| | |state.upd(B) | |
| | | | |
Members are removed from the group in a similar way. Any member of
the group can send a Remove proposal followed by a Commit message,
which adds new entropy to the group state that's known to all except
the removed member. Note that this does not necessarily imply that
any member is actually allowed to evict other members; groups can
enforce access control policies on top of these basic mechanism.
Group
A B ... Z Directory Channel
| | | | |
| | | Remove(B) | |
| | | Commit(Rem) | |
| | |---------------------------->|
| | | | |
| | | | Remove(B) |
| | | | Commit(Rem) |
|<----------------------------------------------------------|
|state.rem(B) | |<----------------------------|
| | |state.rem(B) | |
| | | | |
| | | | |
5. Ratchet Trees
The protocol uses "ratchet trees" for deriving shared secrets among a
group of clients.
Barnes, et al. Expires 14 April 2022 [Page 14]
Internet-Draft MLS October 2021
5.1. Tree Computation Terminology
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our trees have
precisely two children, a _left_ child and a _right_ child. A node
is the _root_ of a tree if it has no parents, and _intermediate_ if
it has both children and parents. The _descendants_ of a node are
that node, its children, and the descendants of its children, and we
say a tree _contains_ a node if that node is a descendant of the root
of the tree. Nodes are _siblings_ if they share the same parent.
A _subtree_ of a tree is the tree given by the descendants of any
node, the _head_ of the subtree. The _size_ of a tree or subtree is
the number of leaf nodes it contains. For a given parent node, its
_left subtree_ is the subtree with its left child as head
(respectively _right subtree_).
All trees used in this protocol are left-balanced binary trees. A
binary tree is _full_ (and _balanced_) if its size is a power of two
and for any parent node in the tree, its left and right subtrees have
the same size.
A binary tree is _left-balanced_ if for every parent, either the
parent is balanced, or the left subtree of that parent is the largest
full subtree that could be constructed from the leaves present in the
parent's own subtree. Given a list of n items, there is a unique
left-balanced binary tree structure with these elements as leaves.
(Note that left-balanced binary trees are the same structure that is
used for the Merkle trees in the Certificate Transparency protocol
[I-D.ietf-trans-rfc6962-bis].)
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node's parent along with the parent's
direct path. The _copath_ of a node is the node's sibling
concatenated with the list of siblings of all the nodes in its direct
path, excluding the root.
For example, in the below tree:
* The direct path of C is (CD, ABCD, ABCDEFG)
* The copath of C is (D, AB, EFG)
Barnes, et al. Expires 14 April 2022 [Page 15]
Internet-Draft MLS October 2021
7 = root
______|______
/ \
3 11
__|__ __|
/ \ / \
1 5 9 |
/ \ / \ / \ |
A B C D E F G
1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2
Each node in the tree is assigned an _index_, starting at zero and
running from left to right. A node is a leaf node if and only if it
has an even index. The node indices for the nodes in the above tree
are as follows:
* 0 = A
* 1 = AB
* 2 = B
* 3 = ABCD
* 4 = C
* 5 = CD
* 6 = D
* 7 = ABCDEFG
* 8 = E
* 9 = EF
* 10 = F
* 11 = EFG
* 12 = G
A tree with n leaves has 2*n - 1 nodes. For example, the above tree
has 7 leaves (A, B, C, D, E, F, G) and 13 nodes. The root of a tree
with n leaves is always the node with index 2^k - 1, where k is the
largest number such that 2^k < n.
Barnes, et al. Expires 14 April 2022 [Page 16]
Internet-Draft MLS October 2021
5.2. Ratchet Tree Nodes
A particular instance of a ratchet tree is defined by the same
parameters that define an instance of HPKE, namely:
* A Key Encapsulation Mechanism (KEM), including a DeriveKeyPair
function that creates a key pair for the KEM from a symmetric
secret
* A Key Derivation Function (KDF), including Extract and Expand
functions
* An AEAD encryption scheme
Each node in a ratchet tree contains up to five values:
* A private key (only within the member's direct path, see below)
* A public key
* An ordered list of node indices for "unmerged" leaves (see
Section 5.3)
* A credential (only for leaf nodes)
* A hash of certain information about the node's parent, as of the
last time the node was changed (see Section 7.5).
The conditions under which each of these values must or must not be
present are laid out in Section 5.3.
A node in the tree may also be _blank_, indicating that no value is
present at that node. The _resolution_ of a node is an ordered list
of non-blank nodes that collectively cover all non-blank descendants
of the node.
* The resolution of a non-blank node comprises the node itself,
followed by its list of unmerged leaves, if any
* The resolution of a blank leaf node is the empty list
* The resolution of a blank intermediate node is the result of
concatenating the resolution of its left child with the resolution
of its right child, in that order
For example, consider the following tree, where the "_" character
represents a blank node and unmerged leaves are indicated in square
brackets:
Barnes, et al. Expires 14 April 2022 [Page 17]
Internet-Draft MLS October 2021
_
__|__
/ \
_ 5[C]
/ \ / \
A _ C D
0 1 2 3 4 5 6
In this tree, we can see all of the above rules in play:
* The resolution of node 5 is the list [CD, C]
* The resolution of node 2 is the empty list []
* The resolution of node 3 is the list [A, CD, C]
Every node, regardless of whether the node is blank or populated, has
a corresponding _hash_ that summarizes the contents of the subtree
below that node. The rules for computing these hashes are described
in Section 7.6.
5.3. Views of a Ratchet Tree
We generally assume that each participant maintains a complete and
up-to-date view of the public state of the group's ratchet tree,
including the public keys for all nodes and the credentials
associated with the leaf nodes.
No participant in an MLS group knows the private key associated with
every node in the tree. Instead, each member is assigned to a leaf
of the tree, which determines the subset of private keys it knows.
The credential stored at that leaf is one provided by the member.
In particular, MLS maintains the members' views of the tree in such a
way as to maintain the _tree invariant_:
The private key for a node in the tree is known to a member of
the group only if that member's leaf is a descendant of
the node.
In other words, if a node is not blank, then it holds a public key.
The corresponding private key is known only to members occupying
leaves below that node.
The reverse implication is not true: A member may not know the
private keys of all the intermediate nodes they're below. Such a
member has an _unmerged_ leaf. Encrypting to an intermediate node
Barnes, et al. Expires 14 April 2022 [Page 18]
Internet-Draft MLS October 2021
requires encrypting to the node's public key, as well as the public
keys of all the unmerged leaves below it. A leaf is unmerged when it
is first added, because the process of adding the leaf does not give
it access to all of the nodes above it in the tree. Leaves are
"merged" as they receive the private keys for nodes, as described in
Section 5.4.
5.4. Ratchet Tree Evolution
A member of an MLS group advances the key schedule to provide forward
secrecy and post-compromise security by providing the group with
fresh key material to be added into the group's shared secret. To do
so, one member of the group generates fresh key material, applies it
to their local tree state, and then sends this key material to other
members in the group via an UpdatePath message (see Section 7.8) .
All other group members then apply the key material in the UpdatePath
to their own local tree state to derive the group's now-updated
shared secret.
To begin, the generator of the UpdatePath updates its leaf KeyPackage
and its direct path to the root with new secret values. The HPKE
leaf public key within the KeyPackage MUST be derived from a freshly
generated HPKE secret key to provide post-compromise security.
The generator of the UpdatePath starts by sampling a fresh random
value called "leaf_secret", and uses the leaf_secret to generate
their leaf HPKE key pair (see Section 7) and to seed a sequence of
"path secrets", one for each ancestor of its leaf. In this setting,
path_secret[0] refers to the node directly above the leaf,
path_secret[1] for its parent, and so on. At each step, the path
secret is used to derive a new secret value for the corresponding
node, from which the node's key pair is derived.
leaf_node_secret = DeriveSecret(leaf_secret, "node")
path_secret[0] = DeriveSecret(leaf_secret, "path")
path_secret[n] = DeriveSecret(path_secret[n-1], "path")
node_secret[n] = DeriveSecret(path_secret[n], "node")
leaf_priv, leaf_pub = KEM.DeriveKeyPair(leaf_node_secret)
node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n])
For example, suppose there is a group with four members, with C an
unmerged leaf at node 5:
Barnes, et al. Expires 14 April 2022 [Page 19]
Internet-Draft MLS October 2021
3
__|__
/ \
1 5[C]
/ \ / \
A B C D
0 1 2 3 4 5 6
If member B subsequently generates an UpdatePath based on a secret
"leaf_secret", then it would generate the following sequence of path
secrets:
path_secret[1] --> node_secret[1] --> node_priv[1], node_pub[1]
^
|
path_secret[0] --> node_secret[0] --> node_priv[0], node_pub[0]
^
|
leaf_secret --> leaf_node_secret --> leaf_priv, leaf_pub
~> leaf_key_package
After applying the UpdatePath, the tree will have the following
structure, where lp and np[i] represent the leaf_priv and node_priv
values generated as described above:
np[1] -> 3
__|__
/ \
np[0] -> 1 5[C]
/ \ / \
A B C D
^
|
lp
0 1 2 3 4 5 6
After performing these operations, the generator of the UpdatePath
MUST delete the leaf_secret.
Barnes, et al. Expires 14 April 2022 [Page 20]
Internet-Draft MLS October 2021
5.5. Synchronizing Views of the Tree
After generating fresh key material and applying it to ratchet
forward their local tree state as described in the prior section, the
generator must broadcast this update to other members of the group in
a Commit message, who apply it to keep their local views of the tree
in sync with the sender's. More specifically, when a member commits
a change to the tree (e.g., to add or remove a member), it transmits
an UpdatePath containing a set of public keys and encrypted path
secrets for intermediate nodes in the direct path of its leaf. The
other members of the group use these values to update their view of
the tree, aligning their copy of the tree to the sender's.
An UpdatePath contains the following information for each node in the
direct path of the sender's leaf, including the root:
* The public key for the node
* Zero or more encrypted copies of the path secret corresponding to
the node
The path secret value for a given node is encrypted for the subtree
corresponding to the parent's non-updated child, that is, the child
on the copath of the sender's leaf node. There is one encryption of
the path secret to each public key in the resolution of the non-
updated child.
The recipient of an UpdatePath processes it with the following steps:
1. Compute the updated path secrets.
* Identify a node in the direct path for which the local member
is in the subtree of the non-updated child.
* Identify a node in the resolution of the copath node for which
this node has a private key.
* Decrypt the path secret for the parent of the copath node
using the private key from the resolution node.
* Derive path secrets for ancestors of that node using the
algorithm described above.
* The recipient SHOULD verify that the received public keys
agree with the public keys derived from the new path_secret
values.
2. Merge the updated path secrets into the tree.
Barnes, et al. Expires 14 April 2022 [Page 21]
Internet-Draft MLS October 2021
* For all updated nodes,
- Replace the public key for each node with the received
public key.
- Set the list of unmerged leaves to the empty list.
- Store the updated hash of the node's parent (represented as
a ParentNode struct), going from root to leaf, so that each
hash incorporates all the nodes above it. The root node
always has a zero-length hash for this value.
* For nodes where an updated path secret was computed in step 1,
compute the corresponding node key pair and replace the values
stored at the node with the computed values.
For example, in order to communicate the example update described in
the previous section, the sender would transmit the following values:
+=============+====================================================+
| Public Key | Ciphertext(s) |
+=============+====================================================+
| node_pub[1] | E(pk(5), path_secret[1]), E(pk(C), path_secret[1]) |
+-------------+----------------------------------------------------+
| node_pub[0] | E(pk(A), path_secret[0]) |
+-------------+----------------------------------------------------+
Table 1
In this table, the value pk(ns[X]) represents the public key derived
from the node secret X, whereas pk(X) represents the public leaf key
for user X. The value E(K, S) represents the public-key encryption
of the path secret S to the public key K (using HPKE).
After processing the update, each recipient MUST delete outdated key
material, specifically:
* The path secrets used to derive each updated node key pair.
* Each outdated node key pair that was replaced by the update.
6. Cryptographic Objects
6.1. Ciphersuites
Each MLS session uses a single ciphersuite that specifies the
following primitives to be used in group key computations:
Barnes, et al. Expires 14 April 2022 [Page 22]
Internet-Draft MLS October 2021
* HPKE parameters:
- A Key Encapsulation Mechanism (KEM)
- A Key Derivation Function (KDF)
- An AEAD encryption algorithm
* A hash algorithm
* A signature algorithm
MLS uses draft-08 of HPKE [I-D.irtf-cfrg-hpke] for public-key
encryption. The DeriveKeyPair function associated to the KEM for the
ciphersuite maps octet strings to HPKE key pairs.
Ciphersuites are represented with the CipherSuite type. HPKE public
keys are opaque values in a format defined by the underlying protocol
(see the Cryptographic Dependencies section of the HPKE specification
for more information).
opaque HPKEPublicKey<1..2^16-1>;
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for signatures in MLSPlaintext and the tree
signatures. It MUST be the same as the signature algorithm specified
in the credential field of the KeyPackage objects in the leaves of
the tree (including the InitKeys used to add new members).
The ciphersuites are defined in section Section 16.1.
6.2. Credentials
A member of a group authenticates the identities of other
participants by means of credentials issued by some authentication
system, like a PKI. Each type of credential MUST express the
following data in the context of the group it is used with:
* The public key of a signature key pair matching the
SignatureScheme specified by the CipherSuite of the group
* The identity of the holder of the private key
Credentials MAY also include information that allows a relying party
to verify the identity / signing key binding.
Additionally, Credentials SHOULD specify the signature scheme
corresponding to each contained public key.
Barnes, et al. Expires 14 April 2022 [Page 23]
Internet-Draft MLS October 2021
// See RFC 8446 and the IANA TLS SignatureScheme registry
uint16 SignatureScheme;
// See IANA registry for registered values
uint16 CredentialType;
struct {
opaque identity<0..2^16-1>;
SignatureScheme signature_scheme;
opaque signature_key<0..2^16-1>;
} BasicCredential;
struct {
opaque cert_data<0..2^16-1>;
} Certificate;
struct {
CredentialType credential_type;
select (Credential.credential_type) {
case basic:
BasicCredential;
case x509:
Certificate chain<1..2^32-1>;
};
} Credential;
A BasicCredential is a raw, unauthenticated assertion of an identity/
key binding. The format of the key in the public_key field is
defined by the relevant ciphersuite: the group ciphersuite for a
credential in a ratchet tree, the KeyPackage ciphersuite for a
credential in a KeyPackage object.
For X509Credential, each entry in the chain represents a single DER-
encoded X509 certificate. The chain is ordered such that the first
entry (chain[0]) is the end-entity certificate and each subsequent
certificate in the chain MUST be the issuer of the previous
certificate. The algorithm for the public_key in the end-entity
certificate MUST match the relevant ciphersuite.
For ciphersuites using Ed25519 or Ed448 signature schemes, the public
key is in the format specified [RFC8032]. For ciphersuites using
ECDSA with the NIST curves P-256 or P-521, the public key is the
output of the uncompressed Elliptic-Curve-Point-to-Octet-String
conversion according to [SECG].
Barnes, et al. Expires 14 April 2022 [Page 24]
Internet-Draft MLS October 2021
The signatures used throughout this document are encoded as specified
in [RFC8446]. In particular, ECDSA signatures are DER-encoded and
EdDSA signatures are defined as the concatenation of r and s as
specified in [RFC8032].
Note that each new credential that has not already been validated by
the application MUST be validated against the Authentication Service.
7. Key Packages
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish key packages that provide some public
information about a user. KeyPackage structures provide information
about a client that any existing member can use to add this client to
the group asynchronously.
A KeyPackage object specifies a ciphersuite that the client supports,
as well as providing a public key that others can use for key
agreement.
The identity arising from the credential, together with the
endpoint_id in the KeyPackage serve to uniquely identify a client in
a group.
When used as InitKeys, KeyPackages are intended to be used only once
and SHOULD NOT be reused except in case of last resort. (See
Section 15.4). Clients MAY generate and publish multiple InitKeys to
support multiple ciphersuites.
KeyPackages contain a public key chosen by the client, which the
client MUST ensure uniquely identifies a given KeyPackage object
among the set of KeyPackages created by this client.
The value for hpke_init_key MUST be a public key for the asymmetric
encryption scheme defined by cipher_suite. The whole structure is
signed using the client's signature key. A KeyPackage object with an
invalid signature field MUST be considered malformed. The input to
the signature computation comprises all of the fields except for the
signature field.
Barnes, et al. Expires 14 April 2022 [Page 25]
Internet-Draft MLS October 2021
enum {
reserved(0),
mls10(1),
(255)
} ProtocolVersion;
// See IANA registry for registered values
uint16 ExtensionType;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^32-1>;
} Extension;
struct {
ProtocolVersion version;
CipherSuite cipher_suite;
HPKEPublicKey hpke_init_key;
opaque endpoint_id<0..255>;
Credential credential;
Extension extensions<8..2^32-1>;
opaque signature<0..2^16-1>;
} KeyPackage;
KeyPackage objects MUST contain at least two extensions, one of type
capabilities, and one of type lifetime. The capabilities extension
allow MLS session establishment to be safe from downgrade attacks on
the parameters described (as discussed in Section 10), while still
only advertising one version / ciphersuite per KeyPackage.
As the KeyPackage is a structure which is stored in the Ratchet Tree
and updated depending on the evolution of this tree, each
modification of its content MUST be reflected by a change of its
signature. This allow other members to control the validity of the
KeyPackage at any time and in particular in the case of a newcomer
joining the group.
7.1. Key Package IDs
When it is necessary to refer to a specific KeyPackage, protocol
messages incorporate a KeyPackageID:
struct { opaque key_package_hash<0..255>; } KeyPackageID
This value is the hash of the KeyPackage, using the hash indicated by
the cipher_suite field. KeyPackage hashes are used in a Welcome
message to indicate which KeyPackage is being used to include the new
member. Since members of a group are uniquely identified by their
Barnes, et al. Expires 14 April 2022 [Page 26]
Internet-Draft MLS October 2021
leaf KeyPackages, messages within a group use the hash of this key
package to refer to group members, e.g., to specify the target of a
Remove proposal or the signer of an MLSPlaintext.
7.2. Client Capabilities
The capabilities extension indicates what protocol versions,
ciphersuites, protocol extensions, and non-default proposal types are
supported by a client. Proposal types defined in this document are
considered "default" and thus need not be listed.
struct {
ProtocolVersion versions<0..255>;
CipherSuite ciphersuites<0..255>;
ExtensionType extensions<0..255>;
ProposalType proposals<0..255>;
} Capabilities;
This extension MUST be always present in a KeyPackage. Extensions
that appear in the extensions field of a KeyPackage MUST be included
in the extensions field of the capabilities extension.
7.3. Lifetime
The lifetime extension represents the times between which clients
will consider a KeyPackage valid. This time is represented as an
absolute time, measured in seconds since the Unix epoch
(1970-01-01T00:00:00Z). A client MUST NOT use the data in a
KeyPackage for any processing before the not_before date, or after
the not_after date.
uint64 not_before;
uint64 not_after;
Applications MUST define a maximum total lifetime that is acceptable
for a KeyPackage, and reject any KeyPackage where the total lifetime
is longer than this duration.
This extension MUST always be present in a KeyPackage.
7.4. KeyPackage Identifiers
Within MLS, a KeyPackage is identified by its hash (see, e.g.,
Section 11.2.2). The external_key_id extension allows applications
to add an explicit, application-defined identifier to a KeyPackage.
opaque external_key_id<0..2^16-1>;
Barnes, et al. Expires 14 April 2022 [Page 27]
Internet-Draft MLS October 2021
7.5. Parent Hash
The parent_hash extension carries information to authenticate the
structure of the tree, as described below.
opaque parent_hash<0..255>;
Consider a ratchet tree with a parent node P and children V and S.
The parent hash of P changes whenever an UpdatePath object is applied
to the ratchet tree along a path traversing node V (and hence also
P). The new "Parent Hash of P (with Co-Path Child S)" is obtained by
hashing P's ParentHashInput struct using the resolution of S to
populate the original_child_resolution field. This way, P's Parent
Hash fixes the new HPKE public keys of all nodes on the path from P
to the root. Furthermore, for each such key PK the hash also binds
the set of HPKE public keys to which PK's secret key was encrypted in
the commit packet that anounced the UpdatePath object.
struct {
HPKEPublicKey public_key;
opaque parent_hash<0..255>;
HPKEPublicKey original_child_resolution<0..2^32-1>;
} ParentHashInput;
The Parent Hash of P with Co-Path Child S is the hash of a
ParentHashInput object populated as follows. The field public_key
contains the HPKE public key of P. If P is the root, then
parent_hash is set to a zero-length octet string. Otherwise
parent_hash is the Parent Hash of P's parent with P's sibling as the
co-path child.
Finally, original_child_resolution is the array of HPKEPublicKey
values of the nodes in the resolution of S but with the
unmerged_leaves of P omitted. For example, in the ratchet tree
depicted in Section 5.2 the ParentHashInput of node 5 with co-path
child 4 would contain an empty original_child_resolution since 4's
resolution includes only itself but 4 is also an unmerged leaf of 5.
Meanwhile, the ParentHashInput of node 5 with co-path child 6 has an
array with one element in it: the HPKE public key of 6.
7.5.1. Using Parent Hashes
The Parent Hash of P appears in three types of structs. If V is
itself a parent node then P's Parent Hash is stored in the
parent_hash fields of both V's ParentHashInput struct and V's
ParentNode struct. (The ParentNode struct is used to encapsulate all
public information about V that must be conveyed to a new member
joining the group as well as to define the Tree Hash of node V.)
Barnes, et al. Expires 14 April 2022 [Page 28]
Internet-Draft MLS October 2021
If, on the other hand, V is a leaf and its KeyPackage contains the
parent_hash extension then the Parent Hash of P (with V's sibling as
co-path child) is stored in that field. In particular, the extension
MUST be present in the leaf_key_package field of an UpdatePath
object. (This way, the signature of such a KeyPackage also serves to
attest to which keys the group member introduced into the ratchet
tree and to whom the corresponding secret keys were sent. This helps
prevent malicious insiders from constructing artificial ratchet trees
with a node V whose HPKE secret key is known to the insider yet where
the insider isn't assigned a leaf in the subtree rooted at V.
Indeed, such a ratchet tree would violate the tree invariant.)
7.5.2. Verifying Parent Hashes
To this end, when processing a Commit message clients MUST recompute
the expected value of parent_hash for the committer's new leaf and
verify that it matches the parent_hash value in the supplied
leaf_key_package. Moreover, when joining a group, new members MUST
authenticate each non-blank parent node P. A parent node P is
authenticated by performing the following check:
* Let L and R be the left and right children of P, respectively
* If L.parent_hash is equal to the Parent Hash of P with Co-Path
Child R, the check passes
* If R is blank, replace R with its left child until R is either
non-blank or a leaf node
* If R is a blank leaf node, the check fails
* If R.parent_hash is equal to the Parent Hash of P with Co-Path
Child L, the check passes
* Otherwise, the check fails
The left-child recursion under the right child of P is necessary
because the expansion of the tree to the right due to Add proposals
can cause blank nodes to be interposed between a parent node and its
right child.
Barnes, et al. Expires 14 April 2022 [Page 29]
Internet-Draft MLS October 2021
7.6. Tree Hashes
To allow group members to verify that they agree on the public
cryptographic state of the group, this section defines a scheme for
generating a hash value (called the "tree hash") that represents the
contents of the group's ratchet tree and the members' KeyPackages.
The tree hash of a tree is the tree hash of its root node, which we
define recursively, starting with the leaves.
As some nodes may be blank while others contain data we use the
following struct to include data if present.
struct {
uint8 present;
select (present) {
case 0: struct{};
case 1: T value;
}
} optional<T>;
The tree hash of a leaf node is the hash of leaf's LeafNodeHashInput
object which might include a Key Package depending on whether or not
it is blank.
struct {
uint32 node_index;
optional<KeyPackage> key_package;
} LeafNodeHashInput;
Now the tree hash of any non-leaf node is recursively defined to be
the hash of its ParentNodeTreeHashInput. This includes an optional
ParentNode object depending on whether the node is blank or not.
struct {
HPKEPublicKey public_key;
opaque parent_hash<0..255>;
uint32 unmerged_leaves<0..2^32-1>;
} ParentNode;
struct {
uint32 node_index;
optional<ParentNode> parent_node;
opaque left_hash<0..255>;
opaque right_hash<0..255>;
} ParentNodeTreeHashInput;
The left_hash and right_hash fields hold the tree hashes of the
node's left and right children, respectively.
Barnes, et al. Expires 14 April 2022 [Page 30]
Internet-Draft MLS October 2021
7.7. Group State
Each member of the group maintains a GroupContext object that
summarizes the state of the group:
struct {
opaque group_id<0..255>;
uint64 epoch;
opaque tree_hash<0..255>;
opaque confirmed_transcript_hash<0..255>;
Extension extensions<0..2^32-1>;
} GroupContext;
The fields in this state have the following semantics:
* The group_id field is an application-defined identifier for the
group.
* The epoch field represents the current version of the group key.
* The tree_hash field contains a commitment to the contents of the
group's ratchet tree and the credentials for the members of the
group, as described in Section 7.6.
* The confirmed_transcript_hash field contains a running hash over
the messages that led to this state.
When a new member is added to the group, an existing member of the
group provides the new member with a Welcome message. The Welcome
message provides the information the new member needs to initialize
its GroupContext.
Different changes to the group will have different effects on the
group state. These effects are described in their respective
subsections of Section 11.1. The following general rules apply:
* The group_id field is constant
* The epoch field increments by one for each Commit message that is
processed
* The tree_hash is updated to represent the current tree and
credentials
* The confirmed_transcript_hash is updated with the data for an
MLSPlaintext message encoding a Commit message in two parts:
Barnes, et al. Expires 14 April 2022 [Page 31]
Internet-Draft MLS October 2021
struct {
WireFormat wire_format;
opaque group_id<0..255>;
uint64 epoch;
Sender sender;
opaque authenticated_data<0..2^32-1>;
ContentType content_type = commit;
Commit commit;
opaque signature<0..2^16-1>;
} MLSPlaintextCommitContent;
struct {
optional<MAC> confirmation_tag;
} MLSPlaintextCommitAuthData;
interim_transcript_hash_[0] = ""; // zero-length octet string
confirmed_transcript_hash_[n] =
Hash(interim_transcript_hash_[n] ||
MLSPlaintextCommitContent_[n]);
interim_transcript_hash_[n+1] =
Hash(confirmed_transcript_hash_[n] ||
MLSPlaintextCommitAuthData_[n]);
Thus the confirmed_transcript_hash field in a GroupContext object
represents a transcript over the whole history of MLSPlaintext Commit
messages, up to the confirmation tag field in the current
MLSPlaintext message. The confirmation tag is then included in the
transcript for the next epoch. The interim transcript hash is
computed by new members using the confirmation tag in the GroupInfo
struct, and enables existing members to incorporate a Commit message
into the transcript without having to store the whole
MLSPlaintextCommitAuthData structure.
As shown above, when a new group is created, the
interim_transcript_hash field is set to the zero-length octet string.
7.8. Update Paths
As described in Section 11.2, each MLS Commit message may optionally
transmit a KeyPackage leaf and node values along its direct path.
The path contains a public key and encrypted secret value for all
intermediate nodes in the path above the leaf. The path is ordered
from the closest node to the leaf to the root; each node MUST be the
parent of its predecessor.
Barnes, et al. Expires 14 April 2022 [Page 32]
Internet-Draft MLS October 2021
struct {
opaque kem_output<0..2^16-1>;
opaque ciphertext<0..2^16-1>;
} HPKECiphertext;
struct {
HPKEPublicKey public_key;
HPKECiphertext encrypted_path_secret<0..2^32-1>;
} UpdatePathNode;
struct {
KeyPackage leaf_key_package;
UpdatePathNode nodes<0..2^32-1>;
} UpdatePath;
For each UpdatePathNode, the resolution of the corresponding copath
node MUST be filtered by removing all new leaf nodes added as part of
this MLS Commit message. The number of ciphertexts in the
encrypted_path_secret vector MUST be equal to the length of the
filtered resolution, with each ciphertext being the encryption to the
respective resolution node.
The HPKECiphertext values are computed as
kem_output, context = SetupBaseS(node_public_key, group_context)
ciphertext = context.Seal("", path_secret)
where node_public_key is the public key of the node that the path
secret is being encrypted for, group_context is the current
GroupContext object for the group, and the functions SetupBaseS and
Seal are defined according to [I-D.irtf-cfrg-hpke].
Decryption is performed in the corresponding way, using the private
key of the resolution node and the ephemeral public key transmitted
in the message.
8. Key Schedule
Group keys are derived using the Extract and Expand functions from
the KDF for the group's ciphersuite, as well as the functions defined
below:
Barnes, et al. Expires 14 April 2022 [Page 33]G.2.3. curve448 (q = 3 (mod 4), K = 1)
The following is a straight-line implementation of Elligator 2 for
curve448 [RFC7748] as specified in Section 8.6.
This implementation can also be used for any Montgomery curve with K
= 1 over GF(q) where q = 3 (mod 4).
map_to_curve_elligator2_curve448(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on curve448.
Constants:
1. c1 = (q - 3) / 4 # Integer arithmetic
Steps:
1. tv1 = u^2
2. e1 = tv1 == 1
3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0
4. xd = 1 - tv1
5. x1n = -J
6. tv2 = xd^2
7. gxd = tv2 * xd # gxd = xd^3
8. gx1 = -J * tv1 # x1n + J * xd
9. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd
10. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2
11. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2
12. tv3 = gxd^2
13. tv2 = gx1 * gxd # gx1 * gxd
14. tv3 = tv3 * tv2 # gx1 * gxd^3
15. y1 = tv3^c1 # (gx1 * gxd^3)^((p - 3) / 4)
16. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((p - 3) / 4)
17. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd
18. y2 = y1 * u
19. y2 = CMOV(y2, 0, e1)
20. tv2 = y1^2
21. tv2 = tv2 * gxd
22. e2 = tv2 == gx1
23. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2
24. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2
25. e3 = sgn0(y) == 1 # Fix sign of y
26. y = CMOV(y, -y, e2 XOR e3)
27. return (xn, xd, y, 1)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 89]
Internet-Draft hash-to-curve June 2022
G.2.4. edwards448
The following is a straight-line implementation of Elligator 2 for
edwards448 [RFC7748] as specified in Section 8.6. The subroutine
map_to_curve_elligator2_curve448 is defined in Appendix G.2.3.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 90]
Internet-Draft hash-to-curve June 2022
map_to_curve_elligator2_edwards448(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on edwards448.
Steps:
1. (xn, xd, yn, yd) = map_to_curve_elligator2_curve448(u)
2. xn2 = xn^2
3. xd2 = xd^2
4. xd4 = xd2^2
5. yn2 = yn^2
6. yd2 = yd^2
7. xEn = xn2 - xd2
8. tv2 = xEn - xd2
9. xEn = xEn * xd2
10. xEn = xEn * yd
11. xEn = xEn * yn
12. xEn = xEn * 4
13. tv2 = tv2 * xn2
14. tv2 = tv2 * yd2
15. tv3 = 4 * yn2
16. tv1 = tv3 + yd2
17. tv1 = tv1 * xd4
18. xEd = tv1 + tv2
19. tv2 = tv2 * xn
20. tv4 = xn * xd4
21. yEn = tv3 - yd2
22. yEn = yEn * tv4
23. yEn = yEn - tv2
24. tv1 = xn2 + xd2
25. tv1 = tv1 * xd2
26. tv1 = tv1 * xd
27. tv1 = tv1 * yn2
28. tv1 = -2 * tv1
29. yEd = tv2 + tv1
30. tv4 = tv4 * yd2
31. yEd = yEd + tv4
32. tv1 = xEd * yEd
33. e = tv1 == 0
34. xEn = CMOV(xEn, 0, e)
35. xEd = CMOV(xEd, 1, e)
36. yEn = CMOV(yEn, 1, e)
37. yEd = CMOV(yEd, 1, e)
38. return (xEn, xEd, yEn, yEd)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 91]
Internet-Draft hash-to-curve June 2022
G.2.5. Montgomery curves with q = 3 (mod 4)
The following is a straight-line implementation of Elligator 2 that
applies to any Montgomery curve defined over GF(q) where q = 3 (mod
4).
For curves where K = 1, the implementation given in Appendix G.2.3
gives identical results with slightly reduced cost.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 92]
Internet-Draft hash-to-curve June 2022
map_to_curve_elligator2_3mod4(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on the target curve.
Constants:
1. c1 = (q - 3) / 4 # Integer arithmetic
2. c2 = K^2
Steps:
1. tv1 = u^2
2. e1 = tv1 == 1
3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0
4. xd = 1 - tv1
5. xd = xd * K
6. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2))
7. tv2 = xd^2
8. gxd = tv2 * xd
9. gxd = gxd * c2 # gxd = xd^3 * K^2
10. gx1 = x1n * K
11. tv3 = xd * J
12. tv3 = gx1 + tv3 # x1n * K + xd * J
13. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd
14. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2
15. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2
16. tv3 = gxd^2
17. tv2 = gx1 * gxd # gx1 * gxd
18. tv3 = tv3 * tv2 # gx1 * gxd^3
19. y1 = tv3^c1 # (gx1 * gxd^3)^((q - 3) / 4)
20. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((q - 3) / 4)
21. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd
22. y2 = y1 * u
23. y2 = CMOV(y2, 0, e1)
24. tv2 = y1^2
25. tv2 = tv2 * gxd
26. e2 = tv2 == gx1
27. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2
28. xn = xn * K
29. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2
30. e3 = sgn0(y) == 1 # Fix sign of y
31. y = CMOV(y, -y, e2 XOR e3)
32. y = y * K
33. return (xn, xd, y, 1)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 93]
Internet-Draft hash-to-curve June 2022
G.2.6. Montgomery curves with q = 5 (mod 8)
The following is a straight-line implementation of Elligator 2 that
applies to any Montgomery curve defined over GF(q) where q = 5 (mod
8).
For curves where K = 1, the implementation given in Appendix G.2.1
gives identical results with slightly reduced cost.
map_to_curve_elligator2_5mod8(u)
Input: u, an element of F.
Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a
point on the target curve.
Constants:
1. c1 = (q + 3) / 8 # Integer arithmetic
2. c2 = 2^c1
3. c3 = sqrt(-1)
4. c4 = (q - 5) / 8 # Integer arithmetic
5. c5 = K^2
Steps:
1. tv1 = u^2
2. tv1 = 2 * tv1
3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not
4. xd = xd * K
5. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2))
6. tv2 = xd^2
7. gxd = tv2 * xd
8. gxd = gxd * c5 # gxd = xd^3 * K^2
9. gx1 = x1n * K
10. tv3 = xd * J
11. tv3 = gx1 + tv3 # x1n * K + xd * J
12. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd
13. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2
14. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2
15. tv3 = gxd^2
16. tv2 = tv3^2 # gxd^4
17. tv3 = tv3 * gxd # gxd^3
18. tv3 = tv3 * gx1 # gx1 * gxd^3
19. tv2 = tv2 * tv3 # gx1 * gxd^7
20. y11 = tv2^c4 # (gx1 * gxd^7)^((q - 5) / 8)
21. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((q - 5) / 8)
22. y12 = y11 * c3
23. tv2 = y11^2
24. tv2 = tv2 * gxd
25. e1 = tv2 == gx1
Faz-Hernandez, et al. Expires 17 December 2022 [Page 94]
Internet-Draft hash-to-curve June 2022
26. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt
27. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd
28. y21 = y11 * u
29. y21 = y21 * c2
30. y22 = y21 * c3
31. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1)
32. tv2 = y21^2
33. tv2 = tv2 * gxd
34. e2 = tv2 == gx2
35. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt
36. tv2 = y1^2
37. tv2 = tv2 * gxd
38. e3 = tv2 == gx1
39. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2
40. xn = xn * K
41. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2
42. e4 = sgn0(y) == 1 # Fix sign of y
43. y = CMOV(y, -y, e3 XOR e4)
44. y = y * K
45. return (xn, xd, y, 1)
G.3. Cofactor clearing for BLS12-381 G2
The curve BLS12-381, whose parameters are defined in Section 8.8.2,
admits an efficiently-computable endomorphism psi that can be used to
speed up cofactor clearing for G2 [SBCDK09] [FKR11] [BP17] (see also
Section 7). This section implements the endomorphism psi and a fast
cofactor clearing method described by Budroni and Pintore [BP17].
The functions in this section operate on points whose coordinates are
represented as ratios, i.e., (xn, xd, yn, yd) corresponds to the
point (xn / xd, yn / yd); see Appendix G.1 for further discussion of
projective coordinates. When points are represented in affine
coordinates, one can simply ignore the denominators (xd == 1 and yd
== 1).
The following function computes the Frobenius endomorphism for an
element of F = GF(p^2) with basis (1, I), where I^2 + 1 == 0 in F.
(This is the base field of the elliptic curve E defined in
Section 8.8.2.)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 95]
Internet-Draft hash-to-curve June 2022
frobenius(x)
Input: x, an element of GF(p^2).
Output: a, an element of GF(p^2).
Notation: x = x0 + I * x1, where x0 and x1 are elements of GF(p).
Steps:
1. a = x0 - I * x1
2. return a
The following function computes the endomorphism psi for points on
the elliptic curve E defined in Section 8.8.2.
psi(xn, xd, yn, yd)
Input: P, a point (xn / xd, yn / yd) on the curve E (see above).
Output: Q, a point on the same curve.
Constants:
1. c1 = 1 / (1 + I)^((p - 1) / 3) # in GF(p^2)
2. c2 = 1 / (1 + I)^((p - 1) / 2) # in GF(p^2)
Steps:
1. qxn = c1 * frobenius(xn)
2. qxd = frobenius(xd)
3. qyn = c2 * frobenius(yn)
4. qyd = frobenius(yd)
5. return (qxn, qxd, qyn, qyd)
The following function efficiently computes psi(psi(P)).
psi2(xn, xd, yn, yd)
Input: P, a point (xn / xd, yn / yd) on the curve E (see above).
Output: Q, a point on the same curve.
Constants:
1. c1 = 1 / 2^((p - 1) / 3) # in GF(p^2)
Steps:
1. qxn = c1 * xn
2. qyn = -yn
3. return (qxn, xd, qyn, yd)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 96]
Internet-Draft hash-to-curve June 2022
The following function maps any point on the elliptic curve E
(Section 8.8.2) into the prime-order subgroup G2. This function
returns a point equal to h_eff * P, where h_eff is the parameter
given in Section 8.8.2.
clear_cofactor_bls12381_g2(P)
Input: P, a point (xn / xd, yn / yd) on the curve E (see above).
Output: Q, a point in the subgroup G2 of BLS12-381.
Constants:
1. c1 = -15132376222941642752 # the BLS parameter for BLS12-381
# i.e., -0xd201000000010000
Notation: in this procedure, + and - represent elliptic curve point
addition and subtraction, respectively, and * represents scalar
multiplication.
Steps:
1. t1 = c1 * P
2. t2 = psi(P)
3. t3 = 2 * P
4. t3 = psi2(t3)
5. t3 = t3 - t2
6. t2 = t1 + t2
7. t2 = c1 * t2
8. t3 = t3 + t2
9. t3 = t3 - t1
10. Q = t3 - P
11. return Q
Appendix H. Scripts for parameter generation
This section gives Sage [SAGE] scripts used to generate parameters
for the mappings of Section 6.
H.1. Finding Z for the Shallue-van de Woestijne map
The below function outputs an appropriate Z for the Shallue and van
de Woestijne map (Section 6.6.1).
Faz-Hernandez, et al. Expires 17 December 2022 [Page 97]
Internet-Draft hash-to-curve June 2022
# Arguments:
# - F, a field object, e.g., F = GF(2^521 - 1)
# - A and B, the coefficients of the curve y^2 = x^3 + A * x + B
def find_z_svdw(F, A, B, init_ctr=1):
g = lambda x: F(x)^3 + F(A) * F(x) + F(B)
h = lambda Z: -(F(3) * Z^2 + F(4) * A) / (F(4) * g(Z))
# NOTE: if init_ctr=1 fails to find Z, try setting it to F.gen()
ctr = init_ctr
while True:
for Z_cand in (F(ctr), F(-ctr)):
# Criterion 1:
# g(Z) != 0 in F.
if g(Z_cand) == F(0):
continue
# Criterion 2:
# -(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F.
if h(Z_cand) == F(0):
continue
# Criterion 3:
# -(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F.
if not is_square(h(Z_cand)):
continue
# Criterion 4:
# At least one of g(Z) and g(-Z / 2) is square in F.
if is_square(g(Z_cand)) or is_square(g(-Z_cand / F(2))):
return Z_cand
ctr += 1
H.2. Finding Z for Simplified SWU
The below function outputs an appropriate Z for the Simplified SWU
map (Section 6.6.2).
Faz-Hernandez, et al. Expires 17 December 2022 [Page 98]
Internet-Draft hash-to-curve June 2022
# Arguments:
# - F, a field object, e.g., F = GF(2^521 - 1)
# - A and B, the coefficients of the curve y^2 = x^3 + A * x + B
def find_z_sswu(F, A, B):
R.<xx> = F[] # Polynomial ring over F
g = xx^3 + F(A) * xx + F(B) # y^2 = g(x) = x^3 + A * x + B
ctr = F.gen()
while True:
for Z_cand in (F(ctr), F(-ctr)):
# Criterion 1: Z is non-square in F.
if is_square(Z_cand):
continue
# Criterion 2: Z != -1 in F.
if Z_cand == F(-1):
continue
# Criterion 3: g(x) - Z is irreducible over F.
if not (g - Z_cand).is_irreducible():
continue
# Criterion 4: g(B / (Z * A)) is square in F.
if is_square(g(B / (Z_cand * A))):
return Z_cand
ctr += 1
H.3. Finding Z for Elligator 2
The below function outputs an appropriate Z for the Elligator 2 map
(Section 6.7.1).
# Argument:
# - F, a field object, e.g., F = GF(2^255 - 19)
def find_z_ell2(F):
ctr = F.gen()
while True:
for Z_cand in (F(ctr), F(-ctr)):
# Z must be a non-square in F.
if is_square(Z_cand):
continue
return Z_cand
ctr += 1
Appendix I. sqrt and is_square functions
This section defines special-purpose sqrt functions for the three
most common cases, q = 3 (mod 4), q = 5 (mod 8), and q = 9 (mod 16),
plus a generic constant-time algorithm that works for any prime
modulus.
In addition, it gives an optimized is_square method for GF(p^2).
Faz-Hernandez, et al. Expires 17 December 2022 [Page 99]
Internet-Draft hash-to-curve June 2022
I.1. sqrt for q = 3 (mod 4)
sqrt_3mod4(x)
Parameters:
- F, a finite field of characteristic p and order q = p^m.
Input: x, an element of F.
Output: z, an element of F such that (z^2) == x, if x is square in F.
Constants:
1. c1 = (q + 1) / 4 # Integer arithmetic
Procedure:
1. return x^c1
I.2. sqrt for q = 5 (mod 8)
sqrt_5mod8(x)
Parameters:
- F, a finite field of characteristic p and order q = p^m.
Input: x, an element of F.
Output: z, an element of F such that (z^2) == x, if x is square in F.
Constants:
1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F
2. c2 = (q + 3) / 8 # Integer arithmetic
Procedure:
1. tv1 = x^c2
2. tv2 = tv1 * c1
3. e = (tv1^2) == x
4. z = CMOV(tv2, tv1, e)
5. return z
I.3. sqrt for q = 9 (mod 16)
Faz-Hernandez, et al. Expires 17 December 2022 [Page 100]
Internet-Draft hash-to-curve June 2022
sqrt_9mod16(x)
Parameters:
- F, a finite field of characteristic p and order q = p^m.
Input: x, an element of F.
Output: z, an element of F such that (z^2) == x, if x is square in F.
Constants:
1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F
2. c2 = sqrt(c1) in F, i.e., (c2^2) == c1 in F
3. c3 = sqrt(-c1) in F, i.e., (c3^2) == -c1 in F
4. c4 = (q + 7) / 16 # Integer arithmetic
Procedure:
1. tv1 = x^c4
2. tv2 = c1 * tv1
3. tv3 = c2 * tv1
4. tv4 = c3 * tv1
5. e1 = (tv2^2) == x
6. e2 = (tv3^2) == x
7. tv1 = CMOV(tv1, tv2, e1) # Select tv2 if (tv2^2) == x
8. tv2 = CMOV(tv4, tv3, e2) # Select tv3 if (tv3^2) == x
9. e3 = (tv2^2) == x
10. z = CMOV(tv1, tv2, e3) # Select the sqrt from tv1 and tv2
11. return z
I.4. Constant-time Tonelli-Shanks algorithm
This algorithm is a constant-time version of the classic Tonelli-
Shanks algorithm ([C93], Algorithm 1.5.1) due to Sean Bowe, Jack
Grigg, and Eirik Ogilvie-Wigley [jubjub-fq], adapted and optimized by
Michael Scott.
This algorithm applies to GF(p) for any p. Note, however, that the
special-purpose algorithms given in the prior sections are faster,
when they apply.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 101]
Internet-Draft hash-to-curve June 2022
sqrt_ts_ct(x)
Parameters:
- F, a finite field of characteristic p and order q = p^m.
Input x, an element of F.
Output: z, an element of F such that z^2 == x, if x is square in F.
Constants:
1. c1, the largest integer such that 2^c1 divides q - 1.
2. c2 = (q - 1) / (2^c1) # Integer arithmetic
3. c3 = (c2 - 1) / 2 # Integer arithmetic
4. c4, a non-square value in F
5. c5 = c4^c2 in F
Procedure:
1. z = x^c3
2. t = z * z
3. t = t * x
4. z = z * x
5. b = t
6. c = c5
7. for i in (c1, c1 - 1, ..., 2):
8. for j in (1, 2, ..., i - 2):
9. b = b * b
10. e = b == 1
11. zt = z * c
12. z = CMOV(zt, z, e)
13. c = c * c
14. tt = t * c
15. t = CMOV(tt, t, e)
16. b = t
17. return z
I.5. is_square for F = GF(p^2)
The following is_square method applies to any field F = GF(p^2) with
basis (1, I) represented as described in Section 2.1, i.e., an
element x = (x_1, x_2) = x_1 + x_2 * I.
Other optimizations of this type are possible in other extension
fields; see, e.g., [AR13] for more information.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 102]
Internet-Draft hash-to-curve June 2022
is_square(x)
Parameters:
- F, an extension field of characteristic p and order q = p^2
with basis (1, I).
Input: x, an element of F.
Output: True if x is square in F, and False otherwise.
Constants:
1. c1 = (p - 1) / 2 # Integer arithmetic
Procedure:
1. tv1 = x_1^2
2. tv2 = I * x_2
3. tv2 = tv2^2
4. tv1 = tv1 - tv2
5. tv1 = tv1^c1
6. e1 = tv1 != -1 # Note: -1 in F
7. return e1
Appendix J. Suite test vectors
This section gives test vectors for each suite defined in Section 8.
The test vectors in this section were generated using code that is
available from [hash2curve-repo].
Each test vector in this section lists values computed by the
appropriate encoding function, with variable names defined as in
Section 3. For example, for a suite whose encoding type is random
oracle, the test vector gives the value for msg, u, Q0, Q1, and the
output point P.
J.1. NIST P-256
J.1.1. P256_XMD:SHA-256_SSWU_RO_
suite = P256_XMD:SHA-256_SSWU_RO_
dst = QUUX-V01-CS02-with-P256_XMD:SHA-256_SSWU_RO_
msg =
P.x = 2c15230b26dbc6fc9a37051158c95b79656e17a1a920b11394ca91
c44247d3e4
P.y = 8a7a74985cc5c776cdfe4b1f19884970453912e9d31528c060be9a
b5c43e8415
u[0] = ad5342c66a6dd0ff080df1da0ea1c04b96e0330dd89406465eeba1
1582515009
u[1] = 8c0f1d43204bd6f6ea70ae8013070a1518b43873bcd850aafa0a9e
Faz-Hernandez, et al. Expires 17 December 2022 [Page 103]
Internet-Draft hash-to-curve June 2022
220e2eea5a
Q0.x = ab640a12220d3ff283510ff3f4b1953d09fad35795140b1c5d64f3
13967934d5
Q0.y = dccb558863804a881d4fff3455716c836cef230e5209594ddd33d8
5c565b19b1
Q1.x = 51cce63c50d972a6e51c61334f0f4875c9ac1cd2d3238412f84e31
da7d980ef5
Q1.y = b45d1a36d00ad90e5ec7840a60a4de411917fbe7c82c3949a6e699
e5a1b66aac
msg = abc
P.x = 0bb8b87485551aa43ed54f009230450b492fead5f1cc91658775da
c4a3388a0f
P.y = 5c41b3d0731a27a7b14bc0bf0ccded2d8751f83493404c84a88e71
ffd424212e
u[0] = afe47f2ea2b10465cc26ac403194dfb68b7f5ee865cda61e9f3e07
a537220af1
u[1] = 379a27833b0bfe6f7bdca08e1e83c760bf9a338ab335542704edcd
69ce9e46e0
Q0.x = 5219ad0ddef3cc49b714145e91b2f7de6ce0a7a7dc7406c7726c7e
373c58cb48
Q0.y = 7950144e52d30acbec7b624c203b1996c99617d0b61c2442354301
b191d93ecf
Q1.x = 019b7cb4efcfeaf39f738fe638e31d375ad6837f58a852d032ff60
c69ee3875f
Q1.y = 589a62d2b22357fed5449bc38065b760095ebe6aeac84b01156ee4
252715446e
msg = abcdef0123456789
P.x = 65038ac8f2b1def042a5df0b33b1f4eca6bff7cb0f9c6c15268118
64e544ed80
P.y = cad44d40a656e7aff4002a8de287abc8ae0482b5ae825822bb870d
6df9b56ca3
u[0] = 0fad9d125a9477d55cf9357105b0eb3a5c4259809bf87180aa01d6
51f53d312c
u[1] = b68597377392cd3419d8fcc7d7660948c8403b19ea78bbca4b133c
9d2196c0fb
Q0.x = a17bdf2965eb88074bc01157e644ed409dac97cfcf0c61c998ed0f
a45e79e4a2
Q0.y = 4f1bc80c70d411a3cc1d67aeae6e726f0f311639fee560c7f5a664
554e3c9c2e
Q1.x = 7da48bb67225c1a17d452c983798113f47e438e4202219dd0715f8
419b274d66
Q1.y = b765696b2913e36db3016c47edb99e24b1da30e761a8a3215dc0ec
4d8f96e6f9
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Faz-Hernandez, et al. Expires 17 December 2022 [Page 104]
Internet-Draft hash-to-curve June 2022
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 4be61ee205094282ba8a2042bcb48d88dfbb609301c49aa8b07853
3dc65a0b5d
P.y = 98f8df449a072c4721d241a3b1236d3caccba603f916ca680f4539
d2bfb3c29e
u[0] = 3bbc30446f39a7befad080f4d5f32ed116b9534626993d2cc5033f
6f8d805919
u[1] = 76bb02db019ca9d3c1e02f0c17f8baf617bbdae5c393a81d9ce11e
3be1bf1d33
Q0.x = c76aaa823aeadeb3f356909cb08f97eee46ecb157c1f56699b5efe
bddf0e6398
Q0.y = 776a6f45f528a0e8d289a4be12c4fab80762386ec644abf2bffb9b
627e4352b1
Q1.x = 418ac3d85a5ccc4ea8dec14f750a3a9ec8b85176c95a7022f39182
6794eb5a75
Q1.y = fd6604f69e9d9d2b74b072d14ea13050db72c932815523305cb9e8
07cc900aff
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 457ae2981f70ca85d8e24c308b14db22f3e3862c5ea0f652ca38b5
e49cd64bc5
P.y = ecb9f0eadc9aeed232dabc53235368c1394c78de05dd96893eefa6
2b0f4757dc
u[0] = 4ebc95a6e839b1ae3c63b847798e85cb3c12d3817ec6ebc10af6ee
51adb29fec
u[1] = 4e21af88e22ea80156aff790750121035b3eefaa96b425a8716e0d
20b4e269ee
Q0.x = d88b989ee9d1295df413d4456c5c850b8b2fb0f5402cc5c4c7e815
412e926db8
Q0.y = bb4a1edeff506cf16def96afff41b16fc74f6dbd55c2210e5b8f01
1ba32f4f40
Q1.x = a281e34e628f3a4d2a53fa87ff973537d68ad4fbc28d3be5e8d9f6
a2571c5a4b
Q1.y = f6ed88a7aab56a488100e6f1174fa9810b47db13e86be999644922
961206e184
J.1.2. P256_XMD:SHA-256_SSWU_NU_
Faz-Hernandez, et al. Expires 17 December 2022 [Page 105]
Internet-Draft hash-to-curve June 2022
suite = P256_XMD:SHA-256_SSWU_NU_
dst = QUUX-V01-CS02-with-P256_XMD:SHA-256_SSWU_NU_
msg =
P.x = f871caad25ea3b59c16cf87c1894902f7e7b2c822c3d3f73596c5a
ce8ddd14d1
P.y = 87b9ae23335bee057b99bac1e68588b18b5691af476234b8971bc4
f011ddc99b
u[0] = b22d487045f80e9edcb0ecc8d4bf77833e2bf1f3a54004d7df1d57
f4802d311f
Q.x = f871caad25ea3b59c16cf87c1894902f7e7b2c822c3d3f73596c5a
ce8ddd14d1
Q.y = 87b9ae23335bee057b99bac1e68588b18b5691af476234b8971bc4
f011ddc99b
msg = abc
P.x = fc3f5d734e8dce41ddac49f47dd2b8a57257522a865c124ed02b92
b5237befa4
P.y = fe4d197ecf5a62645b9690599e1d80e82c500b22ac705a0b421fac
7b47157866
u[0] = c7f96eadac763e176629b09ed0c11992225b3a5ae99479760601cb
d69c221e58
Q.x = fc3f5d734e8dce41ddac49f47dd2b8a57257522a865c124ed02b92
b5237befa4
Q.y = fe4d197ecf5a62645b9690599e1d80e82c500b22ac705a0b421fac
7b47157866
msg = abcdef0123456789
P.x = f164c6674a02207e414c257ce759d35eddc7f55be6d7f415e2cc17
7e5d8faa84
P.y = 3aa274881d30db70485368c0467e97da0e73c18c1d00f34775d012
b6fcee7f97
u[0] = 314e8585fa92068b3ea2c3bab452d4257b38be1c097d58a2189045
6c2929614d
Q.x = f164c6674a02207e414c257ce759d35eddc7f55be6d7f415e2cc17
7e5d8faa84
Q.y = 3aa274881d30db70485368c0467e97da0e73c18c1d00f34775d012
b6fcee7f97
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 324532006312be4f162614076460315f7a54a6f85544da773dc659
aca0311853
P.y = 8d8197374bcd52de2acfefc8a54fe2c8d8bebd2a39f16be9b710e4
b1af6ef883
u[0] = 752d8eaa38cd785a799a31d63d99c2ae4261823b4a367b133b2c66
27f48858ab
Faz-Hernandez, et al. Expires 17 December 2022 [Page 106]
Internet-Draft hash-to-curve June 2022
Q.x = 324532006312be4f162614076460315f7a54a6f85544da773dc659
aca0311853
Q.y = 8d8197374bcd52de2acfefc8a54fe2c8d8bebd2a39f16be9b710e4
b1af6ef883
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 5c4bad52f81f39c8e8de1260e9a06d72b8b00a0829a8ea004a610b
0691bea5d9
P.y = c801e7c0782af1f74f24fc385a8555da0582032a3ce038de637ccd
cb16f7ef7b
u[0] = 0e1527840b9df2dfbef966678ff167140f2b27c4dccd884c25014d
ce0e41dfa3
Q.x = 5c4bad52f81f39c8e8de1260e9a06d72b8b00a0829a8ea004a610b
0691bea5d9
Q.y = c801e7c0782af1f74f24fc385a8555da0582032a3ce038de637ccd
cb16f7ef7b
J.2. NIST P-384
J.2.1. P384_XMD:SHA-384_SSWU_RO_
suite = P384_XMD:SHA-384_SSWU_RO_
dst = QUUX-V01-CS02-with-P384_XMD:SHA-384_SSWU_RO_
msg =
P.x = eb9fe1b4f4e14e7140803c1d99d0a93cd823d2b024040f9c067a8e
ca1f5a2eeac9ad604973527a356f3fa3aeff0e4d83
P.y = 0c21708cff382b7f4643c07b105c2eaec2cead93a917d825601e63
c8f21f6abd9abc22c93c2bed6f235954b25048bb1a
u[0] = 25c8d7dc1acd4ee617766693f7f8829396065d1b447eedb155871f
effd9c6653279ac7e5c46edb7010a0e4ff64c9f3b4
u[1] = 59428be4ed69131df59a0c6a8e188d2d4ece3f1b2a3a02602962b4
7efa4d7905945b1e2cc80b36aa35c99451073521ac
Q0.x = e4717e29eef38d862bee4902a7d21b44efb58c464e3e1f0d03894d
94de310f8ffc6de86786dd3e15a1541b18d4eb2846
Q0.y = 6b95a6e639822312298a47526bb77d9cd7bcf76244c991c8cd7007
5e2ee6e8b9a135c4a37e3c0768c7ca871c0ceb53d4
Q1.x = 509527cfc0750eedc53147e6d5f78596c8a3b7360e0608e2fab056
3a1670d58d8ae107c9f04bcf90e89489ace5650efd
Faz-Hernandez, et al. Expires 17 December 2022 [Page 107]
Internet-Draft hash-to-curve June 2022
Internet-Draft MLS October 2021
ExpandWithLabel(Secret, Label, Context, Length) =
KDF.Expand(Secret, KDFLabel, Length)
Where KDFLabel is specified as:
struct {
uint16 length = Length;
opaque label<7..255> = "mls10 " + Label;
opaque context<0..2^32-1> = Context;
} KDFLabel;
DeriveSecret(Secret, Label) =
ExpandWithLabel(Secret, Label, "", KDF.Nh)
The value KDF.Nh is the size of an output from KDF.Extract, in bytes.
In the below diagram:
* KDF.Extract takes its salt argument from the top and its IKM
argument from the left
* DeriveSecret takes its Secret argument from the incoming arrow
* 0 represents an all-zero byte string of length KDF.Nh.
When processing a handshake message, a client combines the following
information to derive new epoch secrets:
* The init secret from the previous epoch
* The commit secret for the current epoch
* The GroupContext object for current epoch
Given these inputs, the derivation of secrets for an epoch proceeds
as shown in the following diagram:
Barnes, et al. Expires 14 April 2022 [Page 34]
Internet-Draft MLS October 2021
init_secret_[n-1]
|
V
commit_secret -> KDF.Extract
|
V
ExpandWithLabel(., "joiner", GroupContext_[n], KDF.Nh)
|
V
joiner_secret
|
V
psk_secret (or 0) -> KDF.Extract
|
+--> DeriveSecret(., "welcome")
| = welcome_secret
|
V
ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh)
|
V
epoch_secret
|
+--> DeriveSecret(., <label>)
| = <secret>
|
V
DeriveSecret(., "init")
|
V
init_secret_[n]
A number of secrets are derived from the epoch secret for different
purposes:
Barnes, et al. Expires 14 April 2022 [Page 35]
Internet-Draft MLS October 2021
+=======================+==================+
| Secret | Label |
+=======================+==================+
| sender_data_secret | "sender data" |
+-----------------------+------------------+
| encryption_secret | "encryption" |
+-----------------------+------------------+
| exporter_secret | "exporter" |
+-----------------------+------------------+
| authentication_secret | "authentication" |
+-----------------------+------------------+
| external_secret | "external" |
+-----------------------+------------------+
| confirmation_key | "confirm" |
+-----------------------+------------------+
| membership_key | "membership" |
+-----------------------+------------------+
| resumption_secret | "resumption" |
+-----------------------+------------------+
Table 2
The "external secret" is used to derive an HPKE key pair whose
private key is held by the entire group:
external_priv, external_pub = KEM.DeriveKeyPair(external_secret)
The public key external_pub can be published as part of the
PublicGroupState struct in order to allow non-members to join the
group using an external commit.
8.1. External Initialization
In addition to initializing a new epoch via KDF invocations as
described above, an MLS group can also initialize a new epoch via an
asymmetric interaction using the external key pair for the previous
epoch. This is done when an new member is joining via an external
commit.
In this process, the joiner sends a new init_secret value to the
group using the HPKE export method. The joiner then uses that
init_secret with information provided in the PublicGroupState and an
external Commit to initialize their copy of the key schedule for the
new epoch.
kem_output, context = SetupBaseS(external_pub, "")
init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)
Barnes, et al. Expires 14 April 2022 [Page 36]
Internet-Draft MLS October 2021
Members of the group receive the kem_output in an ExternalInit
proposal and preform the corresponding calculation to retrieve the
init_secret value.
context = SetupBaseR(kem_output, external_priv, "")
init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)
In both cases, the info input to HPKE is set to the PublicGroupState
for the previous epoch, encoded using the TLS serialization.
8.2. Pre-Shared Keys
Groups which already have an out-of-band mechanism to generate shared
group secrets can inject those into the MLS key schedule to seed the
MLS group secrets computations by this external entropy.
Injecting an external PSK can improve security in the case where
having a full run of updates across members is too expensive, or if
the external group key establishment mechanism provides stronger
security against classical or quantum adversaries.
Note that, as a PSK may have a different lifetime than an update, it
does not necessarily provide the same Forward Secrecy (FS) or Post-
Compromise Security (PCS) guarantees as a Commit message. Unlike the
key pairs populated in the tree by an Update or Commit, which always
freshly generated, PSKs may be pre-distributed and stored. This
creates the risk that a PSK may be compromised in the process of
distribution and storage. The security that the group gets from
injecting a PSK thus depends on both the entropy of the PSK and the
risk of compromise. These factors are outside of the scope of this
document, but should be considered by application designers relying
on PSKs.
Each PSK in MLS has a type that designates how it was provisioned.
External PSKs are provided by the application, while recovery and re-
init PSKs are derived from the MLS key schedule and used in cases
where it is necessary to authenticate a member's participation in a
prior group state. In particular, in addition to external PSK types,
a PSK derived from within MLS may be used in the following cases:
* Re-Initialization: If during the lifetime of a group, the group
members decide to switch to a more secure ciphersuite or newer
protocol version, a PSK can be used to carry entropy from the old
group forward into a new group with the desired parameters.
Barnes, et al. Expires 14 April 2022 [Page 37]
Internet-Draft MLS October 2021
* Branching: A PSK may be used to bootstrap a subset of current
group members into a new group. This applies if a subset of
current group members wish to branch based on the current group
state.
The injection of one or more PSKs into the key schedule is signaled
in two ways: 1) as a PreSharedKey proposal, and 2) in the
GroupSecrets object of a Welcome message sent to new members added in
that epoch.
enum {
reserved(0),
external(1),
reinit(2),
branch(3)
(255)
} PSKType;
struct {
PSKType psktype;
select (PreSharedKeyID.psktype) {
case external:
opaque psk_id<0..255>;
case reinit:
opaque psk_group_id<0..255>;
uint64 psk_epoch;
case branch:
opaque psk_group_id<0..255>;
uint64 psk_epoch;
}
opaque psk_nonce<0..255>;
} PreSharedKeyID;
struct {
PreSharedKeyID psks<0..2^16-1>;
} PreSharedKeys;
On receiving a Commit with a PreSharedKey proposal or a GroupSecrets
object with the psks field set, the receiving Client includes them in
the key schedule in the order listed in the Commit, or in the psks
field respectively. For resumption PSKs, the PSK is defined as the
resumption_secret of the group and epoch specified in the
PreSharedKeyID object. Specifically, psk_secret is computed as
follows:
Barnes, et al. Expires 14 April 2022 [Page 38]
Internet-Draft MLS October 2021
struct {
PreSharedKeyID id;
uint16 index;
uint16 count;
} PSKLabel;
psk_extracted_[i] = KDF.Extract(0, psk_[i])
psk_input_[i] = ExpandWithLabel(psk_extracted_[i], "derived psk", PSKLabel, KDF.Nh)
psk_secret_[0] = 0
psk_secret_[i] = KDF.Extract(psk_input[i-1], psk_secret_[i-1])
psk_secret = psk_secret[n]
Here 0 represents the all-zero vector of length KDF.Nh. The index
field in PSKLabel corresponds to the index of the PSK in the psk
array, while the count field contains the total number of PSKs. In
other words, the PSKs are chained together with KDF.Extract
invocations, as follows:
0 0 = psk_secret_[0]
| |
V V
psk_[0] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[1]
|
0 |
| |
V V
psk_[1] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[1]
|
0 ...
| |
V V
psk_[n] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[n]
In particular, if there are no PreSharedKey proposals in a given
Commit, then the resulting psk_secret is psk_secret_[0], the all-zero
vector.
Barnes, et al. Expires 14 April 2022 [Page 39]
Internet-Draft MLS October 2021
8.3. Secret Tree
For the generation of encryption keys and nonces, the key schedule
begins with the encryption_secret at the root and derives a tree of
secrets with the same structure as the group's ratchet tree. Each
leaf in the Secret Tree is associated with the same group member as
the corresponding leaf in the ratchet tree. Nodes are also assigned
an index according to their position in the array representation of
the tree (described in Appendix A). If N is a node index in the
Secret Tree then left(N) and right(N) denote the children of N (if
they exist).
The secret of any other node in the tree is derived from its parent's
secret using a call to DeriveTreeSecret:
DeriveTreeSecret(Secret, Label, Node, Generation, Length) =
ExpandWithLabel(Secret, Label, TreeContext, Length)
Where TreeContext is specified as:
struct {
uint32 node = Node;
uint32 generation = Generation;
} TreeContext;
If N is a node index in the Secret Tree then the secrets of the
children of N are defined to be:
tree_node_[N]_secret
|
|
+--> DeriveTreeSecret(., "tree", left(N), 0, KDF.Nh)
| = tree_node_[left(N)]_secret
|
+--> DeriveTreeSecret(., "tree", right(N), 0, KDF.Nh)
= tree_node_[right(N)]_secret
The secret in the leaf of the Secret Tree is used to initiate two
symmetric hash ratchets, from which a sequence of single-use keys and
nonces are derived, as described in Section 8.4. The root of each
ratchet is computed as:
Barnes, et al. Expires 14 April 2022 [Page 40]
Internet-Draft MLS October 2021
tree_node_[N]_secret
|
|
+--> DeriveTreeSecret(., "handshake", N, 0, KDF.Nh)
| = handshake_ratchet_secret_[N]_[0]
|
+--> DeriveTreeSecret(., "application", N, 0, KDF.Nh)
= application_ratchet_secret_[N]_[0]
8.4. Encryption Keys
As described in Section 9, MLS encrypts three different types of
information:
* Metadata (sender information)
* Handshake messages (Proposal and Commit)
* Application messages
The sender information used to look up the key for content encryption
is encrypted with an AEAD where the key and nonce are derived from
both sender_data_secret and a sample of the encrypted message
content.
For handshake and application messages, a sequence of keys is derived
via a "sender ratchet". Each sender has their own sender ratchet,
and each step along the ratchet is called a "generation".
A sender ratchet starts from a per-sender base secret derived from a
Secret Tree, as described in Section 8.3. The base secret initiates
a symmetric hash ratchet which generates a sequence of keys and
nonces. The sender uses the j-th key/nonce pair in the sequence to
encrypt (using the AEAD) the j-th message they send during that
epoch. Each key/nonce pair MUST NOT be used to encrypt more than one
message.
Keys, nonces, and the secrets in ratchets are derived using
DeriveTreeSecret. The context in a given call consists of the index
of the sender's leaf in the ratchet tree and the current position in
the ratchet. In particular, the node index of the sender's leaf in
the ratchet tree is the same as the node index of the leaf in the
Secret Tree used to initialize the sender's ratchet.
Barnes, et al. Expires 14 April 2022 [Page 41]
Internet-Draft MLS October 2021
ratchet_secret_[N]_[j]
|
+--> DeriveTreeSecret(., "nonce", N, j, AEAD.Nn)
| = ratchet_nonce_[N]_[j]
|
+--> DeriveTreeSecret(., "key", N, j, AEAD.Nk)
| = ratchet_key_[N]_[j]
|
V
DeriveTreeSecret(., "secret", N, j, KDF.Nh)
= ratchet_secret_[N]_[j+1]
Here, AEAD.Nn and AEAD.Nk denote the lengths in bytes of the nonce
and key for the AEAD scheme defined by the ciphersuite.
8.5. Deletion Schedule
It is important to delete all security-sensitive values as soon as
they are _consumed_. A sensitive value S is said to be _consumed_ if
* S was used to encrypt or (successfully) decrypt a message, or if
* a key, nonce, or secret derived from S has been consumed. (This
goes for values derived via DeriveSecret as well as
ExpandWithLabel.)
Here, S may be the init_secret, commit_secret, epoch_secret,
encryption_secret as well as any secret in a Secret Tree or one of
the ratchets.
As soon as a group member consumes a value they MUST immediately
delete (all representations of) that value. This is crucial to
ensuring forward secrecy for past messages. Members MAY keep
unconsumed values around for some reasonable amount of time to handle
out-of-order message delivery.
For example, suppose a group member encrypts or (successfully)
decrypts an application message using the j-th key and nonce in the
ratchet of node index N in some epoch n. Then, for that member, at
least the following values have been consumed and MUST be deleted:
* the commit_secret, joiner_secret, epoch_secret, encryption_secret
of that epoch n as well as the init_secret of the previous epoch
n-1,
* all node secrets in the Secret Tree on the path from the root to
the leaf with node index N,
Barnes, et al. Expires 14 April 2022 [Page 42]
Internet-Draft MLS October 2021
* the first j secrets in the application data ratchet of node index
N and
* application_ratchet_nonce_[N]_[j] and
application_ratchet_key_[N]_[j].
Concretely, suppose we have the following Secret Tree and ratchet for
participant D:
G
/ \
/ \
E F
/ \ / \
A B C D
/ \
HR0 AR0 -+- K0
| |
| +- N0
|
AR1 -+- K1
| |
| +- N1
|
AR2
Then if a client uses key K1 and nonce N1 during epoch n then it must
consume (at least) values G, F, D, AR0, AR1, K1, N1 as well as the
key schedule secrets used to derive G (the encryption_secret), namely
init_secret of epoch n-1 and commit_secret, joiner_secret,
epoch_secret of epoch n. The client MAY retain (not consume) the
values K0 and N0 to allow for out-of-order delivery, and SHOULD
retain AR2 for processing future messages.
8.6. Exporters
The main MLS key schedule provides an exporter_secret which can be
used by an application as the basis to derive new secrets called
exported_value outside the MLS layer.
MLS-Exporter(Label, Context, key_length) =
ExpandWithLabel(DeriveSecret(exporter_secret, Label),
"exporter", Hash(Context), key_length)
Each application SHOULD provide a unique label to MLS-Exporter that
identifies its use case. This is to prevent two exported outputs
from being generated with the same values and used for different
functionalities.
Barnes, et al. Expires 14 April 2022 [Page 43]
Internet-Draft MLS October 2021
The exported values are bound to the group epoch from which the
exporter_secret is derived, hence reflects a particular state of the
group.
It is RECOMMENDED for the application generating exported values to
refresh those values after a Commit is processed.
8.7. Resumption Secret
The main MLS key schedule provides a resumption_secret which can
provide extra security in some cross-group operations.
The application SHOULD specify an upper limit on the number of past
epochs for which the resumption_secret may be stored.
There are two ways in which a resumption_secret can be used: to re-
initialize the group with different parameters, or to create a sub-
group of an existing group as detailed in Section 8.2.
Resumption keys are distinguished from exporter keys in that they
have specific use inside the MLS protocol, whereas the use of
exporter secrets may be decided by an external application. They are
thus derived separately to avoid key material reuse.
8.8. State Authentication Keys
The main MLS key schedule provides a per-epoch authentication_secret.
If one of the parties is being actively impersonated by an attacker,
their authentication_secret will differ from that of the other group
members. Thus, members of a group MAY use their
authentication_secrets within an out-of-band authentication protocol
to ensure that they share the same view of the group.
9. Message Framing
Handshake and application messages use a common framing structure.
This framing provides encryption to ensure confidentiality within the
group, as well as signing to authenticate the sender within the
group.
Barnes, et al. Expires 14 April 2022 [Page 44]
Internet-Draft MLS October 2021
The two main structures involved are MLSPlaintext and MLSCiphertext.
MLSCiphertext represents a signed and encrypted message, with
protections for both the content of the message and related metadata.
MLSPlaintext represents a message that is only signed, and not
encrypted. Applications MUST use MLSCiphertext to encrypt
application messages and SHOULD use MLSCiphertext to encode handshake
messages, but MAY transmit handshake messages encoded as MLSPlaintext
objects in cases where it is necessary for the Delivery Service to
examine such messages.
enum {
reserved(0),
application(1),
proposal(2),
commit(3),
(255)
} ContentType;
enum {
reserved(0),
member(1),
preconfigured(2),
new_member(3),
(255)
} SenderType;
struct {
SenderType sender_type;
switch (sender_type) {
case member: KeyPackageID member;
case preconfigured: opaque external_key_id<0..255>;
case new_member: struct{};
}
} Sender;
struct {
opaque mac_value<0..255>;
} MAC;
enum {
reserved(0),
mls_plaintext(1),
mls_ciphertext(2),
(255)
} WireFormat;
struct {
WireFormat wire_format;
Barnes, et al. Expires 14 April 2022 [Page 45]
Internet-Draft MLS October 2021
opaque group_id<0..255>;
uint64 epoch;
Sender sender;
opaque authenticated_data<0..2^32-1>;
ContentType content_type;
select (MLSPlaintext.content_type) {
case application:
opaque application_data<0..2^32-1>;
case proposal:
Proposal proposal;
case commit:
Commit commit;
}
opaque signature<0..2^16-1>;
optional<MAC> confirmation_tag;
optional<MAC> membership_tag;
} MLSPlaintext;
struct {
WireFormat wire_format = mls_ciphertext;
opaque group_id<0..255>;
uint64 epoch;
ContentType content_type;
opaque authenticated_data<0..2^32-1>;
opaque encrypted_sender_data<0..255>;
opaque ciphertext<0..2^32-1>;
} MLSCiphertext;
The field confirmation_tag MUST be present if content_type equals
commit. Otherwise, it MUST NOT be present.
External sender types are sent as MLSPlaintext, see Section 11.1.9
for their use.
The remainder of this section describes how to compute the signature
of an MLSPlaintext object and how to convert it to an MLSCiphertext
object for member sender types. The steps are:
* Set group_id, epoch, content_type and authenticated_data fields
from the MLSPlaintext object directly
* Identify the key and key generation depending on the content type
Barnes, et al. Expires 14 April 2022 [Page 46]
Internet-Draft MLS October 2021
* Encrypt an MLSCiphertextContent for the ciphertext field using the
key identified and MLSPlaintext object
* Encrypt the sender data using a key and nonce derived from the
sender_data_secret for the epoch and a sample of the encrypted
MLSCiphertextContent.
Decryption is done by decrypting the sender data, then the message,
and then verifying the content signature.
The following sections describe the encryption and signing processes
in detail.
9.1. Content Authentication
The signature field in an MLSPlaintext object is computed using the
signing private key corresponding to the public key, which was
authenticated by the credential at the leaf of the tree indicated by
the sender field. The signature covers the plaintext metadata and
message content, which is all of MLSPlaintext except for the
signature, the confirmation_tag and membership_tag fields. If the
sender is a member of the group, the signature also covers the
GroupContext for the current epoch, so that signatures are specific
to a given group and epoch.
Barnes, et al. Expires 14 April 2022 [Page 47]
Internet-Draft MLS October 2021
struct {
select (MLSPlaintextTBS.sender.sender_type) {
case member:
GroupContext context;
case preconfigured:
case new_member:
struct{};
}
WireFormat wire_format;
opaque group_id<0..255>;
uint64 epoch;
Sender sender;
opaque authenticated_data<0..2^32-1>;
ContentType content_type;
select (MLSPlaintextTBS.content_type) {
case application:
opaque application_data<0..2^32-1>;
case proposal:
Proposal proposal;
case commit:
Commit commit;
}
} MLSPlaintextTBS;
The membership_tag field in the MLSPlaintext object authenticates the
sender's membership in the group. For an MLSPlaintext with a sender
type other than member, this field MUST be omitted. For messages
sent by members, it MUST be present and set to the following value:
struct {
MLSPlaintextTBS tbs;
opaque signature<0..2^16-1>;
optional<MAC> confirmation_tag;
} MLSPlaintextTBM;
membership_tag = MAC(membership_key, MLSPlaintextTBM);
Note that the membership_tag only needs to be computed for
MLSPlaintext messages that will be sent over the wire (wire_format ==
mls_plaintext). It isn't needed for messages that will be encrypted
and transmitted as MLSCiphertext messages (wire_format ==
mls_ciphertext).
Barnes, et al. Expires 14 April 2022 [Page 48]
Internet-Draft MLS October 2021Q1.y = 33337b13cb35e173fdea4cb9e8cce915d836ff57803dbbeb7998aa
49d17df2ff09b67031773039d09fbd9305a1566bc4
msg = abc
P.x = e02fc1a5f44a7519419dd314e29863f30df55a514da2d655775a81
d413003c4d4e7fd59af0826dfaad4200ac6f60abe1
P.y = 01f638d04d98677d65bef99aef1a12a70a4cbb9270ec55248c0453
0d8bc1f8f90f8a6a859a7c1f1ddccedf8f96d675f6
u[0] = 53350214cb6bef0b51abb791b1c4209a2b4c16a0c67e1ab1401017
fad774cd3b3f9a8bcdf7f6229dd8dd5a075cb149a0
u[1] = c0473083898f63e03f26f14877a2407bd60c75ad491e7d26cbc6cc
5ce815654075ec6b6898c7a41d74ceaf720a10c02e
Q0.x = fc853b69437aee9a19d5acf96a4ee4c5e04cf7b53406dfaa2afbdd
7ad2351b7f554e4bbc6f5db4177d4d44f933a8f6ee
Q0.y = 7e042547e01834c9043b10f3a8221c4a879cb156f04f72bfccab0c
047a304e30f2aa8b2e260d34c4592c0c33dd0c6482
Q1.x = 57912293709b3556b43a2dfb137a315d256d573b82ded120ef8c78
2d607c05d930d958e50cb6dc1cc480b9afc38c45f1
Q1.y = de9387dab0eef0bda219c6f168a92645a84665c4f2137c14270fb4
24b7532ff84843c3da383ceea24c47fa343c227bb8
msg = abcdef0123456789
P.x = bdecc1c1d870624965f19505be50459d363c71a699a496ab672f9a
5d6b78676400926fbceee6fcd1780fe86e62b2aa89
P.y = 57cf1f99b5ee00f3c201139b3bfe4dd30a653193778d89a0accc5e
0f47e46e4e4b85a0595da29c9494c1814acafe183c
u[0] = aab7fb87238cf6b2ab56cdcca7e028959bb2ea599d34f68484139d
de85ec6548a6e48771d17956421bdb7790598ea52e
u[1] = 26e8d833552d7844d167833ca5a87c35bcfaa5a0d86023479fb28e
5cd6075c18b168bf1f5d2a0ea146d057971336d8d1
Q0.x = 0ceece45b73f89844671df962ad2932122e878ad2259e650626924
e4e7f132589341dec1480ebcbbbe3509d11fb570b7
Q0.y = fafd71a3115298f6be4ae5c6dfc96c400cfb55760f185b7b03f3fa
45f3f91eb65d27628b3c705cafd0466fafa54883ce
Q1.x = dea1be8d3f9be4cbf4fab9d71d549dde76875b5d9b876832313a08
3ec81e528cbc2a0a1d0596b3bcb0ba77866b129776
Q1.y = eb15fe71662214fb03b65541f40d3eb0f4cf5c3b559f647da138c9
f9b7484c48a08760e02c16f1992762cb7298fa52cf
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 03c3a9f401b78c6c36a52f07eeee0ec1289f178adf78448f43a385
0e0456f5dd7f7633dd31676d990eda32882ab486c0
P.y = cc183d0d7bdfd0a3af05f50e16a3f2de4abbc523215bf57c848d5e
a662482b8c1f43dc453a93b94a8026db58f3f5d878
u[0] = 04c00051b0de6e726d228c85bf243bf5f4789efb512b22b498cde3
821db9da667199b74bd5a09a79583c6d353a3bb41c
Faz-Hernandez, et al. Expires 17 December 2022 [Page 108]
Internet-Draft hash-to-curve June 2022
u[1] = 97580f218255f899f9204db64cd15e6a312cb4d8182375d1e5157c
8f80f41d6a1a4b77fb1ded9dce56c32058b8d5202b
Q0.x = 051a22105e0817a35d66196338c8d85bd52690d79bba373ead8a86
dd9899411513bb9f75273f6483395a7847fb21edb4
Q0.y = f168295c1bbcff5f8b01248e9dbc885335d6d6a04aea960f7384f7
46ba6502ce477e624151cc1d1392b00df0f5400c06
Q1.x = 6ad7bc8ed8b841efd8ad0765c8a23d0b968ec9aa360a558ff33500
f164faa02bee6c704f5f91507c4c5aad2b0dc5b943
Q1.y = 47313cc0a873ade774048338fc34ca5313f96bbf6ae22ac6ef475d
85f03d24792dc6afba8d0b4a70170c1b4f0f716629
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 7b18d210b1f090ac701f65f606f6ca18fb8d081e3bc6cbd937c560
4325f1cdea4c15c10a54ef303aabf2ea58bd9947a4
P.y = ea857285a33abb516732915c353c75c576bf82ccc96adb63c094dd
e580021eddeafd91f8c0bfee6f636528f3d0c47fd2
u[0] = 480cb3ac2c389db7f9dac9c396d2647ae946db844598971c26d1af
d53912a1491199c0a5902811e4b809c26fcd37a014
u[1] = d28435eb34680e148bf3908536e42231cba9e1f73ae2c6902a222a
89db5c49c97db2f8fa4d4cd6e424b17ac60bdb9bb6
Q0.x = 42e6666f505e854187186bad3011598d9278b9d6e3e4d2503c3d23
6381a56748dec5d139c223129b324df53fa147c4df
Q0.y = 8ee51dbda46413bf621838cc935d18d617881c6f33f3838a79c767
a1e5618e34b22f79142df708d2432f75c7366c8512
Q1.x = 4ff01ceeba60484fa1bc0d825fe1e5e383d8f79f1e5bb78e5fb26b
7a7ef758153e31e78b9d60ce75c5e32e43869d4e12
Q1.y = 0f84b978fac8ceda7304b47e229d6037d32062e597dc7a9b95bcd9
af441f3c56c619a901d21635f9ec6ab4710b9fcd0e
J.2.2. P384_XMD:SHA-384_SSWU_NU_
suite = P384_XMD:SHA-384_SSWU_NU_
dst = QUUX-V01-CS02-with-P384_XMD:SHA-384_SSWU_NU_
msg =
P.x = de5a893c83061b2d7ce6a0d8b049f0326f2ada4b966dc7e7292725
6b033ef61058029a3bfb13c1c7ececd6641881ae20
P.y = 63f46da6139785674da315c1947e06e9a0867f5608cf24724eb379
3a1f5b3809ee28eb21a0c64be3be169afc6cdb38ca
Faz-Hernandez, et al. Expires 17 December 2022 [Page 109]
Internet-Draft hash-to-curve June 2022
u[0] = bc7dc1b2cdc5d588a66de3276b0f24310d4aca4977efda7d6272e1
be25187b001493d267dc53b56183c9e28282368e60
Q.x = de5a893c83061b2d7ce6a0d8b049f0326f2ada4b966dc7e7292725
6b033ef61058029a3bfb13c1c7ececd6641881ae20
Q.y = 63f46da6139785674da315c1947e06e9a0867f5608cf24724eb379
3a1f5b3809ee28eb21a0c64be3be169afc6cdb38ca
msg = abc
P.x = 1f08108b87e703c86c872ab3eb198a19f2b708237ac4be53d7929f
b4bd5194583f40d052f32df66afe5249c9915d139b
P.y = 1369dc8d5bf038032336b989994874a2270adadb67a7fcc32f0f88
24bc5118613f0ac8de04a1041d90ff8a5ad555f96c
u[0] = 9de6cf41e6e41c03e4a7784ac5c885b4d1e49d6de390b3cdd5a1ac
5dd8c40afb3dfd7bb2686923bab644134483fc1926
Q.x = 1f08108b87e703c86c872ab3eb198a19f2b708237ac4be53d7929f
b4bd5194583f40d052f32df66afe5249c9915d139b
Q.y = 1369dc8d5bf038032336b989994874a2270adadb67a7fcc32f0f88
24bc5118613f0ac8de04a1041d90ff8a5ad555f96c
msg = abcdef0123456789
P.x = 4dac31ec8a82ee3c02ba2d7c9fa431f1e59ffe65bf977b948c59e1
d813c2d7963c7be81aa6db39e78ff315a10115c0d0
P.y = 845333cdb5702ad5c525e603f302904d6fc84879f0ef2ee2014a6b
13edd39131bfd66f7bd7cdc2d9ccf778f0c8892c3f
u[0] = 84e2d430a5e2543573e58e368af41821ca3ccc97baba7e9aab51a8
4543d5a0298638a22ceee6090d9d642921112af5b7
Q.x = 4dac31ec8a82ee3c02ba2d7c9fa431f1e59ffe65bf977b948c59e1
d813c2d7963c7be81aa6db39e78ff315a10115c0d0
Q.y = 845333cdb5702ad5c525e603f302904d6fc84879f0ef2ee2014a6b
13edd39131bfd66f7bd7cdc2d9ccf778f0c8892c3f
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 13c1f8c52a492183f7c28e379b0475486718a7e3ac1dfef39283b9
ce5fb02b73f70c6c1f3dfe0c286b03e2af1af12d1d
P.y = 57e101887e73e40eab8963324ed16c177d55eb89f804ec9df06801
579820420b5546b579008df2145fd770f584a1a54c
u[0] = 504e4d5a529333b9205acaa283107bd1bffde753898f7744161f7d
d19ba57fbb6a64214a2e00ddd2613d76cd508ddb30
Q.x = 13c1f8c52a492183f7c28e379b0475486718a7e3ac1dfef39283b9
ce5fb02b73f70c6c1f3dfe0c286b03e2af1af12d1d
Q.y = 57e101887e73e40eab8963324ed16c177d55eb89f804ec9df06801
579820420b5546b579008df2145fd770f584a1a54c
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 110]
Internet-Draft hash-to-curve June 2022
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = af129727a4207a8cb9e9dce656d88f79fce25edbcea350499d65e9
bf1204537bdde73c7cefb752a6ed5ebcd44e183302
P.y = ce68a3d5e161b2e6a968e4ddaa9e51504ad1516ec170c7eef3ca6b
5327943eca95d90b23b009ba45f58b72906f2a99e2
u[0] = 7b01ce9b8c5a60d9fbc202d6dde92822e46915d8c17e03fcb92ece
1ed6074d01e149fc9236def40d673de903c1d4c166
Q.x = af129727a4207a8cb9e9dce656d88f79fce25edbcea350499d65e9
bf1204537bdde73c7cefb752a6ed5ebcd44e183302
Q.y = ce68a3d5e161b2e6a968e4ddaa9e51504ad1516ec170c7eef3ca6b
5327943eca95d90b23b009ba45f58b72906f2a99e2
J.3. NIST P-521
J.3.1. P521_XMD:SHA-512_SSWU_RO_
suite = P521_XMD:SHA-512_SSWU_RO_
dst = QUUX-V01-CS02-with-P521_XMD:SHA-512_SSWU_RO_
msg =
P.x = 00fd767cebb2452030358d0e9cf907f525f50920c8f607889a6a35
680727f64f4d66b161fafeb2654bea0d35086bec0a10b30b14adef
3556ed9f7f1bc23cecc9c088
P.y = 0169ba78d8d851e930680322596e39c78f4fe31b97e57629ef6460
ddd68f8763fd7bd767a4e94a80d3d21a3c2ee98347e024fc73ee1c
27166dc3fe5eeef782be411d
u[0] = 01e5f09974e5724f25286763f00ce76238c7a6e03dc396600350ee
2c4135fb17dc555be99a4a4bae0fd303d4f66d984ed7b6a3ba3860
93752a855d26d559d69e7e9e
u[1] = 00ae593b42ca2ef93ac488e9e09a5fe5a2f6fb330d18913734ff60
2f2a761fcaaf5f596e790bcc572c9140ec03f6cccc38f767f1c197
5a0b4d70b392d95a0c7278aa
Q0.x = 00b70ae99b6339fffac19cb9bfde2098b84f75e50ac1e80d6acb95
4e4534af5f0e9c4a5b8a9c10317b8e6421574bae2b133b4f2b8c6c
e4b3063da1d91d34fa2b3a3c
Q0.y = 007f368d98a4ddbf381fb354de40e44b19e43bb11a1278759f4ea7
b485e1b6db33e750507c071250e3e443c1aaed61f2c28541bb54b1
b456843eda1eb15ec2a9b36e
Q1.x = 01143d0e9cddcdacd6a9aafe1bcf8d218c0afc45d4451239e821f5
d2a56df92be942660b532b2aa59a9c635ae6b30e803c45a6ac8714
32452e685d661cd41cf67214
Q1.y = 00ff75515df265e996d702a5380defffab1a6d2bc232234c7bcffa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 111]
Internet-Draft hash-to-curve June 2022
433cd8aa791fbc8dcf667f08818bffa739ae25773b32073213cae9
a0f2a917a0b1301a242dda0c
msg = abc
P.x = 002f89a1677b28054b50d15e1f81ed6669b5a2158211118ebdef8a
6efc77f8ccaa528f698214e4340155abc1fa08f8f613ef14a04371
7503d57e267d57155cf784a4
P.y = 010e0be5dc8e753da8ce51091908b72396d3deed14ae166f66d8eb
f0a4e7059ead169ea4bead0232e9b700dd380b316e9361cfdba55a
08c73545563a80966ecbb86d
u[0] = 003d00c37e95f19f358adeeaa47288ec39998039c3256e13c2a4c0
0a7cb61a34c8969472960150a27276f2390eb5e53e47ab193351c2
d2d9f164a85c6a5696d94fe8
u[1] = 01f3cbd3df3893a45a2f1fecdac4d525eb16f345b03e2820d69bc5
80f5cbe9cb89196fdf720ef933c4c0361fcfe29940fd0db0a5da6b
afb0bee8876b589c41365f15
Q0.x = 01b254e1c99c835836f0aceebba7d77750c48366ecb07fb658e4f5
b76e229ae6ca5d271bb0006ffcc42324e15a6d3daae587f9049de2
dbb0494378ffb60279406f56
Q0.y = 01845f4af72fc2b1a5a2fe966f6a97298614288b456cfc385a425b
686048b25c952fbb5674057e1eb055d04568c0679a8e2dda3158dc
16ac598dbb1d006f5ad915b0
Q1.x = 007f08e813c620e527c961b717ffc74aac7afccb9158cebc347d57
15d5c2214f952c97e194f11d114d80d3481ed766ac0a3dba3eb73f
6ff9ccb9304ad10bbd7b4a36
Q1.y = 0022468f92041f9970a7cc025d71d5b647f822784d29ca7b3bc3b0
829d6bb8581e745f8d0cc9dc6279d0450e779ac2275c4c3608064a
d6779108a7828ebd9954caeb
msg = abcdef0123456789
P.x = 006e200e276a4a81760099677814d7f8794a4a5f3658442de63c18
d2244dcc957c645e94cb0754f95fcf103b2aeaf94411847c24187b
89fb7462ad3679066337cbc4
P.y = 001dd8dfa9775b60b1614f6f169089d8140d4b3e4012949b52f98d
b2deff3e1d97bf73a1fa4d437d1dcdf39b6360cc518d8ebcc0f899
018206fded7617b654f6b168
u[0] = 00183ee1a9bbdc37181b09ec336bcaa34095f91ef14b66b1485c16
6720523dfb81d5c470d44afcb52a87b704dbc5c9bc9d0ef524dec2
9884a4795f55c1359945baf3
u[1] = 00504064fd137f06c81a7cf0f84aa7e92b6b3d56c2368f0a08f447
76aa8930480da1582d01d7f52df31dca35ee0a7876500ece3d8fe0
293cd285f790c9881c998d5e
Q0.x = 0021482e8622aac14da60e656043f79a6a110cbae5012268a62dd6
a152c41594549f373910ebed170ade892dd5a19f5d687fae7095a4
61d583f8c4295f7aaf8cd7da
Q0.y = 0177e2d8c6356b7de06e0b5712d8387d529b848748e54a8bc0ef5f
1475aa569f8f492fa85c3ad1c5edc51faf7911f11359bfa2a12d2e
f0bd73df9cb5abd1b101c8b1
Faz-Hernandez, et al. Expires 17 December 2022 [Page 112]
Internet-Draft hash-to-curve June 2022
Q1.x = 00abeafb16fdbb5eb95095678d5a65c1f293291dfd20a3751dbe05
d0a9bfe2d2eef19449fe59ec32cdd4a4adc3411177c0f2dffd0159
438706159a1bbd0567d9b3d0
Q1.y = 007cc657f847db9db651d91c801741060d63dab4056d0a1d3524e2
eb0e819954d8f677aa353bd056244a88f00017e00c3ce8beeedb43
82d83d74418bd48930c6c182
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 01b264a630bd6555be537b000b99a06761a9325c53322b65bdc41b
f196711f9708d58d34b3b90faf12640c27b91c70a507998e559406
48caa8e71098bf2bc8d24664
P.y = 01ea9f445bee198b3ee4c812dcf7b0f91e0881f0251aab272a1220
1fd89b1a95733fd2a699c162b639e9acdcc54fdc2f6536129b6beb
0432be01aa8da02df5e59aaa
u[0] = 0159871e222689aad7694dc4c3480a49807b1eedd9c8cb4ae1b219
d5ba51655ea5b38e2e4f56b36bf3e3da44a7b139849d28f598c816
fe1bc7ed15893b22f63363c3
u[1] = 004ef0cffd475152f3858c0a8ccbdf7902d8261da92744e98df9b7
fadb0a5502f29c5086e76e2cf498f47321434a40b1504911552ce4
4ad7356a04e08729ad9411f5
Q0.x = 0005eac7b0b81e38727efcab1e375f6779aea949c3e409b53a1d37
aa2acbac87a7e6ad24aafbf3c52f82f7f0e21b872e88c55e17b7fa
21ce08a94ea2121c42c2eb73
Q0.y = 00a173b6a53a7420dbd61d4a21a7c0a52de7a5c6ce05f31403bef7
47d16cc8604a039a73bdd6e114340e55dacd6bea8e217ffbadfb8c
292afa3e1b2afc839a6ce7bb
Q1.x = 01881e3c193a69e4d88d8180a6879b74782a0bc7e529233e9f84bf
7f17d2f319c36920ffba26f9e57a1e045cc7822c834c239593b6e1
42a694aa00c757b0db79e5e8
Q1.y = 01558b16d396d866e476e001f2dd0758927655450b84e12f154032
c7c2a6db837942cd9f44b814f79b4d729996ced61eec61d85c6751
39cbffe3fbf071d2c21cfecb
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 00c12bc3e28db07b6b4d2a2b1167ab9e26fc2fa85c7b0498a17b03
47edf52392856d7e28b8fa7a2dd004611159505835b687ecf1a764
857e27e9745848c436ef3925
Faz-Hernandez, et al. Expires 17 December 2022 [Page 113]
Internet-Draft hash-to-curve June 2022
P.y = 01cd287df9a50c22a9231beb452346720bb163344a41c5f5a24e83
35b6ccc595fd436aea89737b1281aecb411eb835f0b939073fdd1d
d4d5a2492e91ef4a3c55bcbd
u[0] = 0033d06d17bc3b9a3efc081a05d65805a14a3050a0dd4dfb488461
8eb5c73980a59c5a246b18f58ad022dd3630faa22889fbb8ba1593
466515e6ab4aeb7381c26334
u[1] = 0092290ab99c3fea1a5b8fb2ca49f859994a04faee3301cefab312
d34227f6a2d0c3322cf76861c6a3683bdaa2dd2a6daa5d6906c663
e065338b2344d20e313f1114
Q0.x = 00041f6eb92af8777260718e4c22328a7d74203350c6c8f5794d99
d5789766698f459b83d5068276716f01429934e40af3d1111a2278
0b1e07e72238d2207e5386be
Q0.y = 001c712f0182813942b87cab8e72337db017126f52ed797dd23458
4ac9ae7e80dfe7abea11db02cf1855312eae1447dbaecc9d7e8c88
0a5e76a39f6258074e1bc2e0
Q1.x = 0125c0b69bcf55eab49280b14f707883405028e05c927cd7625d4e
04115bd0e0e6323b12f5d43d0d6d2eff16dbcf244542f84ec05891
1260dc3bb6512ab5db285fbd
Q1.y = 008bddfb803b3f4c761458eb5f8a0aee3e1f7f68e9d7424405fa69
172919899317fb6ac1d6903a432d967d14e0f80af63e7035aaae0c
123e56862ce969456f99f102
J.3.2. P521_XMD:SHA-512_SSWU_NU_
suite = P521_XMD:SHA-512_SSWU_NU_
dst = QUUX-V01-CS02-with-P521_XMD:SHA-512_SSWU_NU_
msg =
P.x = 01ec604b4e1e3e4c7449b7a41e366e876655538acf51fd40d08b97
be066f7d020634e906b1b6942f9174b417027c953d75fb6ec64b8c
ee2a3672d4f1987d13974705
P.y = 00944fc439b4aad2463e5c9cfa0b0707af3c9a42e37c5a57bb4ecd
12fef9fb21508568aedcdd8d2490472df4bbafd79081c81e99f4da
3286eddf19be47e9c4cf0e91
u[0] = 01e4947fe62a4e47792cee2798912f672fff820b2556282d9843b4
b465940d7683a986f93ccb0e9a191fbc09a6e770a564490d2a4ae5
1b287ca39f69c3d910ba6a4f
Q.x = 01ec604b4e1e3e4c7449b7a41e366e876655538acf51fd40d08b97
be066f7d020634e906b1b6942f9174b417027c953d75fb6ec64b8c
ee2a3672d4f1987d13974705
Q.y = 00944fc439b4aad2463e5c9cfa0b0707af3c9a42e37c5a57bb4ecd
12fef9fb21508568aedcdd8d2490472df4bbafd79081c81e99f4da
3286eddf19be47e9c4cf0e91
msg = abc
P.x = 00c720ab56aa5a7a4c07a7732a0a4e1b909e32d063ae1b58db5f0e
b5e09f08a9884bff55a2bef4668f715788e692c18c1915cd034a6b
998311fcf46924ce66a2be9a
Faz-Hernandez, et al. Expires 17 December 2022 [Page 114]
Internet-Draft hash-to-curve June 2022
P.y = 003570e87f91a4f3c7a56be2cb2a078ffc153862a53d5e03e5dad5
bccc6c529b8bab0b7dbb157499e1949e4edab21cf5d10b782bc1e9
45e13d7421ad8121dbc72b1d
u[0] = 0019b85ef78596efc84783d42799e80d787591fe7432dee1d9fa2b
7651891321be732ddf653fa8fefa34d86fb728db569d36b5b6ed39
83945854b2fc2dc6a75aa25b
Q.x = 00c720ab56aa5a7a4c07a7732a0a4e1b909e32d063ae1b58db5f0e
b5e09f08a9884bff55a2bef4668f715788e692c18c1915cd034a6b
998311fcf46924ce66a2be9a
Q.y = 003570e87f91a4f3c7a56be2cb2a078ffc153862a53d5e03e5dad5
bccc6c529b8bab0b7dbb157499e1949e4edab21cf5d10b782bc1e9
45e13d7421ad8121dbc72b1d
msg = abcdef0123456789
P.x = 00bcaf32a968ff7971b3bbd9ce8edfbee1309e2019d7ff373c3838
7a782b005dce6ceffccfeda5c6511c8f7f312f343f3a891029c585
8f45ee0bf370aba25fc990cc
P.y = 00923517e767532d82cb8a0b59705eec2b7779ce05f9181c7d5d5e
25694ef8ebd4696343f0bc27006834d2517215ecf79482a84111f5
0c1bae25044fe1dd77744bbd
u[0] = 01dba0d7fa26a562ee8a9014ebc2cca4d66fd9de036176aca8fc11
ef254cd1bc208847ab7701dbca7af328b3f601b11a1737a899575a
5c14f4dca5aaca45e9935e07
Q.x = 00bcaf32a968ff7971b3bbd9ce8edfbee1309e2019d7ff373c3838
7a782b005dce6ceffccfeda5c6511c8f7f312f343f3a891029c585
8f45ee0bf370aba25fc990cc
Q.y = 00923517e767532d82cb8a0b59705eec2b7779ce05f9181c7d5d5e
25694ef8ebd4696343f0bc27006834d2517215ecf79482a84111f5
0c1bae25044fe1dd77744bbd
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 001ac69014869b6c4ad7aa8c443c255439d36b0e48a0f57b03d6fe
9c40a66b4e2eaed2a93390679a5cc44b3a91862b34b673f0e92c83
187da02bf3db967d867ce748
P.y = 00d5603d530e4d62b30fccfa1d90c2206654d74291c1db1c25b86a
051ee3fffc294e5d56f2e776853406bd09206c63d40f37ad882952
4cf89ad70b5d6e0b4a3b7341
u[0] = 00844da980675e1244cb209dcf3ea0aabec23bd54b2cda69fff86e
b3acc318bf3d01bae96e9cd6f4c5ceb5539df9a7ad7fcc5e9d5469
6081ba9782f3a0f6d14987e3
Q.x = 001ac69014869b6c4ad7aa8c443c255439d36b0e48a0f57b03d6fe
9c40a66b4e2eaed2a93390679a5cc44b3a91862b34b673f0e92c83
187da02bf3db967d867ce748
Q.y = 00d5603d530e4d62b30fccfa1d90c2206654d74291c1db1c25b86a
051ee3fffc294e5d56f2e776853406bd09206c63d40f37ad882952
4cf89ad70b5d6e0b4a3b7341
Faz-Hernandez, et al. Expires 17 December 2022 [Page 115]
Internet-Draft hash-to-curve June 2022
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 01801de044c517a80443d2bd4f503a9e6866750d2f94a22970f62d
721f96e4310e4a828206d9cdeaa8f2d476705cc3bbc490a6165c68
7668f15ec178a17e3d27349b
P.y = 0068889ea2e1442245fe42bfda9e58266828c0263119f35a61631a
3358330f3bb84443fcb54fcd53a1d097fccbe310489b74ee143fc2
938959a83a1f7dd4a6fd395b
u[0] = 01aab1fb7e5cd44ba4d9f32353a383cb1bb9eb763ed40b32bdd5f6
66988970205998c0e44af6e2b5f6f8e48e969b3f649cae3c6ab463
e1b274d968d91c02f00cce91
Q.x = 01801de044c517a80443d2bd4f503a9e6866750d2f94a22970f62d
721f96e4310e4a828206d9cdeaa8f2d476705cc3bbc490a6165c68
7668f15ec178a17e3d27349b
Q.y = 0068889ea2e1442245fe42bfda9e58266828c0263119f35a61631a
3358330f3bb84443fcb54fcd53a1d097fccbe310489b74ee143fc2
938959a83a1f7dd4a6fd395b
J.4. curve25519
J.4.1. curve25519_XMD:SHA-512_ELL2_RO_
suite = curve25519_XMD:SHA-512_ELL2_RO_
dst = QUUX-V01-CS02-with-curve25519_XMD:SHA-512_ELL2_RO_
msg =
P.x = 2de3780abb67e861289f5749d16d3e217ffa722192d16bbd9d1bfb
9d112b98c0
P.y = 3b5dc2a498941a1033d176567d457845637554a2fe7a3507d21abd
1c1bd6e878
u[0] = 005fe8a7b8fef0a16c105e6cadf5a6740b3365e18692a9c05bfbb4
d97f645a6a
u[1] = 1347edbec6a2b5d8c02e058819819bee177077c9d10a4ce165aab0
fd0252261a
Q0.x = 36b4df0c864c64707cbf6cf36e9ee2c09a6cb93b28313c169be295
61bb904f98
Q0.y = 6cd59d664fb58c66c892883cd0eb792e52055284dac3907dd756b4
5d15c3983d
Q1.x = 3fa114783a505c0b2b2fbeef0102853c0b494e7757f2a089d0daae
7ed9a0db2b
Faz-Hernandez, et al. Expires 17 December 2022 [Page 116]
Internet-Draft hash-to-curve June 2022
Q1.y = 76c0fe7fec932aaafb8eefb42d9cbb32eb931158f469ff3050af15
cfdbbeff94
msg = abc
P.x = 2b4419f1f2d48f5872de692b0aca72cc7b0a60915dd70bde432e82
6b6abc526d
P.y = 1b8235f255a268f0a6fa8763e97eb3d22d149343d495da1160eff9
703f2d07dd
u[0] = 49bed021c7a3748f09fa8cdfcac044089f7829d3531066ac9e74e0
994e05bc7d
u[1] = 5c36525b663e63389d886105cee7ed712325d5a97e60e140aba7e2
ce5ae851b6
Q0.x = 16b3d86e056b7970fa00165f6f48d90b619ad618791661b7b5e1ec
78be10eac1
Q0.y = 4ab256422d84c5120b278cbdfc4e1facc5baadffeccecf8ee9bf39
46106d50ca
Q1.x = 7ec29ddbf34539c40adfa98fcb39ec36368f47f30e8f888cc7e86f
4d46e0c264
Q1.y = 10d1abc1cae2d34c06e247f2141ba897657fb39f1080d54f09ce0a
f128067c74
msg = abcdef0123456789
P.x = 68ca1ea5a6acf4e9956daa101709b1eee6c1bb0df1de3b90d46023
82a104c036
P.y = 2a375b656207123d10766e68b938b1812a4a6625ff83cb8d5e86f5
8a4be08353
u[0] = 6412b7485ba26d3d1b6c290a8e1435b2959f03721874939b21782d
f17323d160
u[1] = 24c7b46c1c6d9a21d32f5707be1380ab82db1054fde82865d5c9e3
d968f287b2
Q0.x = 71de3dadfe268872326c35ac512164850860567aea0e7325e6b91a
98f86533ad
Q0.y = 26a08b6e9a18084c56f2147bf515414b9b63f1522e1b6c5649f7d4
b0324296ec
Q1.x = 5704069021f61e41779e2ba6b932268316d6d2a6f064f997a22fef
16d1eaeaca
Q1.y = 50483c7540f64fb4497619c050f2c7fe55454ec0f0e79870bb4430
2e34232210
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 096e9c8bae6c06b554c1ee69383bb0e82267e064236b3a30608d4e
d20b73ac5a
P.y = 1eb5a62612cafb32b16c3329794645b5b948d9f8ffe501d4e26b07
3fef6de355
u[0] = 5e123990f11bbb5586613ffabdb58d47f64bb5f2fa115f8ea8df01
88e0c9e1b5
Faz-Hernandez, et al. Expires 17 December 2022 [Page 117]
9.2. Content Encryption
The ciphertext field of the MLSCiphertext object is produced by
supplying the inputs described below to the AEAD function specified
by the ciphersuite in use. The plaintext input contains the content
and signature of the MLSPlaintext, plus optional padding. These
values are encoded in the following form:
struct {
select (MLSCiphertext.content_type) {
case application:
opaque application_data<0..2^32-1>;
case proposal:
Proposal proposal;
case commit:
Commit commit;
}
opaque signature<0..2^16-1>;
optional<MAC> confirmation_tag;
opaque padding<0..2^16-1>;
} MLSCiphertextContent;
In the MLS key schedule, the sender creates two distinct key ratchets
for handshake and application messages for each member of the group.
When encrypting a message, the sender looks at the ratchets it
derived for its own member and chooses an unused generation from
either the handshake or application ratchet depending on the content
type of the message. This generation of the ratchet is used to
derive a provisional nonce and key.
Before use in the encryption operation, the nonce is XORed with a
fresh random value to guard against reuse. Because the key schedule
generates nonces deterministically, a client must keep persistent
state as to where in the key schedule it is; if this persistent state
is lost or corrupted, a client might reuse a generation that has
already been used, causing reuse of a key/nonce pair.
To avoid this situation, the sender of a message MUST generate a
fresh random 4-byte "reuse guard" value and XOR it with the first
four bytes of the nonce from the key schedule before using the nonce
for encryption. The sender MUST include the reuse guard in the
reuse_guard field of the sender data object, so that the recipient of
the message can use it to compute the nonce to be used for
decryption.
Barnes, et al. Expires 14 April 2022 [Page 49]
Internet-Draft MLS October 2021
+-+-+-+-+---------...---+
| Key Schedule Nonce |
+-+-+-+-+---------...---+
XOR
+-+-+-+-+---------...---+
| Guard | 0 |
+-+-+-+-+---------...---+
===
+-+-+-+-+---------...---+
| Encrypt/Decrypt Nonce |
+-+-+-+-+---------...---+
The Additional Authenticated Data (AAD) input to the encryption
contains an object of the following form, with the values used to
identify the key and nonce:
struct {
opaque group_id<0..255>;
uint64 epoch;
ContentType content_type;
opaque authenticated_data<0..2^32-1>;
} MLSCiphertextContentAAD;
9.3. Sender Data Encryption
The "sender data" used to look up the key for the content encryption
is encrypted with the ciphersuite's AEAD with a key and nonce derived
from both the sender_data_secret and a sample of the encrypted
content. Before being encrypted, the sender data is encoded as an
object of the following form:
struct {
KeyPackageID sender;
uint32 generation;
opaque reuse_guard[4];
} MLSSenderData;
MLSSenderData.sender is assumed to be a member sender type. When
constructing an MLSSenderData from a Sender object, the sender MUST
verify Sender.sender_type is member and use Sender.sender for
MLSSenderData.sender.
The reuse_guard field contains a fresh random value used to avoid
nonce reuse in the case of state loss or corruption, as described in
Section 9.2.
Barnes, et al. Expires 14 April 2022 [Page 50]
Internet-Draft MLS October 2021
The key and nonce provided to the AEAD are computed as the KDF of the
first KDF.Nh bytes of the ciphertext generated in the previous
section. If the length of the ciphertext is less than KDF.Nh, the
whole ciphertext is used without padding. In pseudocode, the key and
nonce are derived as:
ciphertext_sample = ciphertext[0..KDF.Nh-1]
sender_data_key = ExpandWithLabel(sender_data_secret, "key", ciphertext_sample, AEAD.Nk)
sender_data_nonce = ExpandWithLabel(sender_data_secret, "nonce", ciphertext_sample, AEAD.Nn)
The Additional Authenticated Data (AAD) for the SenderData ciphertext
is all the fields of MLSCiphertext excluding encrypted_sender_data:
struct {
opaque group_id<0..255>;
uint64 epoch;
ContentType content_type;
} MLSSenderDataAAD;
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the KeyPackageID indicated in the sender
field identifies a member of the group.
10. Group Creation
A group is always created with a single member, the "creator". The
other members are added when the creator effectively sends itself an
Add proposal and commits it, then sends the corresponding Welcome
message to the new participants. These processes are described in
detail in Section 11.1.1, Section 11.2, and Section 11.2.2.
The creator of a group MUST take the following steps to initialize
the group:
* Fetch KeyPackages for the members to be added, and select a
version and ciphersuite according to the capabilities of the
members. To protect against downgrade attacks, the creator MUST
use the capabilities extensions in these KeyPackages to verify
that the chosen version and ciphersuite is the best option
supported by all members.
* Initialize a one-member group with the following initial values:
- Ratchet tree: A tree with a single node, a leaf containing an
HPKE public key and credential for the creator
- Group ID: A value set by the creator
Barnes, et al. Expires 14 April 2022 [Page 51]
Internet-Draft MLS October 2021
- Epoch: 0
- Tree hash: The root hash of the above ratchet tree
- Confirmed transcript hash: The zero-length octet string
- Interim transcript hash: The zero-length octet string
- Init secret: A fresh random value of size KDF.Nh
- Extensions: Any values of the creator's choosing
* For each member, construct an Add proposal from the KeyPackage for
that member (see Section 11.1.1)
* Construct a Commit message that commits all of the Add proposals,
in any order chosen by the creator (see Section 11.2)
* Process the Commit message to obtain a new group state (for the
epoch in which the new members are added) and a Welcome message
* Transmit the Welcome message to the other new members
The recipient of a Welcome message processes it as described in
Section 11.2.2.
In principle, the above process could be streamlined by having the
creator directly create a tree and choose a random value for first
epoch's epoch secret. We follow the steps above because it removes
unnecessary choices, by which, for example, bad randomness could be
introduced. The only choices the creator makes here are its own
KeyPackage, the leaf secret from which the Commit is built, and the
intermediate key pairs along the direct path to the root.
10.1. Required Capabilities
The configuration of a group imposes certain requirements on clients
in the group. At a minimum, all members of the group need to support
the ciphersuite and protocol version in use. Additional requirements
can be imposed by including a required_capabilities extension in the
GroupContext.
struct {
ExtensionType extensions<0..255>;
ProposalType proposals<0..255>;
} RequiredCapabilities;
Barnes, et al. Expires 14 April 2022 [Page 52]
Internet-Draft MLS October 2021
This extension lists the extensions and proposal types that must be
supported by all members of the group. For new members, it is
enforced by existing members during the application of Add commits.
Existing members should of course be in compliance already. In order
to ensure this continues to be the case even as the group's
extensions can be updated, a GroupContextExtensions proposal is
invalid if it contains a required_capabilities extension that
requires capabililities not supported by all current members.
10.2. Linking a New Group to an Existing Group
A new group may be tied to an already existing group for the purpose
of re-initializing the existing group, or to branch into a sub-group.
Re-initializing an existing group may be used, for example, to
restart the group with a different ciphersuite or protocol version.
Branching may be used to bootstrap a new group consisting of a subset
of current group members, based on the current group state.
In both cases, the psk_nonce included in the PreSharedKeyID object
must be a randomly sampled nonce of length KDF.Nh to avoid key re-
use.
10.2.1. Sub-group Branching
If a client wants to create a subgroup of an existing group, they MAY
choose to include a PreSharedKeyID in the GroupSecrets object of the
Welcome message choosing the psktype branch, the group_id of the
group from which a subgroup is to be branched, as well as an epoch
within the number of epochs for which a resumption_secret is kept.
11. Group Evolution
Over the lifetime of a group, its membership can change, and existing
members might want to change their keys in order to achieve post-
compromise security. In MLS, each such change is accomplished by a
two-step process:
1. A proposal to make the change is broadcast to the group in a
Proposal message
2. A member of the group or a new member broadcasts a Commit message
that causes one or more proposed changes to enter into effect
Barnes, et al. Expires 14 April 2022 [Page 53]
Internet-Draft MLS October 2021
The group thus evolves from one cryptographic state to another each
time a Commit message is sent and processed. These states are
referred to as "epochs" and are uniquely identified among states of
the group by eight-octet epoch values. When a new group is
initialized, its initial state epoch is 0x0000000000000000. Each
time a state transition occurs, the epoch number is incremented by
one.
11.1. Proposals
Proposals are included in an MLSPlaintext by way of a Proposal
structure that indicates their type:
// See IANA registry for registered values
uint16 ProposalType;
struct {
ProposalType msg_type;
select (Proposal.msg_type) {
case add: Add;
case update: Update;
case remove: Remove;
case psk: PreSharedKey;
case reinit: ReInit;
case external_init: ExternalInit;
case app_ack: AppAck;
case group_context_extensions: GroupContextExtensions;
};
} Proposal;
On receiving an MLSPlaintext containing a Proposal, a client MUST
verify the signature on the enclosing MLSPlaintext. If the signature
verifies successfully, then the Proposal should be cached in such a
way that it can be retrieved by hash (as a ProposalOrRef object) in a
later Commit message.
11.1.1. Add
An Add proposal requests that a client with a specified KeyPackage be
added to the group. The proposer of the Add MUST validate the
KeyPackage in the same way as receipients are required to do below.
struct {
KeyPackage key_package;
} Add;
Barnes, et al. Expires 14 April 2022 [Page 54]
Internet-Draft MLS October 2021
The proposer of the Add does not control where in the group's ratchet
tree the new member is added. Instead, the sender of the Commit
message chooses a location for each added member and states it in the
Commit message.
An Add is applied after being included in a Commit message. The
position of the Add in the list of proposals determines the node
index index of the leaf node where the new member will be added. For
the first Add in the Commit, index is the leftmost empty leaf in the
tree, for the second Add, the next empty leaf to the right, etc.
* Validate the KeyPackage:
- Verify that the signature on the KeyPackage is valid using the
public key in the KeyPackage's credential
- Verify that the following fields in the KeyPackage are unique
among the members of the group (including any other members
added in the same Commit):
o (credential.identity, endpoint_id) tuple
o credential.signature_key
o hpke_init_key
- Verify that the KeyPackage is compatible with the group's
parameters. The ciphersuite and protocol version of the
KeyPackage must match those in use in the group. If the
GroupContext has a required_capabilities extension, then the
required extensions and proposals MUST be listed in the
KeyPackage&
Internet-Draft hash-to-curve June 2022
u[1] = 5e8553eb00438a0bb1e7faa59dec6d8087f9c8011e5fb8ed9df31c
b6c0d4ac19
Q0.x = 7a94d45a198fb5daa381f45f2619ab279744efdd8bd8ed587fc5b6
5d6cea1df0
Q0.y = 67d44f85d376e64bb7d713585230cdbfafc8e2676f7568e0b6ee59
361116a6e1
Q1.x = 30506fb7a32136694abd61b6113770270debe593027a968a01f271
e146e60c18
Q1.y = 7eeee0e706b40c6b5174e551426a67f975ad5a977ee2f01e8e20a6
d612458c3b
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 1bc61845a138e912f047b5e70ba9606ba2a447a4dade024c8ef3dd
42b7bbc5fe
P.y = 623d05e47b70e25f7f1d51dda6d7c23c9a18ce015fe3548df596ea
9e38c69bf1
u[0] = 20f481e85da7a3bf60ac0fb11ed1d0558fc6f941b3ac5469aa8b56
ec883d6d7d
u[1] = 017d57fd257e9a78913999a23b52ca988157a81b09c5442501d07f
ed20869465
Q0.x = 02d606e2699b918ee36f2818f2bc5013e437e673c9f9b9cdc15fd0
c5ee913970
Q0.y = 29e9dc92297231ef211245db9e31767996c5625dfbf92e1c8107ef
887365de1e
Q1.x = 38920e9b988d1ab7449c0fa9a6058192c0c797bb3d42ac34572434
1a1aa98745
Q1.y = 24dcc1be7c4d591d307e89049fd2ed30aae8911245a9d8554bf603
2e5aa40d3d
J.4.2. curve25519_XMD:SHA-512_ELL2_NU_
suite = curve25519_XMD:SHA-512_ELL2_NU_
dst = QUUX-V01-CS02-with-curve25519_XMD:SHA-512_ELL2_NU_
msg =
P.x = 1bb913f0c9daefa0b3375378ffa534bda5526c97391952a7789eb9
76edfe4d08
P.y = 4548368f4f983243e747b62a600840ae7c1dab5c723991f85d3a97
68479f3ec4
Faz-Hernandez, et al. Expires 17 December 2022 [Page 118]
Internet-Draft hash-to-curve June 2022
u[0] = 608d892b641f0328523802a6603427c26e55e6f27e71a91a478148
d45b5093cd
Q.x = 51125222da5e763d97f3c10fcc92ea6860b9ccbbd2eb1285728f56
6721c1e65b
Q.y = 343d2204f812d3dfc5304a5808c6c0d81a903a5d228b342442aa3c
9ba5520a3d
msg = abc
P.x = 7c22950b7d900fa866334262fcaea47a441a578df43b894b4625c9
b450f9a026
P.y = 5547bc00e4c09685dcbc6cb6765288b386d8bdcb595fa5a6e3969e
08097f0541
u[0] = 46f5b22494bfeaa7f232cc8d054be68561af50230234d7d1d63d1d
9abeca8da5
Q.x = 7d56d1e08cb0ccb92baf069c18c49bb5a0dcd927eff8dcf75ca921
ef7f3e6eeb
Q.y = 404d9a7dc25c9c05c44ab9a94590e7c3fe2dcec74533a0b24b188a
5d5dacf429
msg = abcdef0123456789
P.x = 31ad08a8b0deeb2a4d8b0206ca25f567ab4e042746f792f4b7973f
3ae2096c52
P.y = 405070c28e78b4fa269427c82827261991b9718bd6c6e95d627d70
1a53c30db1
u[0] = 235fe40c443766ce7e18111c33862d66c3b33267efa50d50f9e8e5
d252a40aaa
Q.x = 3fbe66b9c9883d79e8407150e7c2a1c8680bee496c62fabe4619a7
2b3cabe90f
Q.y = 08ec476147c9a0a3ff312d303dbbd076abb7551e5fce82b48ab14b
433f8d0a7b
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 027877759d155b1997d0d84683a313eb78bdb493271d935b622900
459d52ceaa
P.y = 54d691731a53baa30707f4a87121d5169fb5d587d70fb0292b5830
dedbec4c18
u[0] = 001e92a544463bda9bd04ddbe3d6eed248f82de32f522669efc5dd
ce95f46f5b
Q.x = 227e0bb89de700385d19ec40e857db6e6a3e634b1c32962f370d26
f84ff19683
Q.y = 5f86ff3851d262727326a32c1bf7655a03665830fa7f1b8b1e5a09
d85bc66e4a
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 119]
Internet-Draft hash-to-curve June 2022
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 5fd892c0958d1a75f54c3182a18d286efab784e774d1e017ba2fb2
52998b5dc1
P.y = 750af3c66101737423a4519ac792fb93337bd74ee751f19da4cf1e
94f4d6d0b8
u[0] = 1a68a1af9f663592291af987203393f707305c7bac9c8d63d6a729
bdc553dc19
Q.x = 3bcd651ee54d5f7b6013898aab251ee8ecc0688166fce6e9548d38
472f6bd196
Q.y = 1bb36ad9197299f111b4ef21271c41f4b7ecf5543db8bb5931307e
bdb2eaa465
J.5. edwards25519
J.5.1. edwards25519_XMD:SHA-512_ELL2_RO_
suite = edwards25519_XMD:SHA-512_ELL2_RO_
dst = QUUX-V01-CS02-with-edwards25519_XMD:SHA-512_ELL2_RO_
msg =
P.x = 3c3da6925a3c3c268448dcabb47ccde5439559d9599646a8260e47
b1e4822fc6
P.y = 09a6c8561a0b22bef63124c588ce4c62ea83a3c899763af26d7953
02e115dc21
u[0] = 03fef4813c8cb5f98c6eef88fae174e6e7d5380de2b007799ac7ee
712d203f3a
u[1] = 780bdddd137290c8f589dc687795aafae35f6b674668d92bf92ae7
93e6a60c75
Q0.x = 6549118f65bb617b9e8b438decedc73c496eaed496806d3b2eb9ee
60b88e09a7
Q0.y = 7315bcc8cf47ed68048d22bad602c6680b3382a08c7c5d3f439a97
3fb4cf9feb
Q1.x = 31dcfc5c58aa1bee6e760bf78cbe71c2bead8cebb2e397ece0f37a
3da19c9ed2
Q1.y = 7876d81474828d8a5928b50c82420b2bd0898d819e9550c5c82c39
fc9bafa196
msg = abc
P.x = 608040b42285cc0d72cbb3985c6b04c935370c7361f4b7fbdb1ae7
f8c1a8ecad
P.y = 1a8395b88338f22e435bbd301183e7f20a5f9de643f11882fb237f
88268a5531
Faz-Hernandez, et al. Expires 17 December 2022 [Page 120]
Internet-Draft hash-to-curve June 2022
u[0] = 5081955c4141e4e7d02ec0e36becffaa1934df4d7a270f70679c78
f9bd57c227
u[1] = 005bdc17a9b378b6272573a31b04361f21c371b256252ae5463119
aa0b925b76
Q0.x = 5c1525bd5d4b4e034512949d187c39d48e8cd84242aa4758956e4a
dc7d445573
Q0.y = 2bf426cf7122d1a90abc7f2d108befc2ef415ce8c2d09695a74072
40faa01f29
Q1.x = 37b03bba828860c6b459ddad476c83e0f9285787a269df2156219b
7e5c86210c
Q1.y = 285ebf5412f84d0ad7bb4e136729a9ffd2195d5b8e73c0dc85110c
e06958f432
msg = abcdef0123456789
P.x = 6d7fabf47a2dc03fe7d47f7dddd21082c5fb8f86743cd020f3fb14
7d57161472
P.y = 53060a3d140e7fbcda641ed3cf42c88a75411e648a1add71217f70
ea8ec561a6
u[0] = 285ebaa3be701b79871bcb6e225ecc9b0b32dff2d60424b4c50642
636a78d5b3
u[1] = 2e253e6a0ef658fedb8e4bd6a62d1544fd6547922acb3598ec6b36
9760b81b31
Q0.x = 3ac463dd7fddb773b069c5b2b01c0f6b340638f54ee3bd92d452fc
ec3015b52d
Q0.y = 7b03ba1e8db9ec0b390d5c90168a6a0b7107156c994c674b61fe69
6cbeb46baf
Q1.x = 0757e7e904f5e86d2d2f4acf7e01c63827fde2d363985aa7432106
f1b3a444ec
Q1.y = 50026c96930a24961e9d86aa91ea1465398ff8e42015e2ec1fa397
d416f6a1c0
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 5fb0b92acedd16f3bcb0ef83f5c7b7a9466b5f1e0d8d217421878e
a3686f8524
P.y = 2eca15e355fcfa39d2982f67ddb0eea138e2994f5956ed37b7f72e
ea5e89d2f7
u[0] = 4fedd25431c41f2a606952e2945ef5e3ac905a42cf64b8b4d4a83c
533bf321af
u[1] = 02f20716a5801b843987097a8276b6d869295b2e11253751ca72c1
09d37485a9
Q0.x = 703e69787ea7524541933edf41f94010a201cc841c1cce60205ec3
8513458872
Q0.y = 32bb192c4f89106466f0874f5fd56a0d6b6f101cb714777983336c
159a9bec75
Q1.x = 0c9077c5c31720ed9413abe59bf49ce768506128d810cb882435aa
90f713ef6b
Faz-Hernandez, et al. Expires 17 December 2022 [Page 121]
Internet-Draft hash-to-curve June 2022
Q1.y = 7d5aec5210db638c53f050597964b74d6dda4be5b54fa73041bf90
9ccb3826cb
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 0efcfde5898a839b00997fbe40d2ebe950bc81181afbd5cd6b9618
aa336c1e8c
P.y = 6dc2fc04f266c5c27f236a80b14f92ccd051ef1ff027f26a07f8c0
f327d8f995
u[0] = 6e34e04a5106e9bd59f64aba49601bf09d23b27f7b594e56d5de06
df4a4ea33b
u[1] = 1c1c2cb59fc053f44b86c5d5eb8c1954b64976d0302d3729ff66e8
4068f5fd96
Q0.x = 21091b2e3f9258c7dfa075e7ae513325a94a3d8a28e1b1cb3b5b6f
5d65675592
Q0.y = 41a33d324c89f570e0682cdf7bdb78852295daf8084c669f2cc969
2896ab5026
Q1.x = 4c07ec48c373e39a23bd7954f9e9b66eeab9e5ee1279b867b3d531
5aa815454f
Q1.y = 67ccac7c3cb8d1381242d8d6585c57eabaddbb5dca5243a68a8aeb
5477d94b3a
J.5.2. edwards25519_XMD:SHA-512_ELL2_NU_
suite = edwards25519_XMD:SHA-512_ELL2_NU_
dst = QUUX-V01-CS02-with-edwards25519_XMD:SHA-512_ELL2_NU_
msg =
P.x = 1ff2b70ecf862799e11b7ae744e3489aa058ce805dd323a936375a
84695e76da
P.y = 222e314d04a4d5725e9f2aff9fb2a6b69ef375a1214eb19021ceab
2d687f0f9b
u[0] = 7f3e7fb9428103ad7f52db32f9df32505d7b427d894c5093f7a0f0
374a30641d
Q.x = 42836f691d05211ebc65ef8fcf01e0fb6328ec9c4737c26050471e
50803022eb
Q.y = 22cb4aaa555e23bd460262d2130d6a3c9207aa8bbb85060928beb2
63d6d42a95
msg = abc
Faz-Hernandez, et al. Expires 17 December 2022 [Page 122]
Internet-Draft hash-to-curve June 2022
P.x = 5f13cc69c891d86927eb37bd4afc6672360007c63f68a33ab423a3
aa040fd2a8
P.y = 67732d50f9a26f73111dd1ed5dba225614e538599db58ba30aaea1
f5c827fa42
u[0] = 09cfa30ad79bd59456594a0f5d3a76f6b71c6787b04de98be5cd20
1a556e253b
Q.x = 333e41b61c6dd43af220c1ac34a3663e1cf537f996bab50ab66e33
c4bd8e4e19
Q.y = 51b6f178eb08c4a782c820e306b82c6e273ab22e258d972cd0c511
787b2a3443
msg = abcdef0123456789
P.x = 1dd2fefce934ecfd7aae6ec998de088d7dd03316aa1847198aecf6
99ba6613f1
P.y = 2f8a6c24dd1adde73909cada6a4a137577b0f179d336685c4a955a
0a8e1a86fb
u[0] = 475ccff99225ef90d78cc9338e9f6a6bb7b17607c0c4428937de75
d33edba941
Q.x = 55186c242c78e7d0ec5b6c9553f04c6aeef64e69ec2e824472394d
a32647cfc6
Q.y = 5b9ea3c265ee42256a8f724f616307ef38496ef7eba391c08f99f3
bea6fa88f0
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 35fbdc5143e8a97afd3096f2b843e07df72e15bfca2eaf6879bf97
c5d3362f73
P.y = 2af6ff6ef5ebba128b0774f4296cb4c2279a074658b083b8dcca91
f57a603450
u[0] = 049a1c8bd51bcb2aec339f387d1ff51428b88d0763a91bcdf69298
14ac95d03d
Q.x = 024b6e1621606dca8071aa97b43dce4040ca78284f2a527dcf5d0f
bfac2b07e7
Q.y = 5102353883d739bdc9f8a3af650342b171217167dcce34f8db5720
8ec1dfdbf2
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 6e5e1f37e99345887fc12111575fc1c3e36df4b289b8759d23af14
Faz-Hernandez, et al. Expires 17 December 2022 [Page 123]
Internet-Draft hash-to-curve June 2022
d774b66bff
P.y = 2c90c3d39eb18ff291d33441b35f3262cdd307162cc97c31bfcc7a
4245891a37
u[0] = 3cb0178a8137cefa5b79a3a57c858d7eeeaa787b2781be4a362a2f
0750d24fa0
Q.x = 3e6368cff6e88a58e250c54bd27d2c989ae9b3acb6067f2651ad28
2ab8c21cd9
Q.y = 38fb39f1566ca118ae6c7af42810c0bb9767ae5960abb5a8ca7925
30bfb9447d
J.6. curve448
J.6.1. curve448_XOF:SHAKE256_ELL2_RO_
suite = curve448_XOF:SHAKE256_ELL2_RO_
dst = QUUX-V01-CS02-with-curve448_XOF:SHAKE256_ELL2_RO_
msg =
P.x = 5ea5ff623d27c75e73717514134e73e419f831a875ca9e82915fdf
c7069d0a9f8b532cfb32b1d8dd04ddeedbe3fa1d0d681c01e825d6
a9ea
P.y = afadd8de789f8f8e3516efbbe313a7eba364c939ecba00dabf4ced
5c563b18e70a284c17d8f46b564c4e6ce11784a3825d9411166221
28c1
u[0] = c704c7b3d3b36614cf3eedd0324fe6fe7d1402c50efd16cff89ff6
3f50938506280d3843478c08e24f7842f4e3ef45f6e3c4897f9d97
6148
u[1] = c25427dc97fff7a5ad0a78654e2c6c27b1c1127b5b53c7950cd1fd
6edd2703646b25f341e73deedfebf022d1d3cecd02b93b4d585ead
3ed7
Q0.x = 3ba318806f89c19cc019f51e33eb6b8c038dab892e858ce7c7f2c2
ac58618d06146a5fef31e49af49588d4d3db1bcf02bd4e4a733e37
065d
Q0.y = b30b4cfc2fd14d9d4b70456c0f5c6f6070be551788893d570e7955
675a20f6c286d01d6e90d2fb500d2efb8f4e18db7f8268bb9b7fbc
5975
Q1.x = f03a48cf003f63be61ca055fec87c750434da07a15f8aa6210389f
f85943b5166484339c8bea1af9fc571313d35ed2fbb779408b760c
4cbd
Q1.y = 23943a33b2954dc54b76a8222faf5b7e18405a41f5ecc61bf1b8df
1f9cbfad057307ed0c7b721f19c0390b8ee3a2dec223671f9ff905
fda7
msg = abc
P.x = 9b2f7ce34878d7cebf34c582db14958308ea09366d1ec71f646411
d3de0ae564d082b06f40cd30dfc08d9fb7cb21df390cf207806ad9
d0e4
P.y = 138a0eef0a4993ea696152ed7db61f7ddb4e8100573591e7466d61
Faz-Hernandez, et al. Expires 17 December 2022 [Page 124]
Internet-Draft hash-to-curve June 2022
c0c568ecaec939e36a84d276f34c402526d8989a96e99760c4869e
d633
u[0] = 2dd95593dfee26fe0d218d3d9a0a23d9e1a262fd1d0b602483d084
15213e75e2db3c69b0a5bc89e71bcefc8c723d2b6a0cf263f02ad2
aa70
u[1] = 272e4c79a1290cc6d2bc4f4f9d31bf7fbe956ca303c04518f117d7
7c0e9d850796fc3e1e2bcb9c75e8eaaded5e150333cae993186804
7c9d
Q0.x = 26714783887ec444fbade9ae350dc13e8d5a64150679232560726a
73d36e28bd56766d7d0b0899d79c8d1c889ae333f601c57532ff3c
4f09
Q0.y = 080e486f8f5740dbbe82305160cab9fac247b0b22a54d961de6750
37c3036fa68464c8756478c322ae0aeb9ba386fe626cebb0bcca46
840c
Q1.x = 0d9741d10421691a8ebc7778b5f623260fdf8b28ae28d776efcb8e
0d5fbb65139a2f828617835f527cb2ca24a8f5fc8e84378343c43d
096d
Q1.y = 54f4c499bf3d5b154511913f9615bd914969b65cfb74508d7ae5a1
69e9595b7cbcab9a1485e07b2ce426e4fbed052f03842c4313b7db
e39a
msg = abcdef0123456789
P.x = f54ecd14b85a50eeeee0618452df3a75be7bfba11da5118774ae4e
a55ac204e153f77285d780c4acee6c96abe3577a0c0b00be6e790c
f194
P.y = 935247a64bf78c107069943c7e3ecc52acb27ce4a3230407c83573
41685ea2152e8c3da93f8cd77da1bddb5bb759c6e7ae7d516dced4
2850
u[0] = 6aab71a38391639f27e49eae8b1cb6b7172a1f478190ece293957e
7cdb2391e7cc1c4261970d9c1bbf9c3915438f74fbd7eb5cd4d4d1
7ace
u[1] = c80b8380ca47a3bcbf76caa75cef0e09f3d270d5ee8f676cde11ae
df41aaca6741bd81a86232bd336ccb42efad39f06542bc06a67b65
909e
Q0.x = 946d91bd50c90ef70743e0dd194bddd68bb630f4e67e5b93e15a9b
94e62cb85134467993501759525c1f4fdbf06f10ddaf817847d735
e062
Q0.y = 185cf511262ec1e9b3c3cbdc015ab93df4e71cbe87766917d81c9f
3419d480407c1462385122c84982d4dae60c3ae4acce0089e37ad6
5934
Q1.x = 01778f4797b717cd6f83c193b2dfb92a1606a36ede941b0f6ab0ac
71ad0eac756d17604bf054398887da907e41065d3595f178ae802f
2087
Q1.y = b4ca727d0bda895e0eee7eb3cbc28710fa2e90a73b568cae26bd7c
2e73b70a9fa0affe1096f0810198890ed65d8935886b6e60dc4c56
9dc6
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Faz-Hernandez, et al. Expires 17 December 2022 [Page 125]
Internet-Draft hash-to-curve June 2022
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 5bd67c4f88adf6beb10f7e0d0054659776a55c97b809ec8b310172
9e104fd0f684e103792f267fd87cc4afc25a073956ef4f268fb028
24d5
P.y = da1f5cb16a352719e4cb064cf47ba72aeba7752d03e8ca2c56229f
419b4ef378785a5af1a53dd7ab4d467c1f92f7b139b3752faf29c9
6432
u[0] = cb5c27e51f9c18ee8ffdb6be230f4eb4f2c2481963b2293484f08d
a2241c1ff59f80978e6defe9d70e34abba2fcbe12dc3a1eb2c5d3d
2e4a
u[1] = c895e8afecec5466e126fa70fc4aa784b8009063afb10e3ee06a9b
22318256aa8693b0c85b955cf2d6540b8ed71e729af1b8d5ca3b11
6cd7
Q0.x = c2d275826d6ad55e41a22318f6b6240f1f862a2e231120ff41eadb
ec319756032e8cef2a7ac6c10214fa0608c17fcaf61ec2694a8a2b
358b
Q0.y = 93d2e092762b135509840e609d413200df800d99da91d8b8284066
6cac30e7a3520adbaa4b089bfdc86132e42729f651d022f4782502
f12c
Q1.x = 3c0880ece7244036e9a45944a85599f9809d772f770cc237ac41b2
1aa71615e4f3bb08f64fca618896e4f6cf5bd92e16b89d2cf6e195
6bfb
Q1.y = 45cce4beb96505cac5976b3d2673641e9bcd18d3462bbb453d293e
5282740a6389cfeae610adc7bd425c728541ceec83fcc999164af4
3fb5
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = ea441c10b3636ecedd5c0dfcae96384cc40de8390a0ab648765b45
08da12c586d55dc981275776507ebca0e4d1bcaa302bb69dcfa31b
3451
P.y = fee0192d49bcc0c28d954763c2cbe739b9265c4bebe3883803c649
71220cfda60b9ac99ad986cd908c0534b260b5cfca46f6c2b0f3f2
1bda
u[0] = 8cba93a007bb2c801b1769e026b1fa1640b14a34cf3029db3c7fd6
392745d6fec0f7870b5071d6da4402cedbbde28ae4e50ab30e1049
a238
u[1] = 4223746145069e4b8a981acc3404259d1a2c3ecfed5d864798a89d
45f81a2c59e2d40eb1d5f0fe11478cbb2bb30246dd388cb932ad7b
Faz-Hernandez, et al. Expires 17 December 2022 [Page 126]
Internet-Draft hash-to-curve June 2022
b330
Q0.x = 4321ab02a9849128691e9b80a5c5576793a218de14885fddccb91f
17ceb1646ea00a28b69ad211e1f14f17739612dbde3782319bdf00
9689
Q0.y = 1b8a7b539519eec0ea9f7a46a43822e16cba39a439733d6847ac44
a806b8adb3e1a75ea48a1228b8937ba85c6cb6ee01046e10cad895
3b1e
Q1.x = 126d744da6a14fddec0f78a9cee4571c1320ac7645b600187812e4
d7021f98fc4703732c54daec787206e1f34d9dbbf4b292c68160b8
bfbd
Q1.y = 136eebe6020f2389d448923899a1a38a4c8ad74254e0686e91c4f9
3c1f8f8e1bd619ffb7c1281467882a9c957d22d50f65c5b72b2aee
11af
J.6.2. curve448_XOF:SHAKE256_ELL2_NU_
suite = curve448_XOF:SHAKE256_ELL2_NU_
dst = QUUX-V01-CS02-with-curve448_XOF:SHAKE256_ELL2_NU_
msg =
P.x = b65e8dbb279fd656f926f68d463b13ca7a982b32f5da9c7cc58afc
f6199e4729863fb75ca9ae3c95c6887d95a5102637a1c5c40ff0aa
fadc
P.y = ea1ea211cf29eca11c057fe8248181591a19f6ac51d45843a65d4b
b8b71bc83a64c771ed7686218a278ef1c5d620f3d26b5316218864
5453
u[0] = 242c70f74eac8184116c71630d284cf8a742fc463e710545847ff6
4d8e9161cb9f599728a18a32dbd8b67c3bec5d64c9b1d2f2cde7b5
888d
Q.x = e6304424de5af3f556d3e645600530c53ad949891c3e60ba041dd5
f68a93901beff8440164477d348c13d28e27bfcd360c44c80b4c7d
4cea
Q.y = 4160a8f2043a347185406a6a7e50973b98b82edbdfa3209b0e1c90
118e10eeb45045b0990d4b2b0708a30eca17df40ad53c9100f20c1
0b44
msg = abc
P.x = 51aceca4fa95854bbaba58d8a5e17a86c07acadef32e1188cafda2
6232131800002cc2f27c7aec454e5e0c615bddffb7df6a5f7f0f14
793f
P.y = c590c9246eb28b08dee816d608ef233ea5d76e305dc458774a1e1b
d880387e6734219e2018e4aa50a49486dce0ba8740065da37e6cf5
212c
u[0] = ef6dcb75b696d325fb36d66b104700df1480c4c17ea9190d447eee
1e7e4c9b7f36bbfb8ba7ba7c4cb6b07fed16531c1ac7a26a3618b4
0b34
Q.x = de0dc93df9ce7953452f20e270699c1e7dacd5d571c226d77f53b7
e3053d16f8a81b1601efb362054e973c8e733b663af93f00cb81ba
#x27;s capabilities extension.
* If necessary, extend the tree to the right until it has at least
index + 1 leaves
* For each non-blank intermediate node along the path from the leaf
at position index to the root, add index to the unmerged_leaves
list for the node.
* Set the leaf node in the tree at position index to a new node
containing the public key from the KeyPackage in the Add, as well
as the credential under which the KeyPackage was signed
Barnes, et al. Expires 14 April 2022 [Page 55]
Internet-Draft MLS October 2021
11.1.2. Update
An Update proposal is a similar mechanism to Add with the distinction
that it is the sender's leaf KeyPackage in the tree which would be
updated with a new KeyPackage.
struct {
KeyPackage key_package;
} Update;
The values in the following fields of the KeyPackage contained in an
Update proposal MUST be the same as those of the KeyPackage it
replaces in the tree. version, cipher_suite, credential.identity,
endpoint_id. However, the value of the credential.signature_key
field of the new KeyPackage MUST be different from that of all other
KeyPackages in the tree. Furthermore, the value of the hpke_init_key
field of the new KeyPackage MUST be different from that of the
KeyPackage it replaces.
A member of the group applies an Update message by taking the
following steps:
* Replace the sender's leaf KeyPackage with the one contained in the
Update proposal
* Blank the intermediate nodes along the path from the sender's leaf
to the root
11.1.3. Remove
A Remove proposal requests that the member with KeyPackageID removed
be removed from the group.
struct {
KeyPackageID removed;
} Remove;
A member of the group applies a Remove message by taking the
following steps:
* Identify a leaf node containing a key package matching removed.
This lookup MUST be done on the tree before any non-Remove
proposals have been applied (the "old" tree in the terminology of
Section 11.2), since proposals such as Update can change the
KeyPackage stored at a leaf. Let removed_index be the node index
of this leaf node.
* Replace the leaf node at removed_index with a blank node
Barnes, et al. Expires 14 April 2022 [Page 56]
Internet-Draft MLS October 2021
* Blank the intermediate nodes along the path from removed_index to
the root
* Truncate the tree by reducing the size of tree until the rightmost
non-blank leaf node
11.1.4. PreSharedKey
A PreSharedKey proposal can be used to request that a pre-shared key
be injected into the key schedule in the process of advancing the
epoch.
struct {
PreSharedKeyID psk;
} PreSharedKey;
The psktype of the pre-shared key MUST be external and the psk_nonce
MUST be a randomly sampled nonce of length KDF.Nh. When processing a
Commit message that includes one or more PreSharedKey proposals,
group members derive psk_secret as described in Section 8.2, where
the order of the PSKs corresponds to the order of the PreSharedKey
proposals in the Commit.
11.1.5. ReInit
A ReInit proposal represents a request to re-initialize the group
with different parameters, for example, to increase the version
number or to change the ciphersuite. The re-initialization is done
by creating a completely new group and shutting down the old one.
struct {
opaque group_id<0..255>;
ProtocolVersion version;
CipherSuite cipher_suite;
Extension extensions<0..2^32-1>;
} ReInit;
A member of the group applies a ReInit proposal by waiting for the
committer to send the Welcome message and by checking that the
group_id and the parameters of the new group corresponds to the ones
specified in the proposal. The Welcome message MUST specify exactly
one pre-shared key with psktype = reinit, and with psk_group_id and
psk_epoch equal to the group_id and epoch of the existing group after
the Commit containing the reinit Proposal was processed. The Welcome
message may specify the inclusion of other pre-shared keys with a
psktype different from reinit.
Barnes, et al. Expires 14 April 2022 [Page 57]
Internet-Draft MLS October 2021
If a ReInit proposal is included in a Commit, it MUST be the only
proposal referenced by the Commit. If other non-ReInit proposals
have been sent during the epoch, the committer SHOULD prefer them
over the ReInit proposal, allowing the ReInit to be resent and
applied in a subsequent epoch. The version field in the ReInit
proposal MUST be no less than the version for the current group.
11.1.6. ExternalInit
An ExternalInit proposal is used by new members that want to join a
group by using an external commit. This propsal can only be used in
that context.
struct {
opaque kem_output<0..2^16-1>;
} ExternalInit;
A member of the group applies an ExternalInit message by initializing
the next epoch using an init secret computed as described in
Section 8.1. The kem_output field contains the required KEM output.
11.1.7. AppAck
An AppAck proposal is used to acknowledge receipt of application
messages. Though this information implies no change to the group, it
is structured as a Proposal message so that it is included in the
group's transcript by being included in Commit messages.
struct {
KeyPackageID sender;
uint32 first_generation;
uint32 last_generation;
} MessageRange;
struct {
MessageRange received_ranges<0..2^32-1>;
} AppAck;
An AppAck proposal represents a set of messages received by the
sender in the current epoch. Messages are represented by the sender
and generation values in the MLSCiphertext for the message. Each
MessageRange represents receipt of a span of messages whose
generation values form a continuous range from first_generation to
last_generation, inclusive.
AppAck proposals are sent as a guard against the Delivery Service
dropping application messages. The sequential nature of the
generation field provides a degree of loss detection, since gaps in
Barnes, et al. Expires 14 April 2022 [Page 58]
Internet-Draft MLS October 2021
the generation sequence indicate dropped messages. AppAck completes
this story by addressing the scenario where the Delivery Service
drops all messages after a certain point, so that a later generation
is never observed. Obviously, there is a risk that AppAck messages
could be suppressed as well, but their inclusion in the transcript
means that if they are suppressed then the group cannot advance at
all.
The schedule on which sending AppAck proposals are sent is up to the
application, and determines which cases of loss/suppression are
detected. For example:
* The application might have the committer include an AppAck
proposal whenever a Commit is sent, so that other members could
know when one of their messages did not reach the committer.
* The application could have a client send an AppAck whenever an
application message is sent, covering all messages received since
its last AppAck. This would provide a complete view of any losses
experienced by active members.
* The application could simply have clients send AppAck proposals on
a timer, so that all participants' state would be known.
An application using AppAck proposals to guard against loss/
suppression of application messages also needs to ensure that AppAck
messages and the Commits that reference them are not dropped. One
way to do this is to always encrypt Proposal and Commit messages, to
make it more difficult for the Delivery Service to recognize which
messages conatain AppAcks. The application can also have clients
enforce an AppAck schedule, reporting loss if an AppAck is not
received at the expected time.
11.1.8. GroupContextExtensions
A GroupContextExtensions proposal is used to update the list of
extensions in the GroupContext for the group.
struct { Extension extensions<0..2^32-1>; } GroupContextExtensions;
A member of the group applies a GroupContextExtensions proposal with
the following steps:
* If the new extensions include a required_capabilities extension,
verify that all members of the group support the required
capabilities (including those added in the same commit, and
excluding those removed).
Barnes, et al. Expires 14 April 2022 [Page 59]
Internet-Draft MLS October 2021
* Remove all of the existing extensions from the GroupContext object
for the group and replacing them with the list of extensions in
the proposal. (This is a wholesale replacement, not a merge. An
extension is only carried over if the sender of the proposal
includes it in the new list.)
Note that once the GroupContext is updated, its inclusion in the
confirmation_tag by way of the key schedule will confirm that all
members of the group agree on the extensions in use.
11.1.9. External Proposals
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group. For example, a Delivery Service
might propose to remove a member of a group who has been inactive for
a long time, or propose adding a newly-hired staff member to a group
representing a real-world team. Proposals originating outside the
group are identified by a preconfigured or new_member SenderType in
MLSPlaintext.
ReInit proposals can also be sent to the group by a preconfigured
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
The new_member SenderType is used for clients proposing that they
themselves be added. For this ID type the sender value MUST be zero
and the Proposal type MUST be Add. The MLSPlaintext MUST be signed
with the private key corresponding to the KeyPackage in the Add
message. Recipients MUST verify that the MLSPlaintext carrying the
Proposal message is validly signed with this key.
The preconfigured SenderType is reserved for signers that are pre-
provisioned to the clients within a group. If proposals with these
sender IDs are to be accepted within a group, the members of the
group MUST be provisioned by the application with a mapping between
these IDs and authorized signing keys. Recipients MUST verify that
the MLSPlaintext carrying the Proposal message is validly signed with
the corresponding key. To ensure consistent handling of external
proposals, the application MUST ensure that the members of a group
have the same mapping and apply the same policies to external
proposals.
An external proposal MUST be sent as an MLSPlaintext object, since
the sender will not have the keys necessary to construct an
MLSCiphertext object.
Barnes, et al. Expires 14 April 2022 [Page 60]
Internet-Draft MLS October 2021
11.2. Commit
A Commit message initiates a new epoch for the group, based on a
collection of Proposals. It instructs group members to update their
representation of the state of the group by applying the proposals
and advancing the key schedule.
Each proposal covered by the Commit is included by a ProposalOrRef
value, which identifies the proposal to be applied by value or by
reference. Proposals supplied by value are included directly in the
Commit object. Proposals supplied by reference are specified by
including the hash of the MLSPlaintext in which the Proposal was
sent, using the hash function from the group's ciphersuite. For
proposals supplied by value, the sender of the proposal is the same
as the sender of the Commit. Conversely, proposals sent by people
other than the committer MUST be included by reference.
enum {
reserved(0),
proposal(1)
reference(2),
(255)
} ProposalOrRefType;
struct {
ProposalOrRefType type;
select (ProposalOrRef.type) {
case proposal: Proposal proposal;
case reference: opaque hash<0..255>;
}
} ProposalOrRef;
struct {
ProposalOrRef proposals<0..2^32-1>;
optional<UpdatePath> path;
} Commit;
A group member that has observed one or more proposals within an
epoch MUST send a Commit message before sending application data.
This ensures, for example, that any members whose removal was
proposed during the epoch are actually removed before any application
data is transmitted.
The sender of a Commit MUST include all valid proposals that it has
received during the current epoch. Invalid proposals include, for
example, proposals with an invalid signature or proposals that are
semantically invalid, such as an Add when the sender does not have
the application-level permission to add new users. Proposals with a
Barnes, et al. Expires 14 April 2022 [Page 61]
Internet-Draft MLS October 2021
non-default proposal type MUST NOT be included in a commit unless the
proposal type is supported by all the members of the group that will
process the Commit (i.e., not including any members being added or
removed by the Commit).
If there are multiple proposals that apply to the same leaf, the
committer chooses one and includes only that one in the Commit,
considering the rest invalid. The committer MUST prefer any Remove
received, or the most recent Update for the leaf if there are no
Removes. If there are multiple Add proposals containing KeyPackages
with the same tuple (credential.identity, endpoint_id) the committer
again chooses one to include and considers the rest invalid. Add
proposals that contain KeyPackages with an (credential.identity,
endpoint_id) tuple that matches that of an existing KeyPackage in the
group MUST be considered invalid. The comitter MUST consider invalid
any Add or Update proposal if the Credential in the contained
KeyPackage shares the same signature key with a Credential in any
leaf of the group, or indeed if the KeyPackage shares the same
hpke_init_key with another KeyPackage in the group.
The Commit MUST NOT combine proposals sent within different epochs.
In the event that a valid proposal is omitted from the next Commit,
the sender of the proposal SHOULD retransmit it in the new epoch.
A member of the group MAY send a Commit that references no proposals
at all, which would thus have an empty proposals vector. Such a
Commit resets the sender's leaf and the nodes along its direct path,
and provides forward secrecy and post-compromise security with regard
to the sender of the Commit. An Update proposal can be regarded as a
"lazy" version of this operation, where only the leaf changes and
intermediate nodes are blanked out.
The path field of a Commit message MUST be populated if the Commit
covers at least one Update or Remove proposal. The path field MUST
also be populated if the Commit covers no proposals at all (i.e., if
the proposals vector is empty). The path field MAY be omitted if the
Commit covers only Add proposals. In pseudocode, the logic for
validating a Commit is as follows:
Barnes, et al. Expires 14 April 2022 [Page 62]
Internet-Draft MLS October 2021
hasUpdates = false
hasRemoves = false
for i, id in commit.proposals:
proposal = proposalCache[id]
assert(proposal != null)
hasUpdates = hasUpdates || proposal.msg_type == update
hasRemoves = hasRemoves || proposal.msg_type == remove
if len(commit.proposals) == 0 || hasUpdates || hasRemoves:
assert(commit.path != null)
To summarize, a Commit can have three different configurations, with
different uses:
1. An "empty" Commit that references no proposals, which updates the
committer's contribution to the group and provides PCS with
regard to the committer.
2. A "partial" Commit that references Add, PreSharedKey, or ReInit
proposals but where the path is empty. Such a commit doesn't
provide PCS with regard to the committer.
3. A "full" Commit that references proposals of any type, which
provides FS with regard to any removed members and PCS for the
committer and any updated members.
When creating or processing a Commit, three different ratchet trees
and their associated GroupContexts are used:
1. "Old" refers to the ratchet tree and GroupContext for the epoch
before the commit. The old GroupContext is used when signing the
MLSPlainText so that existing group members can verify the
signature before processing the commit.
2. "Provisional" refers to the ratchet tree and GroupContext
constructed after applying the proposals that are referenced by
the Commit. The provisional GroupContext uses the epoch number
for the new epoch, and the old confirmed transcript hash. This
is used when creating the UpdatePath, if the UpdatePath is
needed.
Barnes, et al. Expires 14 April 2022 [Page 63]
Internet-Draft MLS October 2021
3. "New" refers to the ratchet tree and GroupContext constructed
after applying the proposals and the UpdatePath (if any). The
new GroupContext uses the epoch number for the new epoch, and the
new confirmed transcript hash. This is used when deriving the
new epoch secrets, and is the only GroupContext that newly-added
members will have.
A member of the group creates a Commit message and the corresponding
Welcome message at the same time, by taking the following steps:
* Construct an initial Commit object with the proposals field
populated from Proposals received during the current epoch, and an
empty path field.
* Generate the provisional ratchet tree and GroupContext by applying
the proposals referenced in the initial Commit object, as
described in Section 11.1. Update proposals are applied first,
followed by Remove proposals, and then finally Add proposals. Add
proposals are applied in the order listed in the proposals vector,
and always to the leftmost unoccupied leaf in the tree, or the
right edge of the tree if all leaves are occupied.
- Note that the order in which different types of proposals are
applied should be updated by the implementation to include any
new proposals added by negotiated group extensions.
- PreSharedKey proposals are processed later when deriving the
psk_secret for the Key Schedule.
* Decide whether to populate the path field: If the path field is
required based on the proposals that are in the commit (see
above), then it MUST be populated. Otherwise, the sender MAY omit
the path field at its discretion.
* If populating the path field: Create an UpdatePath using the
provisional ratchet tree and GroupContext. Any new member (from
an add proposal) MUST be exluded from the resolution during the
computation of the UpdatePath. The leaf_key_package for this
UpdatePath must have a parent_hash extension. Note that the
KeyPackage in the UpdatePath effectively updates an existing
KeyPackage in the group and thus MUST adhere to the same
restrictions as KeyPackages used in Update proposals.
- Assign this UpdatePath to the path field in the Commit.
Barnes, et al. Expires 14 April 2022 [Page 64]
Internet-Draft MLS October 2021
- Apply the UpdatePath to the tree, as described in Section 5.5,
creating the new ratchet tree. Define commit_secret as the
value path_secret[n+1] derived from the path_secret[n] value
assigned to the root node.
* If not populating the path field: Set the path field in the Commit
to the null optional. Define commit_secret as the all-zero vector
of length KDF.Nh (the same length as a path_secret value would
be). In this case, the new ratchet tree is the same as the
provisional ratchet tree.
* Derive the psk_secret as specified in Section 8.2, where the order
of PSKs in the derivation corresponds to the order of PreSharedKey
proposals in the proposals vector.
* Construct an MLSPlaintext object containing the Commit object.
Sign the MLSPlaintext using the old GroupContext as context.
- Use the MLSPlaintext to update the confirmed transcript hash
and generate the new GroupContext.
- Use the init_secret from the previous epoch, the commit_secret
and the psk_secret as defined in the previous steps, and the
new GroupContext to compute the new joiner_secret,
welcome_secret, epoch_secret, and derived secrets for the new
epoch.
- Use the confirmation_key for the new epoch to compute the
confirmation_tag value, and the membership_key for the old
epoch to compute the membership_tag value in the MLSPlaintext.
- Calculate the interim transcript hash using the new confirmed
transcript hash and the confirmation_tag from the MLSPlaintext.
* Construct a GroupInfo reflecting the new state:
- Group ID, epoch, tree, confirmed transcript hash, interim
transcript hash, and group context extensions from the new
state
- The confirmation_tag from the MLSPlaintext object
- Other extensions as defined by the application
- Sign the GroupInfo using the member's private signing key
- Encrypt the GroupInfo using the key and nonce derived from the
joiner_secret for the new epoch (see Section 11.2.2)
Barnes, et al. Expires 14 April 2022 [Page 65]
Internet-Draft MLS October 2021
* For each new member in the group:
- Identify the lowest common ancestor in the tree of the new
member's leaf node and the member sending the Commit
- If the path field was populated above: Compute the path secret
corresponding to the common ancestor node
- Compute an EncryptedGroupSecrets object that encapsulates the
init_secret for the current epoch and the path secret (if
present).
* Construct a Welcome message from the encrypted GroupInfo object,
the encrypted key packages, and any PSKs for which a proposal was
included in the Commit. The order of the psks MUST be the same as
the order of PreSharedKey proposals in the proposals vector.
* If a ReInit proposal was part of the Commit, the committer MUST
create a new group with the parameters specified in the ReInit
proposal, and with the same members as the original group. The
Welcome message MUST include a PreSharedKeyID with psktype reinit
and with psk_group_id and psk_epoch corresponding to the current
group and the epoch after the commit was processed.
A member of the group applies a Commit message by taking the
following steps:
* Verify that the epoch field of the enclosing MLSPlaintext message
is equal to the epoch field of the current GroupContext object
* Verify that the signature on the MLSPlaintext message verifies
using the public key from the credential stored at the leaf in the
tree indicated by the sender field.
* Verify that all PSKs specified in any PreSharedKey proposals in
the proposals vector are available.
* Generate the provisional ratchet tree and GroupContext by applying
the proposals referenced in the initial Commit object, as
described in Section 11.1. Update proposals are applied first,
followed by Remove proposals, and then finally Add proposals. Add
proposals are applied in the order listed in the proposals vector,
and always to the leftmost unoccupied leaf in the tree, or the
right edge of the tree if all leaves are occupied.
- Note that the order in which different types of proposals are
applied should be updated by the implementation to include any
new proposals added by negotiated group extensions.
Barnes, et al. Expires 14 April 2022 [Page 66]
Internet-Draft MLS October 2021
* Verify that the path value is populated if the proposals vector
contains any Update or Remove proposals, or if it's empty.
Otherwise, the path value MAY be omitted.
* If the path value is populated: Process the path value using the
provisional ratchet tree and GroupContext, to generate the new
ratchet tree and the commit_secret:
- Apply the UpdatePath to the tree, as described in Section 5.5,
and store leaf_key_package at the Committer's leaf.
- Verify that the KeyPackage has a parent_hash extension and that
its value matches the new parent of the sender's leaf node.
- Define commit_secret as the value path_secret[n+1] derived from
the path_secret[n] value assigned to the root node.
* If the path value is not populated: Define commit_secret as the
all-zero vector of length KDF.Nh (the same length as a path_secret
value would be).
* Update the confirmed and interim transcript hashes using the new
Commit, and generate the new GroupContext.
* Derive the psk_secret as specified in Section 8.2, where the order
of PSKs in the derivation corresponds to the order of PreSharedKey
proposals in the proposals vector.
* Use the init_secret from the previous epoch, the commit_secret and
the psk_secret as defined in the previous steps, and the new
GroupContext to compute the new joiner_secret, welcome_secret,
epoch_secret, and derived secrets for the new epoch.
* Use the confirmation_key for the new epoch to compute the
confirmation tag for this message, as described below, and verify
that it is the same as the confirmation_tag field in the
MLSPlaintext object.
* If the above checks are successful, consider the new GroupContext
object as the current state of the group.
* If the Commit included a ReInit proposal, the client MUST NOT use
the group to send messages anymore. Instead, it MUST wait for a
Welcome message from the committer and check that
Barnes, et al. Expires 14 April 2022 [Page 67]
Internet-Draft MLS October 2021
- The version, cipher_suite and extensions fields of the new
group corresponds to the ones in the ReInit proposal, and that
the version is greater than or equal to that of the original
group.
- The psks field in the Welcome message includes a PreSharedKeyID
with psktype = reinit, and psk_epoch and psk_group_id equal to
the epoch and group ID of the original group after processing
the Commit.
The confirmation tag value confirms that the members of the group
have arrived at the same state of the group:
MLSPlaintext.confirmation_tag =
MAC(confirmation_key, GroupContext.confirmed_transcript_hash)
11.2.1. External Commits
External Commits are a mechanism for new members (external parties
that want to become members of the group) to add themselves to a
group, without requiring that an existing member has to come online
to issue a Commit that references an Add Proposal.
Whether existing members of the group will accept or reject an
External Commit follows the same rules that are applied to other
handshake messages.
New members can create and issue an External Commit if they have
access to the following information for the group's current epoch:
* group ID
* epoch ID
* ciphersuite
* public tree hash
* interim transcript hash
* group extensions
* external public key
This information is aggregated in a PublicGroupState object as
follows:
Barnes, et al. Expires 14 April 2022 [Page 68]
Internet-Draft MLS October 2021
struct {
CipherSuite cipher_suite;
opaque group_id<0..255>;
uint64 epoch;
opaque tree_hash<0..255>;
opaque interim_transcript_hash<0..255>;
Extension group_context_extensions<0..2^32-1>;
Extension other_extensions<0..2^32-1>;
HPKEPublicKey external_pub;
KeyPackageID signer;
opaque signature<0..2^16-1>;
} PublicGroupState;
Note that the tree_hash field is used the same way as in the Welcome
message. The full tree can be included via the ratchet_tree
extension Section 11.3.
The signature MUST verify using the public key taken from the
credential in the leaf node of the member with KeyPackageID signer.
The signature covers the following structure, comprising all the
fields in the PublicGroupState above signature:
struct {
opaque group_id<0..255>;
uint64 epoch;
opaque tree_hash<0..255>;
opaque interim_transcript_hash<0..255>;
Extension group_context_extensions<0..2^32-1>;
Extension other_extensions<0..2^32-1>;
HPKEPublicKey external_pub;
KeyPackageID signer;
} PublicGroupStateTBS;
This signature authenticates the HPKE public key, so that the joiner
knows that the public key was provided by a member of the group. The
fields that are not signed are included in the key schedule via the
GroupContext object. If the joiner is provided an inaccurate data
for these fields, then its external Commit will have an incorrect
confirmation_tag and thus be rejected.
The information in a PublicGroupState is not deemed public in
general, but applications can choose to make it available to new
members in order to allow External Commits.
External Commits work like regular Commits, with a few differences:
* The proposals included by value in an External Commit MUST meet
the following conditions:
Barnes, et al. Expires 14 April 2022 [Page 69]
Internet-Draft MLS October 2021
- There MUST be a single Add proposal that adds the new issuing
new member to the group
- There MUST be a single ExternalInit proposal
- There MUST NOT be any Update proposals
- If a Remove proposal is present, then the credential and
endpoint_id of the removed leaf MUST be the same as the
corresponding values in the Add KeyPackage.
* The proposals included by reference in an External Commit MUST
meet the following conditions:
- There MUST NOT be any ExternalInit proposals
* External Commits MUST contain a path field (and is therefore a
"full" Commit)
* External Commits MUST be signed by the new member. In particular,
the signature on the enclosing MLSPlaintext MUST verify using the
public key for the credential in the leaf_key_package of the path
field.
* When processing a Commit, both existing and new members MUST use
the external init secret as described in Section 8.1.
* The sender type for the MLSPlaintext encapsulating the External
Commit MUST be new_member
In other words, External Commits come in two "flavors" -- a "join"
commit that adds the sender to the group or a "resync" commit that
replaces a member's prior appearance with a new one.
Note that the "resync" operation allows an attacker that has
compromised a member's signature private key to introduce themselves
into the group and remove the prior, legitimate member in a single
Commit. Without resync, this can still be done, but requires two
operations, the external Commit to join and a second Commit to remove
the old appearance. Applications for whom this distinction is
salient can choose to disallow external commits that contain a
Remove, or to allow such resync commits only if they contain a
"reinit" PSK proposal that demonstrates the joining member's presence
in a prior epoch of the group. With the latter approach, the attacke
would need to compromise the PSK as well as the signing key, but the
application will need to ensure that continuing, non-resync'ing
members have the required PSK.
Barnes, et al. Expires 14 April 2022 [Page 70]
Internet-Draft MLS October 2021
11.2.2. Welcoming New Members
The sender of a Commit message is responsible for sending a Welcome
message to any new members added via Add proposals. The Welcome
message provides the new members with the current state of the group,
after the application of the Commit message. The new members will
not be able to decrypt or verify the Commit message, but will have
the secrets they need to participate in the epoch initiated by the
Commit message.
In order to allow the same Welcome message to be sent to all new
members, information describing the group is encrypted with a
symmetric key and nonce derived from the joiner_secret for the new
epoch. The joiner_secret is then encrypted to each new member using
HPKE. In the same encrypted package, the committer transmits the
path secret for the lowest node contained in the direct paths of both
the committer and the new member. This allows the new member to
compute private keys for nodes in its direct path that are being
reset by the corresponding Commit.
If the sender of the Welcome message wants the receiving member to
include a PSK in the derivation of the epoch_secret, they can
populate the psks field indicating which PSK to use.
Barnes, et al. Expires 14 April 2022 [Page 71]
Internet-Draft MLS October 2021
struct {
opaque group_id<0..255>;
uint64 epoch;
opaque tree_hash<0..255>;
opaque confirmed_transcript_hash<0..255>;
Extension group_context_extensions<0..2^32-1>;
Extension other_extensions<0..2^32-1>;
MAC confirmation_tag;
KeyPackageID signer;
opaque signature<0..2^16-1>;
} GroupInfo;
struct {
opaque path_secret<1..255>;
} PathSecret;
struct {
opaque joiner_secret<1..255>;
optional<PathSecret> path_secret;
PreSharedKeys psks;
} GroupSecrets;
struct {
KeyPackageID new_member<1..255>;
HPKECiphertext encrypted_group_secrets;
} EncryptedGroupSecrets;
struct {
ProtocolVersion version = mls10;
CipherSuite cipher_suite;
EncryptedGroupSecrets secrets<0..2^32-1>;
opaque encrypted_group_info<1..2^32-1>;
} Welcome;
The client processing a Welcome message will need to have a copy of
the group's ratchet tree. The tree can be provided in the Welcome
message, in an extension of type ratchet_tree. If it is sent
otherwise (e.g., provided by a caching service on the Delivery
Service), then the client MUST download the tree before processing
the Welcome.
On receiving a Welcome message, a client processes it using the
following steps:
Barnes, et al. Expires 14 April 2022 [Page 72]
Internet-Draft MLS October 2021
* Identify an entry in the secrets array where the new_member value
corresponds to one of this client's KeyPackages, using the hash
indicated by the cipher_suite field. If no such field exists, or
if the ciphersuite indicated in the KeyPackage does not match the
one in the Welcome message, return an error.
* Decrypt the encrypted_group_secrets using HPKE with the algorithms
indicated by the ciphersuite and the HPKE private key
corresponding to the GroupSecrets. If a PreSharedKeyID is part of
the GroupSecrets and the client is not in possession of the
corresponding PSK, return an error.
* From the joiner_secret in the decrypted GroupSecrets object and
the PSKs specified in the GroupSecrets, derive the welcome_secret
and using that the welcome_key and welcome_nonce. Use the key and
nonce to decrypt the encrypted_group_info field.
welcome_nonce = KDF.Expand(welcome_secret, "nonce", AEAD.Nn)
welcome_key = KDF.Expand(welcome_secret, "key", AEAD.Nk)
* Verify the signature on the GroupInfo object. The signature input
comprises all of the fields in the GroupInfo object except the
signature field. The public key and algorithm are taken from the
credential in the leaf node of the member with KeyPackageID
signer. If there is no matching leaf node, or if signature
verification fails, return an error.
* Verify the integrity of the ratchet tree.
- Verify that the tree hash of the ratchet tree matches the
tree_hash field in the GroupInfo.
- For each non-empty parent node, verify that exactly one of the
node's children are non-empty and have the hash of this node
set as their parent_hash value (if the child is another parent)
or has a parent_hash extension in the KeyPackage containing the
same value (if the child is a leaf). If either of the node's
children is empty, and in particular does not have a parent
hash, then its respective children's parent_hash values have to
be considered instead.
- For each non-empty leaf node, verify the signature on the
KeyPackage.
* Identify a leaf in the tree array (any even-numbered node) whose
key_package field is identical to the KeyPackage. If no such
field exists, return an error. Let index represent the index of
this node in the tree.
Barnes, et al. Expires 14 April 2022 [Page 73]
Internet-Draft MLS October 2021
* Construct a new group state using the information in the GroupInfo
object.
- The GroupContext contains the group_id, epoch, tree_hash,
confirmed_transcript_hash, and group_context_extensions fields
from the GroupInfo object.
- The new member's position in the tree is index, as defined
above.
- Update the leaf at index index with the private key
corresponding to the public key in the node.
- If the path_secret value is set in the GroupSecrets object:
Identify the lowest common ancestor of the node index index and
of the node index of the member with KeyPackageID
GroupInfo.signer. Set the private key for this node to the
private key derived from the path_secret.
- For each parent of the common ancestor, up to the root of the
tree, derive a new path secret and set the private key for the
node to the private key derived from the path secret. The
private key MUST be the private key that corresponds to the
public key in the node.
* Use the joiner_secret from the GroupSecrets object to generate the
epoch secret and other derived secrets for the current epoch.
* Set the confirmed transcript hash in the new state to the value of
the confirmed_transcript_hash in the GroupInfo.
* Verify the confirmation tag in the GroupInfo using the derived
confirmation key and the confirmed_transcript_hash from the
GroupInfo.
* Use the confirmed transcript hash and confirmation tag to compute
the interim transcript hash in the new state.
11.3. Ratchet Tree Extension
By default, a GroupInfo message only provides the joiner with a
commitment to the group's ratchet tree. In order to process or
generate handshake messages, the joiner will need to get a copy of
the ratchet tree from some other source. (For example, the DS might
provide a cached copy.) The inclusion of the tree hash in the
GroupInfo message means that the source of the ratchet tree need not
be trusted to maintain the integrity of tree.
Barnes, et al. Expires 14 April 2022 [Page 74]
Internet-Draft MLS October 2021
In cases where the application does not wish to provide such an
external source, the whole public state of the ratchet tree can be
provided in an extension of type ratchet_tree, containing a
ratchet_tree object of the following form:
enum {
reserved(0),
leaf(1),
parent(2),
(255)
} NodeType;
struct {
NodeType node_type;
select (Node.node_type) {
case leaf: KeyPackage key_package;
case parent: ParentNode node;
};
} Node;
optional<Node> ratchet_tree<1..2^32-1>;
The presence of a ratchet_tree extension in a GroupInfo message does
not result in any changes to the GroupContext extensions for the
group. The ratchet tree provided is simply stored by the client and
used for MLS operations.
If this extension is not provided in a Welcome message, then the
client will need to fetch the ratchet tree over some other channel
before it can generate or process Commit messages. Applications
should ensure that this out-of-band channel is provided with security
protections equivalent to the protections that are afforded to
Proposal and Commit messages. For example, an application that
encrypts Proposal and Commit messages might distribute ratchet trees
encrypted using a key exchanged over the MLS channel.
12. Extensibility
This protocol includes a mechanism for negotiating extension
parameters similar to the one in TLS [RFC8446]. In TLS, extension
negotiation is one-to-one: The client offers extensions in its
ClientHello message, and the server expresses its choices for the
session with extensions in its ServerHello and EncryptedExtensions
messages. In MLS, extensions appear in the following places:
* In KeyPackages, to describe client capabilities and aspects of
their participation in the group (once in the ratchet tree)
Barnes, et al. Expires 14 April 2022 [Page 75]
Internet-Draft MLS October 2021
* In the Welcome message, to tell new members of a group what
parameters are being used by the group, and to provide any
additional details required to join the group
* In the GroupContext object, to ensure that all members of the
group have the same view of the parameters in use
In other words, an application can use GroupContext extensions to
ensure that all members of the group agree on a set of parameters.
Clients indicate their support for parameters in KeyPackage
extensions. New members of a group are informed of the group's
GroupContext extensions via the group_context_extensions field in the
GroupInfo or PublicGroupState object. The other_extensions field in
a GroupInfo object can be used to provide additional parameters to
new joiners that are used to join the group.
This extension mechanism is designed to allow for secure and forward-
compatible negotiation of extensions. For this to work,
implementations MUST correctly handle extensible fields:
* A client that posts a KeyPackage MUST support all parameters
advertised in it. Otherwise, another client might fail to
interoperate by selecting one of those parameters.
* A client initiating a group MUST ignore all unrecognized
ciphersuites, extensions, and other parameters. Otherwise, it may
fail to interoperate with newer clients.
* A client adding a new member to a group MUST verify that the
KeyPackage for the new member contains extensions that are
consistent with the group's extensions. For each extension in the
GroupContext, the KeyPackage MUST have an extension of the same
type, and the contents of the extension MUST be consistent with
the value of the extension in the GroupContext, according to the
semantics of the specific extension.
* If any extension in a GroupInfo message is unrecognized (i.e., not
contained in the corresponding KeyPackage), then the client MUST
reject the Welcome message and not join the group.
* The extensions populated into a GroupContext object are drawn from
those in the GroupInfo object, according to the definitions of
those extensions.
Note that the latter two requirements mean that all MLS extensions
are mandatory, in the sense that an extension in use by the group
MUST be supported by all members of the group.
Faz-Hernandez, et al. Expires 17 December 2022 [Page 127]
Internet-Draft hash-to-curve June 2022
f130
Q.y = 8c5bdec6fa6690905f6eff966b0f98f5a8161493bd04976684d4ec
1f4512fa8743d86860b2ff2c5d67e9c145fd906f2cb89ff812c6b9
883f
msg = abcdef0123456789
P.x = c6d65987f146b8d0cb5d2c44e1872ac3af1f458f6a8bd8c232ffe8
b9d09496229a5a27f350eb7d97305bcc4e0f38328718352e8e3129
ed71
P.y = 4d2f901bf333fdc4135b954f20d59207e9f6a4ecf88ce5af11c892
b44f79766ec4ecc9f60d669b95ca8940f39b1b7044140ac2040c1b
f659
u[0] = 3012ba5d9b3bb648e4613833a26ecaeadb3e8c8bba07fc90ac3da0
375769289c44d3dc87474b23df7f45f9a4030892cda689e343aeee
a6ad
Q.x = dc29532761f03c24d57f530da4c24acc4c676d185becaa89fcc083
266541fb7f10ecec91dac64a34cd988274633ae25c4d784aee52de
47a8
Q.y = a5f6da11259c69f2e07fce6a7b6afec4c25bd2df83426765f9c070
4111da24c6a0550d5c7aac7d648d55f7640d50be99c926195e852a
daac
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 9b8d008863beb4a02fb9e4efefd2eba867307fb1c7ce01746115d3
2e1db551bb254e8e3e4532d5c74a83949a69a60519ecc9178083cb
e943
P.y = 346a1fca454d1e67c628437c270ec0f0c4256bb774fe6c0e49de70
04ff6d9199e2cd99d8f7575a96aafc4dc8db1811ba0a44317581f4
1371
u[0] = fe952ac0149f92436bba12ea2e542aa226f4fc074d79ff462c41b3
27968a649a495a8a93b6c3044af2273456abb5e166ce4fb8c9b10c
8c2e
Q.x = 512803d89f59c57376e6570cd54c4e901643e089cd9456f549daa4
372b8b52679860b68aa8bedfaa88970f15ab6098d5f252083ac98a
58c9
Q.y = 3d9b6593c7941a20d76161c9a171f1e507495a08f03dfcae33a2ac
3602698e46a74d1039b583c984036f590eaa43d20ba5aada3ffb55
2f77
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 128]
Internet-Draft hash-to-curve June 2022
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 8746dc34799112d1f20acda9d7f722c9abb29b1fb6b7e9e5669838
43c20bd7c9bfad21b45c5166b808d2f5d44e188f1fdaf29cdee8a7
2e4c
P.y = 7c1293484c9287c298a1a0600c64347eee8530acf563cd8705e057
28274d8cd8101835f8003b6f3b78b5beb28f5be188a3d7bce1ec5a
36b1
u[0] = afd3d7ad9d819be7561706e050d4f30b634b203387ab682739365f
62cd7393ca2cf18cd07a3d3af8dd163f043ac7457c2eb145b4a561
70a9
Q.x = 08aed6480793218034fd3b3b0867943d7e0bd1b6f76b4929e0885b
d082b84d4449341da6038bb08229ad9eb7d518dff2c7ea50148e70
a4db
Q.y = e00d32244561ebd4b5f4ef70fcac75a06416be0a1c1b304e7bd361
a6a6586915bb902a323eaf73cf7738e70d34282f61485395ab2833
d2c1
J.7. edwards448
J.7.1. edwards448_XOF:SHAKE256_ELL2_RO_
suite = edwards448_XOF:SHAKE256_ELL2_RO_
dst = QUUX-V01-CS02-with-edwards448_XOF:SHAKE256_ELL2_RO_
msg =
P.x = 73036d4a88949c032f01507005c133884e2f0d81f9a950826245dd
a9e844fc78186c39daaa7147ead3e462cff60e9c6340b58134480b
4d17
P.y = 94c1d61b43728e5d784ef4fcb1f38e1075f3aef5e99866911de5a2
34f1aafdc26b554344742e6ba0420b71b298671bbeb2b773661863
4610
u[0] = 0847c5ebf957d3370b1f98fde499fb3e659996d9fc9b5707176ade
785ba72cd84b8a5597c12b1024be5f510fa5ba99642c4cec7f3f69
d3e7
u[1] = f8cbd8a7ae8c8deed071f3ac4b93e7cfcb8f1eac1645d699fd6d38
81cb295a5d3006d9449ed7cad412a77a1fe61e84a9e41d59ef384d
6f9a
Q0.x = c08177330869db17fb81a5e6e53b36d29086d806269760f2e4caba
a4015f5dbadb7ca2ba594d96a89d0ca4f0944489e1ef393d53db85
096f
Q0.y = 02e894598c050eeb7195f5791f1a5f65da3776b7534be37640bcbf
95d4b915bd22333c50387583507169708fbd7bea0d7aa385dcc614
be9c
Q1.x = 770877fd3b6c5503398157b68a9d3609f585f40e1ebebdd69bb0e4
d3d9aa811995ce75333fdadfa50db886a35959cc59cffd5c9710da
ca25
Faz-Hernandez, et al. Expires 17 December 2022 [Page 129]
Internet-Draft hash-to-curve June 2022
Q1.y = b27fef77aa6231fbbc27538fa90eaca8abd03eb1e62fdae4ec5e82
8117c3b8b3ff8c34d0a6e6d79fff16d339b94ae8ede33331d5b464
c792
msg = abc
P.x = 4e0158acacffa545adb818a6ed8e0b870e6abc24dfc1dc45cf9a05
2e98469275d9ff0c168d6a5ac7ec05b742412ee090581f12aa398f
9f8c
P.y = 894d3fa437b2d2e28cdc3bfaade035430f350ec5239b6b406b5501
da6f6d6210ff26719cad83b63e97ab26a12df6dec851d6bf38e294
af9a
u[0] = 04d975cd938ab49be3e81703d6a57cca84ed80d2ff6d4756d3f229
47fb5b70ab0231f0087cbfb4b7cae73b41b0c9396b356a4831d9a1
4322
u[1] = 2547ca887ac3db7b5fad3a098aa476e90078afe1358af6c63d677d
6edfd2100bc004e0f5db94dd2560fc5b308e223241d00488c9ca6b
0ef2
Q0.x = 7544612a97f4419c94ab0f621a1ee8ccf46c6657b8e0778ec9718b
f4b41bc774487ad87d9b1e617aa49d3a4dd35a3cf57cd390ebf042
9952
Q0.y = d3ab703e60267d796b485bb58a28f934bd0133a6d1bbdfeda5277f
a293310be262d7f653a5adffa608c37ed45c0e6008e54a16e1a342
e4df
Q1.x = 6262f18d064bc131ade1b8bbcf1cbdf984f4f88153fcc9f94c888a
f35d5e41aae84c12f169a55d8abf06e6de6c5b23079e587a58cf73
303e
Q1.y = 6d57589e901abe7d947c93ab02c307ad9093ed9a83eb0b6e829fb7
318d590381ca25f3cc628a36a924a9ddfcf3cbedf94edf3b338ea7
7403
msg = abcdef0123456789
P.x = 2c25b4503fadc94b27391933b557abdecc601c13ed51c5de683894
84f93dbd6c22e5f962d9babf7a39f39f994312f8ca23344847e1fb
f176
P.y = d5e6f5350f430e53a110f5ac7fcc82a96cb865aeca982029522d32
601e41c042a9dfbdfbefa2b0bdcdc3bc58cca8a7cd546803083d3a
8548
u[0] = 10659ce25588db4e4be6f7c791a79eb21a7f24aaaca76a6ca3b83b
80aaf95aa328fe7d569a1ac99f9cd216edf3915d72632f1a8b990e
250c
u[1] = 9243e5b6c480683fd533e81f4a778349a309ce00bd163a29eb9fa8
dbc8f549242bef33e030db21cffacd408d2c4264b93e476c6a8590
e7aa
Q0.x = 1457b60c12e00e47ceb3ce64b57e7c3c61636475443d704a8e2b2a
b0a5ac7e4b3909435416784e16e19929c653b1bdcd9478a8e5331c
a9ae
Q0.y = 935d9f75f7a0babbc39c0a1c3b412518ed8a24bc2c4886722fb4b7
d4a747af98e4e2528c75221e2dffd3424abb436e10539a74caaafa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 130]
Internet-Draft hash-to-curve June 2022
3ea3
Q1.x = b44d9e34211b4028f24117e856585ed81448f3c8b934987a1c5939
c86048737a08d85934fec6b3c2ef9f09cbd365cf22744f2e4ce697
62a4
Q1.y = dc996c1736f4319868f897d9a27c45b02dd3bc6b7ca356a039606e
5406e131a0bbe8238208b327b00853e8af84b58b13443e70542556
3323
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = a1861a9464ae31249a0e60bf38791f3663049a3f5378998499a832
92e159a2fecff838eb9bc6939e5c6ae76eb074ad4aae39b55b72ca
0b9a
P.y = 580a2798c5b904f8adfec5bd29fb49b4633cd9f8c2935eb4a0f12e
5dfa0285680880296bb729c6405337525fb5ed3dff930c137314f6
0401
u[0] = c80390020e578f009ead417029eff6cd0926110922db63ab98395e
3bdfdd5d8a65b1a2b8d495dc8c5e59b7f3518731f7dfc0f93ace5d
ee4b
u[1] = 1c4dc6653a445bbef2add81d8e90a6c8591a788deb91d0d3f1519a
2e4a460313041b77c1b0817f2e80b388e5c3e49f37d787dc1f85e4
324a
Q0.x = 9d355251e245e4b13ed4ea3e5a3c55bf9b7211f1704771f2e1d8f1
a65610c468b1cf70c6c2ce30dcaad54ad9e5439471ec554b862ec8
875a
Q0.y = 6689ba36a242af69ac2aadb955d15e982d9b04f5d77f7609ebf742
9587feb7e5ce27490b9c72114509f89565122074e46a614d7fd7c8
00bd
Q1.x = c4b3d3ad4d2d62739a62989532992c1081e9474a201085b4616da5
706cab824693b9fb428a201bcd1639a4588cc43b9eb841dbca7421
9b1f
Q1.y = 265286f5dee8f3d894b5649da8565b58e96b4cfd44b462a2883ea6
4dbcda21a00706ea3fea53fc2d769084b0b74589e91d0384d71189
09fb
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 987c5ac19dd4b47835466a50b2d9feba7c8491b8885a04edf577e1
5a9f2c98b203ec2cd3e5390b3d20bba0fa6fc3eecefb5029a31723
Faz-Hernandez, et al. Expires 17 December 2022 [Page 131]
Internet-Draft hash-to-curve June 2022
Barnes, et al. Expires 14 April 2022 [Page 76]
Internet-Draft MLS October 2021
This document does not define any way for the parameters of the group
to change once it has been created; such a behavior could be
implemented as an extension.
13. Sequencing of State Changes
Each Commit message is premised on a given starting state, indicated
by the epoch field of the enclosing MLSPlaintext message. If the
changes implied by a Commit messages are made starting from a
different state, the results will be incorrect.
This need for sequencing is not a problem as long as each time a
group member sends a Commit message, it is based on the most current
state of the group. In practice, however, there is a risk that two
members will generate Commit messages simultaneously, based on the
same state.
When this happens, there is a need for the members of the group to
deconflict the simultaneous Commit messages. There are two general
approaches:
* Have the Delivery Service enforce a total order
* Have a signal in the message that clients can use to break ties
As long as Commit messages cannot be merged, there is a risk of
starvation. In a sufficiently busy group, a given member may never
be able to send a Commit message, because he always loses to other
members. The degree to which this is a practical problem will depend
on the dynamics of the application.
It might be possible, because of the non-contributivity of
intermediate nodes, that Commit messages could be applied one after
the other without the Delivery Service having to reject any Commit
message, which would make MLS more resilient regarding the
concurrency of Commit messages. The Messaging system can decide to
choose the order for applying the state changes. Note that there are
certain cases (if no total ordering is applied by the Delivery
Service) where the ordering is important for security, ie. all
updates must be executed before removes.
Regardless of how messages are kept in sequence, implementations MUST
only update their cryptographic state when valid Commit messages are
received. Generation of Commit messages MUST NOT modify a client's
state, since the endpoint doesn't know at that time whether the
changes implied by the Commit message will succeed or not.
Barnes, et al. Expires 14 April 2022 [Page 77]
Internet-Draft MLS October 2021
13.1. Server-Enforced Ordering
With this approach, the Delivery Service ensures that incoming
messages are added to an ordered queue and outgoing messages are
dispatched in the same order. The server is trusted to break ties
when two members send a Commit message at the same time.
Messages should have a counter field sent in clear-text that can be
checked by the server and used for tie-breaking. The counter starts
at 0 and is incremented for every new incoming message. If two group
members send a message with the same counter, the first message to
arrive will be accepted by the server and the second one will be
rejected. The rejected message needs to be sent again with the
correct counter number.
To prevent counter manipulation by the server, the counter's
integrity can be ensured by including the counter in a signed message
envelope.
This applies to all messages, not only state changing messages.
13.2. Client-Enforced Ordering
Order enforcement can be implemented on the client as well, one way
to achieve it is to use a two step update protocol: the first client
sends a proposal to update and the proposal is accepted when it gets
50%+ approval from the rest of the group, then it sends the approved
update. Clients which didn't get their proposal accepted, will wait
for the winner to send their update before retrying new proposals.
While this seems safer as it doesn't rely on the server, it is more
complex and harder to implement. It also could cause starvation for
some clients if they keep failing to get their proposal accepted.
14. Application Messages
The primary purpose of the Handshake protocol is to provide an
authenticated group key exchange to clients. In order to protect
Application messages sent among the members of a group, the
Application secret provided by the Handshake key schedule is used to
derive nonces and encryption keys for the Message Protection Layer
according to the Application Key Schedule. That is, each epoch is
equipped with a fresh Application Key Schedule which consist of a
tree of Application Secrets as well as one symmetric ratchet per
group member.
Barnes, et al. Expires 14 April 2022 [Page 78]
Internet-Draft MLS October 2021
Each client maintains their own local copy of the Application Key
Schedule for each epoch during which they are a group member. They
derive new keys, nonces and secrets as needed while deleting old ones
as soon as they have been used.
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite using the common framing mechanism. Note
that "Authenticated" in this context does not mean messages are known
to be sent by a specific client but only from a legitimate member of
the group. To authenticate a message from a particular member,
signatures are required. Handshake messages MUST use asymmetric
signatures to strongly authenticate the sender of a message.
14.1. Message Encryption and Decryption
The group members MUST use the AEAD algorithm associated with the
negotiated MLS ciphersuite to AEAD encrypt and decrypt their
Application messages according to the Message Framing section.
The group identifier and epoch allow a recipient to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys. The sender identifier is used to identify
the member's symmetric ratchet from the initial group Application
secret. The application generation field is used to determine how
far into the ratchet to iterate in order to reproduce the required
AEAD keys and nonce for performing decryption.
Application messages SHOULD be padded to provide some resistance
against traffic analysis techniques over encrypted traffic. [CLINIC]
[HCJ16] While MLS might deliver the same payload less frequently
across a lot of ciphertexts than traditional web servers, it might
still provide the attacker enough information to mount an attack. If
Alice asks Bob: "When are we going to the movie ?" the answer
"Wednesday" might be leaked to an adversary by the ciphertext length.
An attacker expecting Alice to answer Bob with a day of the week
might find out the plaintext by correlation between the question and
the length.
Similarly to TLS 1.3, if padding is used, the MLS messages MUST be
padded with zero-valued bytes before AEAD encryption. Upon AEAD
decryption, the length field of the plaintext is used to compute the
number of bytes to be removed from the plaintext to get the correct
data. As the padding mechanism is used to improve protection against
traffic analysis, removal of the padding SHOULD be implemented in a
"constant-time" manner at the MLS layer and above layers to prevent
timing side-channels that would provide attackers with information on
the size of the plaintext. The padding length length_of_padding can
Barnes, et al. Expires 14 April 2022 [Page 79]
Internet-Draft MLS October 2021
be chosen at the time of the message encryption by the sender.
Recipients can calculate the padding size from knowing the total size
of the ApplicationPlaintext and the length of the content.
14.2. Restrictions
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used.
Note that each change to the Group through a Handshake message will
also set a new encryption_secret. Hence this change MUST be applied
before encrypting any new application message. This is required both
to ensure that any users removed from the group can no longer receive
messages and to (potentially) recover confidentiality and
authenticity for future messages despite a past state compromise.
14.3. Delayed and Reordered Application messages
Since each Application message contains the group identifier, the
epoch and a message counter, a client can receive messages out of
order. If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material clients
can decrypt these messages.
For usability, MLS clients might be required to keep the AEAD key and
nonce for a certain amount of time to retain the ability to decrypt
delayed or out of order messages, possibly still in transit while a
decryption is being done.
15. Security Considerations
The security goals of MLS are described in
[I-D.ietf-mls-architecture]. We describe here how the protocol
achieves its goals at a high level, though a complete security
analysis is outside of the scope of this document.
15.1. Confidentiality of the Group Secrets
Group secrets are partly derived from the output of a ratchet tree.
Ratchet trees work by assigning each member of the group to a leaf in
the tree and maintaining the following property: the private key of a
node in the tree is known only to members of the group that are
assigned a leaf in the node's subtree. This is called the _ratchet
tree invariant_ and it makes it possible to encrypt to all group
members except one, with a number of ciphertexts that's logarithmic
in the number of group members.
Barnes, et al. Expires 14 April 2022 [Page 80]
Internet-Draft MLS October 2021
The ability to efficiently encrypt to all members except one allows
members to be securely removed from a group. It also allows a member
to rotate their keypair such that the old private key can no longer
be used to decrypt new messages.
15.2. Authentication
The first form of authentication we provide is that group members can
verify a message originated from one of the members of the group.
For encrypted messages, this is guaranteed because messages are
encrypted with an AEAD under a key derived from the group secrets.
For plaintext messages, this is guaranteed by the use of a
membership_tag which constitutes a MAC over the message, under a key
derived from the group secrets.
The second form of authentication is that group members can verify a
message originated from a particular member of the group. This is
guaranteed by a digital signature on each message from the sender's
signature key.
The signature keys held by group members are critical to the security
of MLS against active attacks. If a member's signature key is
compromised, then an attacker can create KeyPackages impersonating
the member; depending on the application, this can then allow the
attacker to join the group with the compromised member's identity.
For example, if a group has enabled external parties to join via
external commits, then an attacker that has compromised a member's
signature key could use an external commit to insert themselves into
the group -- even using a "resync"-style external commit to replace
the compromised member in the group.
Applications can mitigate the risks of signature key compromise using
pre-shared keys. If a group requires joiners to know a PSK in
addition to authenticating with a credential, then in order to mount
an impersonation attack, the attacker would need to compromise the
relevant PSK as well as the victim's signature key. The cost of this
mitigation is that the application needs some external arrangement
that ensures that the legitimate members of the group to have the
required PSKs.
15.3. Forward Secrecy and Post-Compromise Security
Post-compromise security is provided between epochs by members
regularly updating their leaf key in the ratchet tree. Updating
their leaf key prevents group secrets from continuing to be encrypted
to previously compromised public keys.
Barnes, et al. Expires 14 April 2022 [Page 81]
Internet-Draft MLS October 2021
Forward-secrecy between epochs is provided by deleting private keys
from past version of the ratchet tree, as this prevents old group
secrets from being re-derived. Forward secrecy _within_ an epoch is
provided by deleting message encryption keys once they've been used
to encrypt or decrypt a message.
Post-compromise security is also provided for new groups by members
regularly generating new InitKeys and uploading them to the Delivery
Service, such that compromised key material won't be used when the
member is added to a new group.
15.4. InitKey Reuse
InitKeys are intended to be used only once. That is, once an InitKey
has been used to introduce the corresponding client to a group, it
SHOULD be deleted from the InitKey publication system. Reuse of
InitKeys can lead to replay attacks.
An application MAY allow for reuse of a "last resort&4401
P.y = 5e273fcfff6b007bb6771e90509275a71ff1480c459ded26fc7b10
664db0a68aaa98bc7ecb07e49cf05b80ae5ac653fbdd14276bbd35
ccbc
u[0] = 163c79ab0210a4b5e4f44fb19437ea965bf5431ab233ef16606f0b
03c5f16a3feb7d46a5a675ce8f606e9c2bf74ee5336c54a1e54919
f13f
u[1] = f99666bde4995c4088333d6c2734687e815f80a99c6da02c47df4b
51f6c9d9ed466b4fecf7d9884990a8e0d0be6907fa437e0b1a27f4
9265
Q0.x = d1a5eba4a332514b69760948af09ceaeddbbb9fd4cb1f19b78349c
2ee4cf9ee86dbcf9064659a4a0566fe9c34d90aec86f0801edc131
ad9b
Q0.y = 5d0a75a3014c3269c33b1b5da80706a4f097893461df286353484d
8031cd607c98edc2a846c77a841f057c7251eb45077853c7b20595
7e52
Q1.x = 69583b00dc6b2aced6ffa44630cc8c8cd0dd0649f57588dd0fb1da
ad2ce132e281d01e3f25ccd3f405be759975c6484268bfe8f5e5f2
3c30
Q1.y = 8418484035f60bdccf48cb488634c2dfb40272123435f7e654fb6f
254c6c42e7e38f1fa79a637a168a28de6c275232b704f9ded0ff76
dd94
J.7.2. edwards448_XOF:SHAKE256_ELL2_NU_
suite = edwards448_XOF:SHAKE256_ELL2_NU_
dst = QUUX-V01-CS02-with-edwards448_XOF:SHAKE256_ELL2_NU_
msg =
P.x = eb5a1fc376fd73230af2de0f3374087cc7f279f0460114cf0a6c12
d6d044c16de34ec2350c34b26bf110377655ab77936869d085406a
f71e
P.y = df5dcea6d42e8f494b279a500d09e895d26ac703d75ca6d118e8ca
58bf6f608a2a383f292fce1563ff995dce75aede1fdc8e7c0c737a
e9ad
u[0] = 1368aefc0416867ea2cfc515416bcbeecc9ec81c4ecbd52ccdb91e
06996b3f359bc930eef6743c7a2dd7adb785bc7093ed044efed950
86d7
Q.x = 4b2abf8c0fca49d027c2a81bf73bb5990e05f3e76c7ba137cc0b89
415ccd55ce7f191cc0c11b0560c1cdc2a8085dd56996079e05a3cd
8dde
Q.y = 82532f5b0cb3bfb8542d3228d055bfe61129dbeae8bace80cf61f1
7725e8ec8226a24f0e687f78f01da88e3b2715194a03dca7c0a96b
bf04
msg = abc
P.x = 4623a64bceaba3202df76cd8b6e3daf70164f3fcbda6d6e340f7fa
b5cdf89140d955f722524f5fe4d968fef6ba2853ff4ea086c2f67d
Faz-Hernandez, et al. Expires 17 December 2022 [Page 132]
Internet-Draft hash-to-curve June 2022
8110
P.y = abaac321a169761a8802ab5b5d10061fec1a83c670ac6bc9595470
0317ee5f82870120e0e2c5a21b12a0c7ad17ebd343363604c4bcec
afd1
u[0] = cda3b0ecfe054c4077007d7300969ec24f4c741300b630ec9188eb
ab31a5ae0065612ee22d9f793733179ffc2e10c53ca5b539057aaf
dc2f
Q.x = b1ca5bef2f157673a210f56c9b0039db8399e4749585abac64f831
f74ed1ec5f591928976c687c06d57686bacb98440e77af878349cd
f2d2
Q.y = 5bbfd6a3730d517b03c3cd9e2eed94af12891334ec090e0495c2ed
c588e9e10b6f63b03a62076808cbcd6da95adfb5af76c136b2d42e
0dac
msg = abcdef0123456789
P.x = e9eb562e76db093baa43a31b7edd04ec4aadcef3389a7b9c58a19c
f87f8ae3d154e134b6b3ed45847a741e33df51903da681629a4b8b
cc2e
P.y = 0cf6606927ad7eb15dbc193993bc7e4dda744b311a8ec4274c8f73
8f74f605934582474c79260f60280fe35bd37d4347e59184cbfa12
cbc4
u[0] = d36bae98351512c382c7a3e1eba22497574f11fef9867901b1a270
0b39fa2cd0d38ed4380387a99162b7ba0240c743f0532ef60d577c
413d
Q.x = 958a51e2f02e0dfd3930709010d5d16f869adb9d8a8f7c01139911
d206c20cdb7bfb40ee33ba30536a99f49362fa7633d0f417fc3914
fe21
Q.y = f4307a36ab6612fa97501497f01afa109733ce85875935551c3ca9
0f0fa7e0097a8640bb7e5dbcc38ab32b23b748790f2261f2c44c3b
f3ba
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 122a3234d34b26c69749f23356452bf9501efa2d94859d5ef741fe
f024156d9d191a03a2ad24c38186f93e02d05572575968b083d8a3
9738
P.y = ddf55e74eb4414c2c1fa4aa6bc37c4ab470a3fed6bb5af1e435703
09b162fb61879bb15f9ea49c712efd42d0a71666430f9f0d4a2050
5050
u[0] = 5945744d27122f89da3daf76ab4db9616053df64e25d30ec9a0066
7ee6710240579c1db8f8ef3386f3f4f413cfb325ac14094d582026
a971
Q.x = e7e1f2d13548ac2c8fcd346e4c63606545bf93652011721e83ac3b
64226f77a8823d3881e164bc6ca45505b236e8e3721c028052fcc9
ade5
Q.y = 7e0f340501bf25f018b9d374c2acbdd43c07261d85a6ef3c855113
d4e023634db59a87b8fab9efe04ed1fee302c8a4994e83bdda32bd
Faz-Hernandez, et al. Expires 17 December 2022 [Page 133]
Internet-Draft hash-to-curve June 2022
9c0b
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 221704949b1ce1ab8dd174dc9b8c56fcffa27179569ce9219c0c2f
e183d3d23343a4c42a0e2e9d6b9d0feb1df3883ec489b6671d1fa6
4089
P.y = ebdecfdc87142d1a919034bf22ecfad934c9a85effff14b594ae2c
00943ca62a39d6ee3be9df0bb504ce8a9e1669bc6959c42ad6a1d3
b686
u[0] = 1192e378043f01cedc7ea0209321519213b0184ea0d8575816bcd9
182a367823e1eecc2faf1df8f79b24027a4b9bfa208cd320e79bef
06ea
Q.x = 0fd3bb833c1d7a5b319d1d4117406a23b9aece976186ecb18a11a6
35e6fbdb920d47e04762b1f2a8c59d2f8435d0fdefe501f544cda2
3dbf
Q.y = f13b0dad4d5eeb120f2443ac4392f8096a1396f5014ec2a3506a34
7fef8076a7282035cf619599b1919cf29df5ce87711c11688aab77
00a6
J.8. secp256k1
J.8.1. secp256k1_XMD:SHA-256_SSWU_RO_
suite = secp256k1_XMD:SHA-256_SSWU_RO_
dst = QUUX-V01-CS02-with-secp256k1_XMD:SHA-256_SSWU_RO_
msg =
P.x = c1cae290e291aee617ebaef1be6d73861479c48b841eaba9b7b585
2ddfeb1346
P.y = 64fa678e07ae116126f08b022a94af6de15985c996c3a91b64c406
a960e51067
u[0] = 6b0f9910dd2ba71c78f2ee9f04d73b5f4c5f7fc773a701abea1e57
3cab002fb3
u[1] = 1ae6c212e08fe1a5937f6202f929a2cc8ef4ee5b9782db68b0d579
9fd8f09e16
Q0.x = 74519ef88b32b425a095e4ebcc84d81b64e9e2c2675340a720bb1a
1857b99f1e
Q0.y = c174fa322ab7c192e11748beed45b508e9fdb1ce046dee9c2cd3a2
a86b410936
Faz-Hernandez, et al. Expires 17 December 2022 [Page 134]
Internet-Draft hash-to-curve June 2022
Q1.x = 44548adb1b399263ded3510554d28b4bead34b8cf9a37b4bd0bd2b
a4db87ae63
Q1.y = 96eb8e2faf05e368efe5957c6167001760233e6dd2487516b46ae7
25c4cce0c6
msg = abc
P.x = 3377e01eab42db296b512293120c6cee72b6ecf9f9205760bd9ff1
1fb3cb2c4b
P.y = 7f95890f33efebd1044d382a01b1bee0900fb6116f94688d487c6c
7b9c8371f6
u[0] = 128aab5d3679a1f7601e3bdf94ced1f43e491f544767e18a4873f3
97b08a2b61
u[1] = 5897b65da3b595a813d0fdcc75c895dc531be76a03518b044daaa0
f2e4689e00
Q0.x = 07dd9432d426845fb19857d1b3a91722436604ccbbbadad8523b8f
c38a5322d7
Q0.y = 604588ef5138cffe3277bbd590b8550bcbe0e523bbaf1bed4014a4
67122eb33f
Q1.x = e9ef9794d15d4e77dde751e06c182782046b8dac05f8491eb88764
fc65321f78
Q1.y = cb07ce53670d5314bf236ee2c871455c562dd76314aa41f012919f
e8e7f717b3
msg = abcdef0123456789
P.x = bac54083f293f1fe08e4a70137260aa90783a5cb84d3f35848b324
d0674b0e3a
P.y = 4436476085d4c3c4508b60fcf4389c40176adce756b398bdee27bc
a19758d828
u[0] = ea67a7c02f2cd5d8b87715c169d055a22520f74daeb080e6180958
380e2f98b9
u[1] = 7434d0d1a500d38380d1f9615c021857ac8d546925f5f2355319d8
23a478da18
Q0.x = 576d43ab0260275adf11af990d130a5752704f7947862876172080
8862544b5d
Q0.y = 643c4a7fb68ae6cff55edd66b809087434bbaff0c07f3f9ec4d49b
b3c16623c3
Q1.x = f89d6d261a5e00fe5cf45e827b507643e67c2a947a20fd9ad71039
f8b0e29ff8
Q1.y = b33855e0cc34a9176ead91c6c3acb1aacb1ce936d563bc1cee1dcf
fc806caf57
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = e2167bc785333a37aa562f021f1e881defb853839babf52a7f72b1
02e41890e9
P.y = f2401dd95cc35867ffed4f367cd564763719fbc6a53e969fb8496a
1e6685d873
Faz-Hernandez, et al. Expires 17 December 2022 [Page 135]
Internet-Draft hash-to-curve June 2022
u[0] = eda89a5024fac0a8207a87e8cc4e85aa3bce10745d501a30deb873
41b05bcdf5
u[1] = dfe78cd116818fc2c16f3837fedbe2639fab012c407eac9dfe9245
bf650ac51d
Q0.x = 9c91513ccfe9520c9c645588dff5f9b4e92eaf6ad4ab6f1cd720d1
92eb58247a
Q0.y = c7371dcd0134412f221e386f8d68f49e7fa36f9037676e163d4a06
3fbf8a1fb8
Q1.x = 10fee3284d7be6bd5912503b972fc52bf4761f47141a0015f1c6ae
36848d869b
Q1.y = 0b163d9b4bf21887364332be3eff3c870fa053cf508732900fc69a
6eb0e1b672
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = e3c8d35aaaf0b9b647e88a0a0a7ee5d5bed5ad38238152e4e6fd8c
1f8cb7c998
P.y = 8446eeb6181bf12f56a9d24e262221cc2f0c4725c7e3803024b588
8ee5823aa6
u[0] = 8d862e7e7e23d7843fe16d811d46d7e6480127a6b78838c277bca1
7df6900e9f
u[1] = 68071d2530f040f081ba818d3c7188a94c900586761e9115efa47a
e9bd847938
Q0.x = b32b0ab55977b936f1e93fdc68cec775e13245e161dbfe556bbb1f
72799b4181
Q0.y = 2f5317098360b722f132d7156a94822641b615c91f8663be691698
70a12af9e8
Q1.x = 148f98780f19388b9fa93e7dc567b5a673e5fca7079cd9cdafd719
82ec4c5e12
Q1.y = 3989645d83a433bc0c001f3dac29af861f33a6fd1e04f4b36873f5
bff497298a
J.8.2. secp256k1_XMD:SHA-256_SSWU_NU_
suite = secp256k1_XMD:SHA-256_SSWU_NU_
dst = QUUX-V01-CS02-with-secp256k1_XMD:SHA-256_SSWU_NU_
msg =
P.x = a4792346075feae77ac3b30026f99c1441b4ecf666ded19b7522cf
65c4c55c5b
Faz-Hernandez, et al. Expires 17 December 2022 [Page 136]
Internet-Draft hash-to-curve June 2022
P.y = 62c59e2a6aeed1b23be5883e833912b08ba06be7f57c0e9cdc663f
31639ff3a7
u[0] = 0137fcd23bc3da962e8808f97474d097a6c8aa2881fceef4514173
635872cf3b
Q.x = a4792346075feae77ac3b30026f99c1441b4ecf666ded19b7522cf
65c4c55c5b
Q.y = 62c59e2a6aeed1b23be5883e833912b08ba06be7f57c0e9cdc663f
31639ff3a7
msg = abc
P.x = 3f3b5842033fff837d504bb4ce2a372bfeadbdbd84a1d2b678b6e1
d7ee426b9d
P.y = 902910d1fef15d8ae2006fc84f2a5a7bda0e0407dc913062c3a493
c4f5d876a5
u[0] = e03f894b4d7caf1a50d6aa45cac27412c8867a25489e32c5ddeb50
3229f63a2e
Q.x = 3f3b5842033fff837d504bb4ce2a372bfeadbdbd84a1d2b678b6e1
d7ee426b9d
Q.y = 902910d1fef15d8ae2006fc84f2a5a7bda0e0407dc913062c3a493
c4f5d876a5
msg = abcdef0123456789
P.x = 07644fa6281c694709f53bdd21bed94dab995671e4a8cd1904ec4a
a50c59bfdf
P.y = c79f8d1dad79b6540426922f7fbc9579c3018dafeffcd4552b1626
b506c21e7b
u[0] = e7a6525ae7069ff43498f7f508b41c57f80563c1fe4283510b3224
46f32af41b
Q.x = 07644fa6281c694709f53bdd21bed94dab995671e4a8cd1904ec4a
a50c59bfdf
Q.y = c79f8d1dad79b6540426922f7fbc9579c3018dafeffcd4552b1626
b506c21e7b
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = b734f05e9b9709ab631d960fa26d669c4aeaea64ae62004b9d34f4
83aa9acc33
P.y = 03fc8a4a5a78632e2eb4d8460d69ff33c1d72574b79a35e402e801
f2d0b1d6ee
u[0] = d97cf3d176a2f26b9614a704d7d434739d194226a706c886c5c3c3
9806bc323c
Q.x = b734f05e9b9709ab631d960fa26d669c4aeaea64ae62004b9d34f4
83aa9acc33
Q.y = 03fc8a4a5a78632e2eb4d8460d69ff33c1d72574b79a35e402e801
f2d0b1d6ee
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 137]
Internet-Draft hash-to-curve June 2022
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 17d22b867658977b5002dbe8d0ee70a8cfddec3eec50fb93f36136
070fd9fa6c
P.y = e9178ff02f4dab73480f8dd590328aea99856a7b6cc8e5a6cdf289
ecc2a51718
u[0] = a9ffbeee1d6e41ac33c248fb3364612ff591b502386c1bf6ac4aaf
1ea51f8c3b
Q.x = 17d22b867658977b5002dbe8d0ee70a8cfddec3eec50fb93f36136
070fd9fa6c
Q.y = e9178ff02f4dab73480f8dd590328aea99856a7b6cc8e5a6cdf289
ecc2a51718
J.9. BLS12-381 G1
J.9.1. BLS12381G1_XMD:SHA-256_SSWU_RO_
suite = BLS12381G1_XMD:SHA-256_SSWU_RO_
dst = QUUX-V01-CS02-with-BLS12381G1_XMD:SHA-256_SSWU_RO_
msg =
P.x = 052926add2207b76ca4fa57a8734416c8dc95e24501772c8142787
00eed6d1e4e8cf62d9c09db0fac349612b759e79a1
P.y = 08ba738453bfed09cb546dbb0783dbb3a5f1f566ed67bb6be0e8c6
7e2e81a4cc68ee29813bb7994998f3eae0c9c6a265
u[0] = 0ba14bd907ad64a016293ee7c2d276b8eae71f25a4b941eece7b0d
89f17f75cb3ae5438a614fb61d6835ad59f29c564f
u[1] = 019b9bd7979f12657976de2884c7cce192b82c177c80e0ec604436
a7f538d231552f0d96d9f7babe5fa3b19b3ff25ac9
Q0.x = 11a3cce7e1d90975990066b2f2643b9540fa40d6137780df4e753a
8054d07580db3b7f1f03396333d4a359d1fe3766fe
Q0.y = 0eeaf6d794e479e270da10fdaf768db4c96b650a74518fc67b04b0
3927754bac66f3ac720404f339ecdcc028afa091b7
Q1.x = 160003aaf1632b13396dbad518effa00fff532f604de1a7fc2082f
f4cb0afa2d63b2c32da1bef2bf6c5ca62dc6b72f9c
Q1.y = 0d8bb2d14e20cf9f6036152ed386d79189415b6d015a20133acb4e
019139b94e9c146aaad5817f866c95d609a361735e
msg = abc
P.x = 03567bc5ef9c690c2ab2ecdf6a96ef1c139cc0b2f284dca0a9a794
3388a49a3aee664ba5379a7655d3c68900be2f6903
Faz-Hernandez, et al. Expires 17 December 2022 [Page 138]
Internet-Draft hash-to-curve June 2022
P.y = 0b9c15f3fe6e5cf4211f346271d7b01c8f3b28be689c8429c85b67
af215533311f0b8dfaaa154fa6b88176c229f2885d
u[0] = 0d921c33f2bad966478a03ca35d05719bdf92d347557ea166e5bba
579eea9b83e9afa5c088573c2281410369fbd32951
u[1] = 003574a00b109ada2f26a37a91f9d1e740dffd8d69ec0c35e1e9f4
652c7dba61123e9dd2e76c655d956e2b3462611139
Q0.x = 125435adce8e1cbd1c803e7123f45392dc6e326d292499c2c45c58
65985fd74fe8f042ecdeeec5ecac80680d04317d80
Q0.y = 0e8828948c989126595ee30e4f7c931cbd6f4570735624fd25aef2
fa41d3f79cfb4b4ee7b7e55a8ce013af2a5ba20bf2
Q1.x = 11def93719829ecda3b46aa8c31fc3ac9c34b428982b898369608e
4f042babee6c77ab9218aad5c87ba785481eff8ae4
Q1.y = 0007c9cef122ccf2efd233d6eb9bfc680aa276652b0661f4f820a6
53cec1db7ff69899f8e52b8e92b025a12c822a6ce6
msg = abcdef0123456789
P.x = 11e0b079dea29a68f0383ee94fed1b940995272407e3bb916bbf26
8c263ddd57a6a27200a784cbc248e84f357ce82d98
P.y = 03a87ae2caf14e8ee52e51fa2ed8eefe80f02457004ba4d486d6aa
1f517c0889501dc7413753f9599b099ebcbbd2d709
u[0] = 062d1865eb80ebfa73dcfc45db1ad4266b9f3a93219976a3790ab8
d52d3e5f1e62f3b01795e36834b17b70e7b76246d4
u[1] = 0cdc3e2f271f29c4ff75020857ce6c5d36008c9b48385ea2f2bf6f
96f428a3deb798aa033cd482d1cdc8b30178b08e3a
Q0.x = 08834484878c217682f6d09a4b51444802fdba3d7f2df9903a0dda
db92130ebbfa807fffa0eabf257d7b48272410afff
Q0.y = 0b318f7ecf77f45a0f038e62d7098221d2dbbca2a394164e2e3fe9
53dc714ac2cde412d8f2d7f0c03b259e6795a2508e
Q1.x = 158418ed6b27e2549f05531a8281b5822b31c3bf3144277fbb977f
8d6e2694fedceb7011b3c2b192f23e2a44b2bd106e
Q1.y = 1879074f344471fac5f839e2b4920789643c075792bec5af4282c7
3f7941cda5aa77b00085eb10e206171b9787c4169f
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 15f68eaa693b95ccb85215dc65fa81038d69629f70aeee0d0f677c
f22285e7bf58d7cb86eefe8f2e9bc3f8cb84fac488
P.y = 1807a1d50c29f430b8cafc4f8638dfeeadf51211e1602a5f184443
076715f91bb90a48ba1e370edce6ae1062f5e6dd38
u[0] = 010476f6a060453c0b1ad0b628f3e57c23039ee16eea5e71bb87c3
b5419b1255dc0e5883322e563b84a29543823c0e86
u[1] = 0b1a912064fb0554b180e07af7e787f1f883a0470759c03c1b6509
eb8ce980d1670305ae7b928226bb58fdc0a419f46e
Q0.x = 0cbd7f84ad2c99643fea7a7ac8f52d63d66cefa06d9a56148e58b9
84b3dd25e1f41ff47154543343949c64f88d48a710
Q0.y = 052c00e4ed52d000d94881a5638ae9274d3efc8bc77bc0e5c650de
04a000b2c334a9e80b85282a00f3148dfdface0865
Faz-Hernandez, et al. Expires 17 December 2022 [Page 139]
Internet-Draft hash-to-curve June 2022
Q1.x = 06493fb68f0d513af08be0372f849436a787e7b701ae31cb964d96
8021d6ba6bd7d26a38aaa5a68e8c21a6b17dc8b579
Q1.y = 02e98f2ccf5802b05ffaac7c20018bc0c0b2fd580216c4aa2275d2
909dc0c92d0d0bdc979226adeb57a29933536b6bb4
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 082aabae8b7dedb0e78aeb619ad3bfd9277a2f77ba7fad20ef6aab
dc6c31d19ba5a6d12283553294c1825c4b3ca2dcfe
P.y = 05b84ae5a942248eea39e1d91030458c40153f3b654ab7872d779a
d1e942856a20c438e8d99bc8abfbf74729ce1f7ac8
u[0] = 0a8ffa7447f6be1c5a2ea4b959c9454b431e29ccc0802bc052413a
9c5b4f9aac67a93431bd480d15be1e057c8a08e8c6
u[1] = 05d487032f602c90fa7625dbafe0f4a49ef4a6b0b33d7bb349ff4c
f5410d297fd6241876e3e77b651cfc8191e40a68b7
Q0.x = 0cf97e6dbd0947857f3e578231d07b309c622ade08f2c08b32ff37
2bd90db19467b2563cc997d4407968d4ac80e154f8
Q0.y = 127f0cddf2613058101a5701f4cb9d0861fd6c2a1b8e0afe194fcc
f586a3201a53874a2761a9ab6d7220c68661a35ab3
Q1.x = 092f1acfa62b05f95884c6791fba989bbe58044ee6355d100973bf
9553ade52b47929264e6ae770fb264582d8dce512a
Q1.y = 028e6d0169a72cfedb737be45db6c401d3adfb12c58c619c82b93a
5dfcccef12290de530b0480575ddc8397cda0bbebf
J.9.2. BLS12381G1_XMD:SHA-256_SSWU_NU_
suite = BLS12381G1_XMD:SHA-256_SSWU_NU_
dst = QUUX-V01-CS02-with-BLS12381G1_XMD:SHA-256_SSWU_NU_
msg =
P.x = 184bb665c37ff561a89ec2122dd343f20e0f4cbcaec84e3c3052ea
81d1834e192c426074b02ed3dca4e7676ce4ce48ba
P.y = 04407b8d35af4dacc809927071fc0405218f1401a6d15af775810e
4e460064bcc9468beeba82fdc751be70476c888bf3
u[0] = 156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e2
5e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f03
Q.x = 11398d3b324810a1b093f8e35aa8571cced95858207e7f49c4fd74
656096d61d8a2f9a23cdb18a4dd11cd1d66f41f709
Q.y = 19316b6fb2ba7717355d5d66a361899057e1e84a6823039efc7bec
cefe09d023fb2713b1c415fcf278eb0c39a89b4f72
Faz-Hernandez, et al. Expires 17 December 2022 [Page 140]
Internet-Draft hash-to-curve June 2022
msg = abc
P.x = 009769f3ab59bfd551d53a5f846b9984c59b97d6842b20a2c565ba
a167945e3d026a3755b6345df8ec7e6acb6868ae6d
P.y = 1532c00cf61aa3d0ce3e5aa20c3b531a2abd2c770a790a26138183
03c6b830ffc0ecf6c357af3317b9575c567f11cd2c
u[0] = 147e1ed29f06e4c5079b9d14fc89d2820d32419b990c1c7bb7dbea
2a36a045124b31ffbde7c99329c05c559af1c6cc82
Q.x = 1998321bc27ff6d71df3051b5aec12ff47363d81a5e9d2dff55f44
4f6ca7e7d6af45c56fd029c58237c266ef5cda5254
Q.y = 034d274476c6307ae584f951c82e7ea85b84f72d28f4d647173235
6121af8d62a49bc263e8eb913a6cf6f125995514ee
msg = abcdef0123456789
P.x = 1974dbb8e6b5d20b84df7e625e2fbfecb2cdb5f77d5eae5fb2955e
5ce7313cae8364bc2fff520a6c25619739c6bdcb6a
P.y = 15f9897e11c6441eaa676de141c8d83c37aab8667173cbe1dfd6de
74d11861b961dccebcd9d289ac633455dfcc7013a3
u[0] = 04090815ad598a06897dd89bcda860f25837d54e897298ce31e694
7378134d3761dc59a572154963e8c954919ecfa82d
Q.x = 17d502fa43bd6a4cad2859049a0c3ecefd60240d129be65da271a4
c03a9c38fa78163b9d2a919d2beb57df7d609b4919
Q.y = 109019902ae93a8732abecf2ff7fecd2e4e305eb91f41c9c3267f1
6b6c19de138c7272947f25512745da6c466cdfd1ac
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 0a7a047c4a8397b3446450642c2ac64d7239b61872c9ae7a59707a
8f4f950f101e766afe58223b3bff3a19a7f754027c
P.y = 1383aebba1e4327ccff7cf9912bda0dbc77de048b71ef8c8a81111
d71dc33c5e3aa6edee9cf6f5fe525d50cc50b77cc9
u[0] = 08dccd088ca55b8bfbc96fb50bb25c592faa867a8bb78d4e94a8cc
2c92306190244532e91feba2b7fed977e3c3bb5a1f
Q.x = 112eb92dd2b3aa9cd38b08de4bef603f2f9fb0ca226030626a9a2e
47ad1e9847fe0a5ed13766c339e38f514bba143b21
Q.y = 17542ce2f8d0a54f2c5ba8c4b14e10b22d5bcd7bae2af3c965c8c8
72b571058c720eac448276c99967ded2bf124490e1
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Faz-Hernandez, et al. Expires 17 December 2022 [Page 141]
Internet-Draft hash-to-curve June 2022
P.x = 0e7a16a975904f131682edbb03d9560d3e48214c9986bd50417a77
108d13dc957500edf96462a3d01e62dc6cd468ef11
P.y = 0ae89e677711d05c30a48d6d75e76ca9fb70fe06c6dd6ff988683d
89ccde29ac7d46c53bb97a59b1901abf1db66052db
u[0] = 0dd824886d2123a96447f6c56e3a3fa992fbfefdba17b6673f9f63
0ff19e4d326529db37e1c1be43f905bf9202e0278d
Q.x = 1775d400a1bacc1c39c355da7e96d2d1c97baa9430c4a3476881f8
521c09a01f921f592607961efc99c4cd46bd78ca19
Q.y = 1109b5d59f65964315de65a7a143e86eabc053104ed289cf480949
317a5685fad7254ff8e7fe6d24d3104e5d55ad6370
J.10. BLS12-381 G2
J.10.1. BLS12381G2_XMD:SHA-256_SSWU_RO_
suite = BLS12381G2_XMD:SHA-256_SSWU_RO_
dst = QUUX-V01-CS02-with-BLS12381G2_XMD:SHA-256_SSWU_RO_
msg =
P.x = 0141ebfbdca40eb85b87142e130ab689c673cf60f1a3e98d693352
66f30d9b8d4ac44c1038e9dcdd5393faf5c41fb78a
+ I * 05cb8437535e20ecffaef7752baddf98034139c38452458baeefab
379ba13dff5bf5dd71b72418717047f5b0f37da03d
P.y = 0503921d7f6a12805e72940b963c0cf3471c7b2a524950ca195d11
062ee75ec076daf2d4bc358c4b190c0c98064fdd92
+ I * 12424ac32561493f3fe3c260708a12b7c620e7be00099a974e259d
dc7d1f6395c3c811cdd19f1e8dbf3e9ecfdcbab8d6
u[0] = 03dbc2cce174e91ba93cbb08f26b917f98194a2ea08d1cce75b2b9
cc9f21689d80bd79b594a613d0a68eb807dfdc1cf8
+ I * 05a2acec64114845711a54199ea339abd125ba38253b70a92c876d
f10598bd1986b739cad67961eb94f7076511b3b39a
u[1] = 02f99798e8a5acdeed60d7e18e9120521ba1f47ec090984662846b
c825de191b5b7641148c0dbc237726a334473eee94
+ I * 145a81e418d4010cc027a68f14391b30074e89e60ee7a22f87217b
2f6eb0c4b94c9115b436e6fa4607e95a98de30a435
Q0.x = 019ad3fc9c72425a998d7ab1ea0e646a1f6093444fc6965f1cad5a
3195a7b1e099c050d57f45e3fa191cc6d75ed7458c
+ I * 171c88b0b0efb5eb2b88913a9e74fe111a4f68867b59db252ce586
8af4d1254bfab77ebde5d61cd1a86fb2fe4a5a1c1d
Q0.y = 0ba10604e62bdd9eeeb4156652066167b72c8d743b050fb4c1016c
31b505129374f76e03fa127d6a156213576910fef3
+ I * 0eb22c7a543d3d376e9716a49b72e79a89c9bfe9feee8533ed931c
bb5373dde1fbcd7411d8052e02693654f71e15410a
Q1.x = 113d2b9cd4bd98aee53470b27abc658d91b47a78a51584f3d4b950
677cfb8a3e99c24222c406128c91296ef6b45608be
+ I * 13855912321c5cb793e9d1e88f6f8d342d49c0b0dbac613ee9e17e
3c0b3c97dfbb5a49cc3fb45102fdbaf65e0efe2632
Q1.y = 0fd3def0b7574a1d801be44fde617162aa2e89da47f464317d9bb5
Faz-Hernandez, et al. Expires 17 December 2022 [Page 142]
Internet-Draft hash-to-curve June 2022
abc3a7071763ce74180883ad7ad9a723a9afafcdca
+ I * 056f617902b3c0d0f78a9a8cbda43a26b65f602f8786540b9469b0
60db7b38417915b413ca65f875c130bebfaa59790c
msg = abc
P.x = 02c2d18e033b960562aae3cab37a27ce00d80ccd5ba4b7fe0e7a21
0245129dbec7780ccc7954725f4168aff2787776e6
+ I * 139cddbccdc5e91b9623efd38c49f81a6f83f175e80b06fc374de9
eb4b41dfe4ca3a230ed250fbe3a2acf73a41177fd8
P.y = 1787327b68159716a37440985269cf584bcb1e621d3a7202be6ea0
5c4cfe244aeb197642555a0645fb87bf7466b2ba48
+ I * 00aa65dae3c8d732d10ecd2c50f8a1baf3001578f71c694e03866e
9f3d49ac1e1ce70dd94a733534f106d4cec0eddd16
u[0] = 15f7c0aa8f6b296ab5ff9c2c7581ade64f4ee6f1bf18f55179ff44
a2cf355fa53dd2a2158c5ecb17d7c52f63e7195771
+ I * 01c8067bf4c0ba709aa8b9abc3d1cef589a4758e09ef53732d670f
d8739a7274e111ba2fcaa71b3d33df2a3a0c8529dd
u[1] = 187111d5e088b6b9acfdfad078c4dacf72dcd17ca17c82be35e79f
8c372a693f60a033b461d81b025864a0ad051a06e4
+ I * 08b852331c96ed983e497ebc6dee9b75e373d923b729194af8e72a
051ea586f3538a6ebb1e80881a082fa2b24df9f566
Q0.x = 12b2e525281b5f4d2276954e84ac4f42cf4e13b6ac4228624e1776
0faf94ce5706d53f0ca1952f1c5ef75239aeed55ad
+ I * 05d8a724db78e570e34100c0bc4a5fa84ad5839359b40398151f37
cff5a51de945c563463c9efbdda569850ee5a53e77
Q0.y = 02eacdc556d0bdb5d18d22f23dcb086dd106cad713777c7e640794
3edbe0b3d1efe391eedf11e977fac55f9b94f2489c
+ I * 04bbe48bfd5814648d0b9e30f0717b34015d45a861425fabc1ee06
fdfce36384ae2c808185e693ae97dcde118f34de41
Q1.x = 19f18cc5ec0c2f055e47c802acc3b0e40c337256a208001dde14b2
5afced146f37ea3d3ce16834c78175b3ed61f3c537
+ I * 15b0dadc256a258b4c68ea43605dffa6d312eef215c19e6474b3e1
01d33b661dfee43b51abbf96fee68fc6043ac56a58
Q1.y = 05e47c1781286e61c7ade887512bd9c2cb9f640d3be9cf87ea0bad
24bd0ebfe946497b48a581ab6c7d4ca74b5147287f
+ I * 19f98db2f4a1fcdf56a9ced7b320ea9deecf57c8e59236b0dc21f6
ee7229aa9705ce9ac7fe7a31c72edca0d92370c096
msg = abcdef0123456789
P.x = 121982811d2491fde9ba7ed31ef9ca474f0e1501297f68c298e9f4
c0028add35aea8bb83d53c08cfc007c1e005723cd0
+ I * 190d119345b94fbd15497bcba94ecf7db2cbfd1e1fe7da034d26cb
ba169fb3968288b3fafb265f9ebd380512a71c3f2c
P.y = 05571a0f8d3c08d094576981f4a3b8eda0a8e771fcdcc8ecceaf13
56a6acf17574518acb506e435b639353c2e14827c8
+ I * 0bb5e7572275c567462d91807de765611490205a941a5a6af3b169
1bfe596c31225d3aabdf15faff860cb4ef17c7c3be
u[0] = 0313d9325081b415bfd4e5364efaef392ecf69b087496973b22930
Faz-Hernandez, et al. Expires 17 December 2022 [Page 143]
Internet-Draft hash-to-curve June 2022
3e1816d2080971470f7da112c4eb43053130b785e1
+ I * 062f84cb21ed89406890c051a0e8b9cf6c575cf6e8e18ecf63ba86
826b0ae02548d83b483b79e48512b82a6c0686df8f
u[1] = 1739123845406baa7be5c5dc74492051b6d42504de008c635f3535
bb831d478a341420e67dcc7b46b2e8cba5379cca97
+ I * 01897665d9cb5db16a27657760bbea7951f67ad68f8d55f7113f24
ba6ddd82caef240a9bfa627972279974894701d975
Q0.x = 0f48f1ea1318ddb713697708f7327781fb39718971d72a9245b973
1faaca4dbaa7cca433d6c434a820c28b18e20ea208
+ I * 06051467c8f85da5ba2540974758f7a1e0239a5981de441fdd8768
0a995649c211054869c50edbac1f3a86c561ba3162
Q0.y = 168b3d6df80069dbbedb714d41b32961ad064c227355e1ce5fac8e
105de5e49d77f0c64867f3834848f152497eb76333
+ I * 134e0e8331cee8cb12f9c2d0742714ed9eee78a84d634c9a95f6a7
391b37125ed48bfc6e90bf3546e99930ff67cc97bc
Q1.x = 004fd03968cd1c99a0dd84551f44c206c84dcbdb78076c5bfee24e
89a92c8508b52b88b68a92258403cbe1ea2da3495f
+ I * 1674338ea298281b636b2eb0fe593008d03171195fd6dcd4531e8a
1ed1f02a72da238a17a635de307d7d24aa2d969a47
Q1.y = 0dc7fa13fff6b12558419e0a1e94bfc3cfaf67238009991c5f24ee
94b632c3d09e27eca329989aee348a67b50d5e236c
+ I * 169585e164c131103d85324f2d7747b23b91d66ae5d947c449c819
4a347969fc6bbd967729768da485ba71868df8aed2
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 19a84dd7248a1066f737cc34502ee5555bd3c19f2ecdb3c7d9e24d
c65d4e25e50d83f0f77105e955d78f4762d33c17da
+ I * 0934aba516a52d8ae479939a91998299c76d39cc0c035cd18813be
c433f587e2d7a4fef038260eef0cef4d02aae3eb91
P.y = 14f81cd421617428bc3b9fe25afbb751d934a00493524bc4e06563
5b0555084dd54679df1536101b2c979c0152d09192
+ I * 09bcccfa036b4847c9950780733633f13619994394c23ff0b32fa6
b795844f4a0673e20282d07bc69641cee04f5e5662
u[0] = 025820cefc7d06fd38de7d8e370e0da8a52498be9b53cba9927b2e
f5c6de1e12e12f188bbc7bc923864883c57e49e253
+ I * 034147b77ce337a52e5948f66db0bab47a8d038e712123bb381899
b6ab5ad20f02805601e6104c29df18c254b8618c7b
u[1] = 0930315cae1f9a6017c3f0c8f2314baa130e1cf13f6532bff0a8a1
790cd70af918088c3db94bda214e896e1543629795
+ I * 10c4df2cacf67ea3cb3108b00d4cbd0b3968031ebc8eac4b1ebcef
e84d6b715fde66bef0219951ece29d1facc8a520ef
Q0.x = 09eccbc53df677f0e5814e3f86e41e146422834854a224bf5a83a5
0e4cc0a77bfc56718e8166ad180f53526ea9194b57
+ I * 0c3633943f91daee715277bd644fba585168a72f96ded64fc5a384
cce4ec884a4c3c30f08e09cd2129335dc8f67840ec
Q0.y = 0eb6186a0457d5b12d132902d4468bfeb7315d83320b6c32f1c875
Faz-Hernandez, et al. Expires 17 December 2022 [Page 144]
Internet-Draft hash-to-curve June 2022
f344efcba979952b4aa418589cb01af712f98cc555
+ I * 119e3cf167e69eb16c1c7830e8df88856d48be12e3ff0a40791a5c
d2f7221311d4bf13b1847f371f467357b3f3c0b4c7
Q1.x = 0eb3aabc1ddfce17ff18455fcc7167d15ce6b60ddc9eb9b59f8d40
ab49420d35558686293d046fc1e42f864b7f60e381
+ I * 198bdfb19d7441ebcca61e8ff774b29d17da16547d2c10c273227a
635cacea3f16826322ae85717630f0867539b5ed8b
Q1.y = 0aaf1dee3adf3ed4c80e481c09b57ea4c705e1b8d25b897f0ceeec
3990748716575f92abff22a1c8f4582aff7b872d52
+ I * 0d058d9061ed27d4259848a06c96c5ca68921a5d269b078650c882
cb3c2bd424a8702b7a6ee4e0ead9982baf6843e924
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 01a6ba2f9a11fa5598b2d8ace0fbe0a0eacb65deceb476fbbcb64f
d24557c2f4b18ecfc5663e54ae16a84f5ab7f62534
+ I * 11fca2ff525572795a801eed17eb12785887c7b63fb77a42be46ce
4a34131d71f7a73e95fee3f812aea3de78b4d01569
P.y = 0b6798718c8aed24bc19cb27f866f1c9effcdbf92397ad6448b5c9
db90d2b9da6cbabf48adc1adf59a1a28344e79d57e
+ I * 03a47f8e6d1763ba0cad63d6114c0accbef65707825a511b251a66
0a9b3994249ae4e63fac38b23da0c398689ee2ab52
u[0] = 190b513da3e66fc9a3587b78c76d1d132b1152174d0b83e3c11140
66392579a45824c5fa17649ab89299ddd4bda54935
+ I * 12ab625b0fe0ebd1367fe9fac57bb1168891846039b4216b9d9400
7b674de2d79126870e88aeef54b2ec717a887dcf39
u[1] = 0e6a42010cf435fb5bacc156a585e1ea3294cc81d0ceb81924d950
40298380b164f702275892cedd81b62de3aba3f6b5
+ I * 117d9a0defc57a33ed208428cb84e54c85a6840e7648480ae42883
8989d25d97a0af8e3255be62b25c2a85630d2dddd8
Q0.x = 17cadf8d04a1a170f8347d42856526a24cc466cb2ddfd506cff011
91666b7f944e31244d662c904de5440516a2b09004
+ I * 0d13ba91f2a8b0051cf3279ea0ee63a9f19bc9cb8bfcc7d78b3cbd
8cc4fc43ba726774b28038213acf2b0095391c523e
Q0.y = 17ef19497d6d9246fa94d35575c0f8d06ee02f21a284dbeaa78768
cb1e25abd564e3381de87bda26acd04f41181610c5
+ I * 12c3c913ba4ed03c24f0721a81a6be7430f2971ffca8fd1729aafe
496bb725807531b44b34b59b3ae5495e5a2dcbd5c8
Q1.x = 16ec57b7fe04c71dfe34fb5ad84dbce5a2dbbd6ee085f1d8cd17f4
5e8868976fc3c51ad9eeda682c7869024d24579bfd
Faz-Hernandez, et al. Expires 17 December 2022 [Page 145]
Internet-Draft hash-to-curve June 2022
+ I * 13103f7aace1ae1420d208a537f7d3a9679c287208026e4e3439ab
8cd534c12856284d95e27f5e1f33eec2ce656533b0
Q1.y = 0958b2c4c2c10fcef5a6c59b9e92c4a67b0fae3e2e0f1b6b5edad9
c940b8f3524ba9ebbc3f2ceb3cfe377655b3163bd7
+ I * 0ccb594ed8bd14ca64ed9cb4e0aba221be540f25dd0d6ba15a4a4b
e5d67bcf35df7853b2d8dad3ba245f1ea3697f66aa
J.10.2. BLS12381G2_XMD:SHA-256_SSWU_NU_
suite = BLS12381G2_XMD:SHA-256_SSWU_NU_
dst = QUUX-V01-CS02-with-BLS12381G2_XMD:SHA-256_SSWU_NU_
msg =
P.x = 00e7f4568a82b4b7dc1f14c6aaa055edf51502319c723c4dc2688c
7fe5944c213f510328082396515734b6612c4e7bb7
+ I * 126b855e9e69b1f691f816e48ac6977664d24d99f8724868a18418
6469ddfd4617367e94527d4b74fc86413483afb35b
P.y = 0caead0fd7b6176c01436833c79d305c78be307da5f6af6c133c47
311def6ff1e0babf57a0fb5539fce7ee12407b0a42
+ I * 1498aadcf7ae2b345243e281ae076df6de84455d766ab6fcdaad71
fab60abb2e8b980a440043cd305db09d283c895e3d
u[0] = 07355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa
31714e09ea0ded3a078b526bed3307f804d4b93b04
+ I * 02829ce3c021339ccb5caf3e187f6370e1e2a311dec9b753631170
63ab2015603ff52c3d3b98f19c2f65575e99e8b78c
Q.x = 18ed3794ad43c781816c523776188deafba67ab773189b8f18c49b
c7aa841cd81525171f7a5203b2a340579192403bef
+ I * 0727d90785d179e7b5732c8a34b660335fed03b913710b60903cf4
954b651ed3466dc3728e21855ae822d4a0f1d06587
Q.y = 00764a5cf6c5f61c52c838523460eb2168b5a5b43705e19cb612e0
06f29b717897facfd15dd1c8874c915f6d53d0342d
+ I * 19290bb9797c12c1d275817aa2605ebe42275b66860f0e4d04487e
bc2e47c50b36edd86c685a60c20a2bd584a82b011a
msg = abc
P.x = 108ed59fd9fae381abfd1d6bce2fd2fa220990f0f837fa30e0f279
14ed6e1454db0d1ee957b219f61da6ff8be0d6441f
+ I * 0296238ea82c6d4adb3c838ee3cb2346049c90b96d602d7bb1b469
b905c9228be25c627bffee872def773d5b2a2eb57d
P.y = 033f90f6057aadacae7963b0a0b379dd46750c1c94a6357c99b65f
63b79e321ff50fe3053330911c56b6ceea08fee656
+ I * 153606c417e59fb331b7ae6bce4fbf7c5190c33ce9402b5ebe2b70
e44fca614f3f1382a3625ed5493843d0b0a652fc3f
u[0] = 138879a9559e24cecee8697b8b4ad32cced053138ab913b9987277
2dc753a2967ed50aabc907937aefb2439ba06cc50c
+ I * 0a1ae7999ea9bab1dcc9ef8887a6cb6e8f1e22566015428d220b7e
ec90ffa70ad1f624018a9ad11e78d588bd3617f9f2
Q.x = 0f40e1d5025ecef0d850aa0bb7bbeceab21a3d4e85e6bee857805b
Faz-Hernandez, et al. Expires 17 December 2022 [Page 146]
Internet-Draft hash-to-curve June 2022
quot; InitKey in
order to prevent denial of service attacks. Since an InitKey is
needed to add a client to a new group, an attacker could prevent a
client being added to new groups by exhausting all available
InitKeys.
15.5. Group Fragmentation by Malicious Insiders
It is possible for a malicious member of a group to "fragment" the
group by crafting an invalid UpdatePath. Recall that an UpdatePath
encrypts a sequence of path secrets to different subtrees of the
group's ratchet trees. These path secrets should be derived in a
sequence as described in Section 5.4, but the UpdatePath syntax
allows the sender to encrypt arbitrary, unrelated secrets. The
syntax also does not guarantee that the encrypted path secret
encrypted for a given node corresponds to the public key provided for
that node.
Both of these types of corruption will cause processing of a Commit
to fail for some members of the group. If the public key for a node
does not match the path secret, then the members that decrypt that
path secret will reject the commit based on this mismatch. If the
path secret sequence is incorrect at some point, then members that
can decrypt nodes before that point will compute a different public
key for the mismatched node than the one in the UpdatePath, which
also causes the Commit to fail. Applications SHOULD provide
mechanisms for failed commits to be reported, so that group members
who were not able to recognize the error themselves can reject the
commit and roll back to a previous state if necessary.
Barnes, et al. Expires 14 April 2022 [Page 82]
Internet-Draft MLS October 2021
Even with such an error reporting mechanism in place, however, it is
still possible for members to get locked out of the group by a
malformed commit. Since malformed Commits can only be recognized by
certain members of the group, in an asynchronous application, it may
be the case that all members that could detect a fault in a Commit
are offline. In such a case, the Commit will be accepted by the
group, and the resulting state possibly used as the basis for further
Commits. When the affected members come back online, they will
reject the first commit, and thus be unable to catch up with the
group.
Applications can address this risk by requiring certain members of
the group to acknowledge successful processing of a Commit before the
group regards the Commit as accepted. The minimum set of
acknowledgements necessary to verify that a Commit is well-formed
comprises an acknowledgement from one member per node in the
UpdatePath, that is, one member from each subtree rooted in the
copath node corresponding to the node in the UpdatePath.
16. IANA Considerations
This document requests the creation of the following new IANA
registries:
* MLS Ciphersuites (Section 16.1)
* MLS Extension Types (Section 16.2)
* MLS Proposal Types (Section 16.3)
* MLS Credential Types (Section 16.4)
All of these registries should be under a heading of "Messaging Layer
Security", and assignments are made via the Specification Required
policy [RFC8126]. See Section 16.5 for additional information about
the MLS Designated Experts (DEs).
RFC EDITOR: Please replace XXXX throughout with the RFC number
assigned to this document
16.1. MLS Ciphersuites
A ciphersuite is a combination of a protocol version and the set of
cryptographic algorithms that should be used.
Ciphersuite names follow the naming convention:
CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE;
Barnes, et al. Expires 14 April 2022 [Page 83]
Internet-Draft MLS October 2021
Where VALUE is represented as a sixteen-bit integer:
uint16 CipherSuite;
+===========+========================================+
| Component | Contents |
+===========+========================================+
| MLS | The string "MLS" followed by the major |
| | and minor version, e.g. "MLS10" |
+-----------+----------------------------------------+
| LVL | The security level |
+-----------+----------------------------------------+
| KEM | The KEM algorithm used for HPKE in |
| | TreeKEM group operations |
+-----------+----------------------------------------+
| AEAD | The AEAD algorithm used for HPKE and |
| | message protection |
+-----------+----------------------------------------+
| HASH | The hash algorithm used for HPKE and |
| | the MLS transcript hash |
+-----------+----------------------------------------+
| SIG | The Signature algorithm used for |
| | message authentication |
+-----------+----------------------------------------+
Table 3
The columns in the registry are as follows:
* Value: The numeric value of the ciphersuite
* Name: The name of the ciphersuite
* Recommended: Whether support for this ciphersuite is recommended
by the IETF MLS WG. Valid values are "Y" and "N". The
"Recommended" column is assigned a value of "N" unless explicitly
requested, and adding a value with a "Recommended" value of "Y"
requires Standards Action [RFC8126]. IESG Approval is REQUIRED
for a Y->N transition.
* Reference: The document where this ciphersuite is defined
Initial contents:
Barnes, et al. Expires 14 April 2022 [Page 84]
Internet-Draft MLS October 2021
+======+=====================================================+===========+=========+
|Value |Name |Recommended|Reference|
+======+=====================================================+===========+=========+
|0x0000|RESERVED |N/A |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0001|MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 |Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0002|MLS10_128_DHKEMP256_AES128GCM_SHA256_P256 |Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0003|MLS10_128_DHKEMX25519_CHACHA20POLY1305_SHA256_Ed25519|Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0004|MLS10_256_DHKEMX448_AES256GCM_SHA512_Ed448 |Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0005|MLS10_256_DHKEMP521_AES256GCM_SHA512_P521 |Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0x0006|MLS10_256_DHKEMX448_CHACHA20POLY1305_SHA512_Ed448 |Y |RFC XXXX |
+------+-----------------------------------------------------+-----------+---------+
|0xff00|Reserved for Private Use |N/A |RFC XXXX |
|- | | | |
|0xffff| | | |
+------+-----------------------------------------------------+-----------+---------+
Table 4
All of these ciphersuites use HMAC [RFC2104] as their MAC function,
with different hashes per ciphersuite. The mapping of ciphersuites
to HPKE primitives, HMAC hash functions, and TLS signature schemes is
as follows [I-D.irtf-cfrg-hpke] [RFC8446]:
+======+========+========+========+========+========================+
|Value | KEM | KDF | AEAD | Hash | Signature |
+======+========+========+========+========+========================+
|0x0001| 0x0020 | 0x0001 | 0x0001 | SHA256 | ed25519 |
+------+--------+--------+--------+--------+------------------------+
|0x0002| 0x0010 | 0x0001 | 0x0001 | SHA256 | ecdsa_secp256r1_sha256 |
+------+--------+--------+--------+--------+------------------------+
|0x0003| 0x0020 | 0x0001 | 0x0003 | SHA256 | ed25519 |
+------+--------+--------+--------+--------+------------------------+
|0x0004| 0x0021 | 0x0003 | 0x0002 | SHA512 | ed448 |
+------+--------+--------+--------+--------+------------------------+
|0x0005| 0x0012 | 0x0003 | 0x0002 | SHA512 | ecdsa_secp521r1_sha512 |
+------+--------+--------+--------+--------+------------------------+
|0x0006| 0x0021 | 0x0003 | 0x0003 | SHA512 | ed448 |
+------+--------+--------+--------+--------+------------------------+
Table 5
Barnes, et al. Expires 14 April 2022 [Page 85]
Internet-Draft MLS October 2021
The hash used for the MLS transcript hash is the one referenced in
the ciphersuite name. In the ciphersuites defined above, "SHA256"
and "SHA512" refer to the SHA-256 and SHA-512 functions defined in
[SHS].
It is advisable to keep the number of ciphersuites low to increase
the chances clients can interoperate in a federated environment,
therefore the ciphersuites only inlcude modern, yet well-established
algorithms. Depending on their requirements, clients can choose
between two security levels (roughly 128-bit and 256-bit). Within
the security levels clients can choose between faster X25519/X448
curves and FIPS 140-2 compliant curves for Diffie-Hellman key
negotiations. Additionally clients that run predominantly on mobile
processors can choose ChaCha20Poly1305 over AES-GCM for performance
reasons. Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is
not paired with FIPS 140-2 compliant curves. The security level of
symmetric encryption algorithms and hash functions is paired with the
security level of the curves.
The mandatory-to-implement ciphersuite for MLS 1.0 is
MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 which uses Curve25519
for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and
Ed25519 for signatures.
Values with the first byte 255 (decimal) are reserved for Private
Use.
New ciphersuite values are assigned by IANA as described in
Section 16.
16.2. MLS Extension Types
This registry lists identifiers for extensions to the MLS protocol.
The extension type field is two bytes wide, so valid extension type
values are in the range 0x0000 to 0xffff.
Template:
* Value: The numeric value of the extension type
* Name: The name of the extension type
* Message(s): The messages in which the extension may appear, drawn
from the following list:
- KP: KeyPackage messages
Barnes, et al. Expires 14 April 2022 [Page 86]
Internet-Draft MLS October 2021
- GC: GroupContext objects (and the group_context_extensions
field of GroupInfo objects)
- GI: The other_extensions field of GroupInfo objects
* Recommended: Whether support for this extension is recommended by
the IETF MLS WG. Valid values are "Y" and "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N
transition.
* Reference: The document where this extension is defined
Initial contents:
+==========+=================+============+=============+===========+
| Value | Name | Message(s) | Recommended | Reference |
+==========+=================+============+=============+===========+
| 0x0000 | RESERVED | N/A | N/A | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0x0001 | capabilities | KP | Y | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0x0002 | lifetime | KP | Y | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0x0003 | external_key_id | KP | Y | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0x0004 | parent_hash | KP | Y | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0x0005 | ratchet_tree | GI | Y | RFC XXXX |
+----------+-----------------+------------+-------------+-----------+
| 0xff00 | Reserved for | N/A | N/A | RFC XXXX |
| - | Private Use | | | |
| 0xffff | | | | |
+----------+-----------------+------------+-------------+-----------+
Table 6
16.3. MLS Proposal Types
This registry lists identifiers for types of proposals that can be
made for changes to an MLS group. The extension type field is two
bytes wide, so valid extension type values are in the range 0x0000 to
0xffff.
Template:
* Value: The numeric value of the proposal type
Barnes, et al. Expires 14 April 2022 [Page 87]
Internet-Draft MLS October 2021
* Name: The name of the proposal type
* Recommended: Whether support for this extension is recommended by
the IETF MLS WG. Valid values are "Y" and "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N
transition.
* Reference: The document where this extension is defined
Initial contents:
+==========+==========================+=============+===========+
| Value | Name | Recommended | Reference |
+==========+==========================+=============+===========+
| 0x0000 | RESERVED | N/A | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0001 | add | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0002 | update | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0003 | remove | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0004 | psk | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0005 | reinit | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0006 | external_init | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0007 | app_ack | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0x0008 | group_context_extensions | Y | RFC XXXX |
+----------+--------------------------+-------------+-----------+
| 0xff00 - | Reserved for Private Use | N/A | RFC XXXX |
| 0xffff | | | |
+----------+--------------------------+-------------+-----------+
Table 7
16.4. MLS Credential Types
This registry lists identifiers for types of credentials that can be
used for authentication in the MLS protocol. The credential type
field is two bytes wide, so valid credential type values are in the
range 0x0000 to 0xffff.
Template:
Barnes, et al. Expires 14 April 2022 [Page 88]
Internet-Draft MLS October 2021
* Value: The numeric value of the credential type
* Name: The name of the credential type
* Recommended: Whether support for this credential is recommended by
the IETF MLS WG. Valid values are "Y" and "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N
transition.
* Reference: The document where this credential is defined
Initial contents:
+=================+==============+=============+===========+
| Value | Name | Recommended | Reference |
+=================+==============+=============+===========+
| 0x0000 | RESERVED | N/A | RFC XXXX |
+-----------------+--------------+-------------+-----------+
| 0x0001 | basic | Y | RFC XXXX |
+-----------------+--------------+-------------+-----------+
| 0x0002 | x509 | Y | RFC XXXX |
+-----------------+--------------+-------------+-----------+
| 0xff00 - 0xffff | Reserved for | N/A | RFC XXXX |
| | Private Use | | |
+-----------------+--------------+-------------+-----------+
Table 8
16.5. MLS Designated Expert Pool
Specification Required [RFC8126] registry requests are registered
after a three-week review period on the MLS DEs' mailing list: mls-
reg-review@ietf.org (mailto:mls-reg-review@ietf.org), on the advice
of one or more of the MLS DEs. However, to allow for the allocation
of values prior to publication, the MLS DEs may approve registration
once they are satisfied that such a specification will be published.
Registration requests sent to the MLS DEs mailing list for review
SHOULD use an appropriate subject (e.g., "Request to register value
in MLS Bar registry").
Barnes, et al. Expires 14 April 2022 [Page 89]
Internet-Draft MLS October 2021
Within the review period, the MLS DEs will either approve or deny the
registration request, communicating this decision to the MLS DEs
mailing list and IANA. Denials SHOULD include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention for resolution using
the iesg@ietf.org (mailto:iesg@ietf.org) mailing list.
Criteria that SHOULD be applied by the MLS DEs includes determining
whether the proposed registration duplicates existing functionality,
whether it is likely to be of general applicability or useful only
for a single application, and whether the registration description is
clear. For example, the MLS DEs will apply the ciphersuite-related
advisory found in Section 6.1.
IANA MUST only accept registry updates from the MLS DEs and SHOULD
direct all requests for registration to the MLS DEs' mailing list.
It is suggested that multiple MLS DEs be appointed who are able to
represent the perspectives of different applications using this
specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular MLS
DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs.
17. Contributors
* Joel Alwen
Wickr
joel.alwen@wickr.com
* Karthikeyan Bhargavan
INRIA
karthikeyan.bhargavan@inria.fr
* Cas Cremers
University of Oxford
cremers@cispa.de
* Alan Duric
Wire
alan@wire.com
* Britta Hale
Naval Postgraduate School
britta.hale@nps.edu
Barnes, et al. Expires 14 April 2022 [Page 90]
Internet-Draft MLS October 2021
* Srinivas Inguva
Twitter
singuva@twitter.com
* Konrad Kohbrok
Aalto University
konrad.kohbrok@datashrine.de
* Albert Kwon
MIT
kwonal@mit.edu
* Brendan McMillion
Cloudflare
brendan@cloudflare.com
* Eric Rescorla
Mozilla
ekr@rtfm.com
* Michael Rosenberg
Trail of Bits
michael.rosenberg@trailofbits.com
* Thyla van der Merwe
Royal Holloway, University of London
thyla.van.der@merwe.tech
18. References
18.1. Normative References
[I-D.irtf-cfrg-hpke]
Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
"Hybrid Public Key Encryption", Work in Progress,
Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hpke-12>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Barnes, et al. Expires 14 April 2022 [Page 91]
Internet-Draft MLS October 2021
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
18.2. Informative References
[art] Cohn-Gordon, K., Cremers, C., Garratt, L., Millican, J.,
and K. Milner, "On Ends-to-Ends Encryption: Asynchronous
Group Messaging with Strong Security Guarantees", 18
January 2018, <https://eprint.iacr.org/2017/666.pdf>.
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
Why You Went to the Clinic: Risks and Realization of HTTPS
Traffic Analysis", Privacy Enhancing Technologies pp.
143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,
<https://doi.org/10.1007/978-3-319-08506-7_8>.
[doubleratchet]
Cohn-Gordon, K., Cremers, C., Dowling, B., Garratt, L.,
and D. Stebila, "A Formal Security Analysis of the Signal
Messaging Protocol", 2017 IEEE European Symposium on
Security and Privacy (EuroS&P),
DOI 10.1109/eurosp.2017.27, April 2017,
<https://doi.org/10.1109/eurosp.2017.27>.
[HCJ16] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS
traffic analysis and client identification using passive
SSL/TLS fingerprinting", EURASIP Journal on Information
Security Vol. 2016, DOI 10.1186/s13635-016-0030-7,
February 2016,
<https://doi.org/10.1186/s13635-016-0030-7>.
[I-D.ietf-mls-architecture]
Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mls-architecture-07, 4 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
architecture-07>.
Barnes, et al. Expires 14 April 2022 [Page 92]
Internet-Draft MLS October 2021
[I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", Work in
Progress, Internet-Draft, draft-ietf-trans-rfc6962-bis-42,
31 August 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-trans-rfc6962-bis-42>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[SECG] "Elliptic Curve Cryptography, Standards for Efficient
Cryptography Group, ver. 2", 2009,
<https://secg.org/sec1-v2.pdf>.
[SHS] Dang, Q., "Secure Hash Standard", National Institute of
Standards and Technology report,
DOI 10.6028/nist.fips.180-4, July 2015,
<https://doi.org/10.6028/nist.fips.180-4>.
[signal] Perrin(ed), T. and M. Marlinspike, "The Double Ratchet
Algorithm", 20 November 2016,
<https://www.signal.org/docs/specifications/
doubleratchet/>.
Appendix A. Tree Math
One benefit of using left-balanced trees is that they admit a simple
flat array representation. In this representation, leaf nodes are
even-numbered nodes, with the n-th leaf at 2*n. Intermediate nodes
are held in odd-numbered nodes. For example, an 11-element tree has
the following structure:
X
X
X X X
X X X X X
X X X X X X X X X X X
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
This allows us to compute relationships between tree nodes simply by
manipulating indices, rather than having to maintain complicated
structures in memory, even for partial trees. The basic rule is that
the high-order bits of parent and child nodes have the following
relation (where x is an arbitrary bit string):
parent=01x => left=00x, right=10x
Barnes, et al. Expires 14 April 2022 [Page 93]
Internet-Draft MLS October 2021
The following python code demonstrates the tree computations
necessary for MLS. Test vectors can be derived from the diagram
above.
# The exponent of the largest power of 2 less than x. Equivalent to:
# int(math.floor(math.log(x, 2)))
def log2(x):
if x == 0:
return 0
k = 0
while (x >> k) > 0:
k += 1
return k-1
# The level of a node in the tree. Leaves are level 0, their parents are
# level 1, etc. If a node's children are at different levels, then its
# level is the max level of its children plus one.
def level(x):
if x & 0x01 == 0:
return 0
k = 0
while ((x >> k) & 0x01) == 1:
k += 1
return k
# The number of nodes needed to represent a tree with n leaves.
def node_width(n):
if n == 0:
return 0
else:
return 2*(n - 1) + 1
# The index of the root node of a tree with n leaves.
def root(n):
w = node_width(n)
return (1 << log2(w)) - 1
# The left child of an intermediate node. Note that because the tree is
# left-balanced, there is no dependency on the size of the tree.
def left(x):
k = level(x)
if k == 0:
raise Exception('leaf node has no children')
return x ^ (0x01 << (k - 1))
Barnes, et al. Expires 14 April 2022 [Page 94]
Internet-Draft MLS October 2021
# The right child of an intermediate node. Depends on the number of
# leaves because the straightforward calculation can take you beyond the
# edge of the tree.
def right(x, n):
k = level(x)
if k == 0:
raise Exception('leaf node has no children')
r = x ^ (0x03 << (k - 1))
while r >= node_width(n):
r = left(r)
return r
# The immediate parent of a node. May be beyond the right edge of the
# tree.
def parent_step(x):
k = level(x)
b = (x >> (k + 1)) & 0x01
return (x | (1 << k)) ^ (b << (k + 1))
# The parent of a node. As with the right child calculation, we have to
# walk back until the parent is within the range of the tree.
def parent(x, n):
if x == root(n):
raise Exception('root node has no parent')
p = parent_step(x)
while p 09693051f5b25428c6be343edba5f14317fcc30143
+ I * 02e0d261f2b9fee88b82804ec83db330caa75fbb12719cfa71ccce
1c532dc4e1e79b0a6a281ed8d3817524286c8bc04c
Q.y = 0cf4a4adc5c66da0bca4caddc6a57ecd97c8252d7526a8ff478e0d
fed816c4d321b5c3039c6683ae9b1e6a3a38c9c0ae
+ I * 11cad1646bb3768c04be2ab2bbe1f80263b7ff6f8f9488f5bc3b68
50e5a3e97e20acc583613c69cf3d2bfe8489744ebb
msg = abcdef0123456789
P.x = 038af300ef34c7759a6caaa4e69363cafeed218a1f207e93b2c70d
91a1263d375d6730bd6b6509dcac3ba5b567e85bf3
+ I * 0da75be60fb6aa0e9e3143e40c42796edf15685cafe0279afd2a67
c3dff1c82341f17effd402e4f1af240ea90f4b659b
P.y = 19b148cbdf163cf0894f29660d2e7bfb2b68e37d54cc83fd4e6e62
c020eaa48709302ef8e746736c0e19342cc1ce3df4
+ I * 0492f4fed741b073e5a82580f7c663f9b79e036b70ab3e51162359
cec4e77c78086fe879b65ca7a47d34374c8315ac5e
u[0] = 18c16fe362b7dbdfa102e42bdfd3e2f4e6191d479437a59db4eb71
6986bf08ee1f42634db66bde97d6c16bbfd342b3b8
+ I * 0e37812ce1b146d998d5f92bdd5ada2a31bfd63dfe18311aa91637
b5f279dd045763166aa1615e46a50d8d8f475f184e
Q.x = 13a9d4a738a85c9f917c7be36b240915434b58679980010499b9ae
8d7a1bf7fbe617a15b3cd6060093f40d18e0f19456
+ I * 16fa88754e7670366a859d6f6899ad765bf5a177abedb2740aacc9
252c43f90cd0421373fbd5b2b76bb8f5c4886b5d37
Q.y = 0a7fa7d82c46797039398253e8765a4194100b330dfed6d7fbb46d
6fbf01e222088779ac336e3675c7a7a0ee05bbb6e3
+ I * 0c6ee170ab766d11fa9457cef53253f2628010b2cffc102b3b2835
1eb9df6c281d3cfc78e9934769d661b72a5265338d
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
P.x = 0c5ae723be00e6c3f0efe184fdc0702b64588fe77dda152ab13099
a3bacd3876767fa7bbad6d6fd90b3642e902b208f9
+ I * 12c8c05c1d5fc7bfa847f4d7d81e294e66b9a78bc9953990c35894
5e1f042eedafce608b67fdd3ab0cb2e6e263b9b1ad
P.y = 04e77ddb3ede41b5ec4396b7421dd916efc68a358a0d7425bddd25
3547f2fb4830522358491827265dfc5bcc1928a569
+ I * 11c624c56dbe154d759d021eec60fab3d8b852395a89de497e4850
4366feedd4662d023af447d66926a28076813dd646
u[0] = 08d4a0997b9d52fecf99427abb721f0fa779479963315fe21c6445
250de7183e3f63bfdf86570da8929489e421d4ee95
+ I * 16cb4ccad91ec95aab070f22043916cd6a59c4ca94097f7f510043
d48515526dc8eaaea27e586f09151ae613688d5a89
Q.x = 0a08b2f639855dfdeaaed972702b109e2241a54de198b2b4cd12ad
9f88fa419a6086a58d91fc805de812ea29bee427c2
+ I * 04a7442e4cb8b42ef0f41dac9ee74e65ecad3ce0851f0746dc4756
Faz-Hernandez, et al. Expires 17 December 2022 [Page 147]
Internet-Draft hash-to-curve June 2022
8b0e7a8134121ed09ba054509232c49148aef62cda
Q.y = 05d60b1f04212b2c87607458f71d770f43973511c260f0540eef3a
565f42c7ce59aa1cea684bb2a7bcab84acd2f36c8c
+ I * 1017aa5747ba15505ece266a86b0ca9c712f41a254b76ca04094ca
442ce45ecd224bd5544cd16685d0d1b9d156dd0531
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
P.x = 0ea4e7c33d43e17cc516a72f76437c4bf81d8f4eac69ac355d3bf9
b71b8138d55dc10fd458be115afa798b55dac34be1
+ I * 1565c2f625032d232f13121d3cfb476f45275c303a037faa255f9d
a62000c2c864ea881e2bcddd111edc4a3c0da3e88d
P.y = 043b6f5fe4e52c839148dc66f2b3751e69a0f6ebb3d056d6465d50
d4108543ecd956e10fa1640dfd9bc0030cc2558d28
+ I * 0f8991d2a1ad662e7b6f58ab787947f1fa607fce12dde171bc1790
3b012091b657e15333e11701edcf5b63ba2a561247
u[0] = 03f80ce4ff0ca2f576d797a3660e3f65b274285c054feccc3215c8
79e2c0589d376e83ede13f93c32f05da0f68fd6a10
+ I * 006488a837c5413746d868d1efb7232724da10eca410b07d8b505b
9363bdccf0a1fc0029bad07d65b15ccfe6dd25e20d
Q.x = 19592c812d5a50c5601062faba14c7d670711745311c879de1235a
0a11c75aab61327bf2d1725db07ec4d6996a682886
+ I * 0eef4fa41ddc17ed47baf447a2c498548f3c72a02381313d13bef9
16e240b61ce125539090d62d9fbb14a900bf1b8e90
Q.y = 1260d6e0987eae96af9ebe551e08de22b37791d53f4db9e0d59da7
36e66699735793e853e26362531fe4adf99c1883e3
+ I * 0dbace5df0a4ac4ac2f45d8fdf8aee45484576fdd6efc4f98ab9b9
f4112309e628255e183022d98ea5ed6e47ca00306c
Appendix K. Expand test vectors
This section gives test vectors for expand_message variants specified
in Section 5.4. The test vectors in this section were generated
using code that is available from [hash2curve-repo].
Faz-Hernandez, et al. Expires 17 December 2022 [Page 148]
Internet-Draft hash-to-curve June 2022
Each test vector in this section lists the expand_message name, hash
function, and DST, along with a series of tuples of the function
inputs (msg and len_in_bytes), output (uniform_bytes), and
intermediate values (dst_prime and msg_prime). DST and msg are
represented as ASCII strings. Intermediate and output values are
represented as byte strings in hexadecimal.
K.1. expand_message_xmd(SHA-256)
name = expand_message_xmd
DST = QUUX-V01-CS02-with-expander-SHA256-128
hash = SHA256
k = 128
msg =
len_in_bytes = 0x20
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000002000515555582d5630312d43533032
2d776974682d657870616e6465722d5348413235362d31323826
uniform_bytes = 68a985b87eb6b46952128911f2a4412bbc302a9d759667f8
7f7a21d803f07235
msg = abc
len_in_bytes = 0x20
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000616263002000515555582d5630312d43
5330322d776974682d657870616e6465722d5348413235362d3132
3826
uniform_bytes = d8ccab23b5985ccea865c6c97b6e5b8350e794e603b4b979
02f53a8a0d605615
msg = abcdef0123456789
len_in_bytes = 0x20
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000061626364656630313233343536373839
002000515555582d5630312d435330322d776974682d657870616e
6465722d5348413235362d31323826
uniform_bytes = eff31487c770a893cfb36f912fbfcbff40d5661771ca4b2c
b4eafe524333f5c1
Faz-Hernandez, et al. Expires 17 December 2022 [Page 149]
Internet-Draft hash-to-curve June 2022
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
len_in_bytes = 0x20
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000713132385f7171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171002000515555582d5630312d435330322d77
6974682d657870616e6465722d5348413235362d31323826
uniform_bytes = b23a1d2b4d97b2ef7785562a7e8bac7eed54ed6e97e29aa5
1bfe3f12ddad1ff9
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
len_in_bytes = 0x20
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000613531325f6161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
Faz-Hernandez, et al. Expires 17 December 2022 [Page 150]
Internet-Draft hash-to-curve June 2022
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161002000515555582d5630312d
435330322d776974682d657870616e6465722d5348413235362d31
323826
uniform_bytes = 4623227bcc01293b8c130bf771da8c298dede7383243dc09
93d2d94823958c4c
msg =
len_in_bytes = 0x80
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000008000515555582d5630312d43533032
2d776974682d657870616e6465722d5348413235362d31323826
uniform_bytes = af84c27ccfd45d41914fdff5df25293e221afc53d8ad2ac0
6d5e3e29485dadbee0d121587713a3e0dd4d5e69e93eb7cd4f5df4
cd103e188cf60cb02edc3edf18eda8576c412b18ffb658e3dd6ec8
49469b979d444cf7b26911a08e63cf31f9dcc541708d3491184472
c2c29bb749d4286b004ceb5ee6b9a7fa5b646c993f0ced
msg = abc
len_in_bytes = 0x80
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000616263008000515555582d5630312d43
5330322d776974682d657870616e6465722d5348413235362d3132
3826
uniform_bytes = abba86a6129e366fc877aab32fc4ffc70120d8996c88aee2
fe4b32d6c7b6437a647e6c3163d40b76a73cf6a5674ef1d890f95b
664ee0afa5359a5c4e07985635bbecbac65d747d3d2da7ec2b8221
b17b0ca9dc8a1ac1c07ea6a1e60583e2cb00058e77b7b72a298425
cd1b941ad4ec65e8afc50303a22c0f99b0509b4c895f40
msg = abcdef0123456789
len_in_bytes = 0x80
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000061626364656630313233343536373839
008000515555582d5630312d435330322d776974682d657870616e
6465722d5348413235362d31323826
Faz-Hernandez, et al. Expires 17 December 2022 [Page 151]
Internet-Draft hash-to-curve June 2022
uniform_bytes = ef904a29bffc4cf9ee82832451c946ac3c8f8058ae97d8d6
29831a74c6572bd9ebd0df635cd1f208e2038e760c4994984ce73f
0d55ea9f22af83ba4734569d4bc95e18350f740c07eef653cbb9f8
7910d833751825f0ebefa1abe5420bb52be14cf489b37fe1a72f7d
e2d10be453b2c9d9eb20c7e3f6edc5a60629178d9478df
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
len_in_bytes = 0x80
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000713132385f7171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171008000515555582d5630312d435330322d77
6974682d657870616e6465722d5348413235362d31323826
uniform_bytes = 80be107d0884f0d881bb460322f0443d38bd222db8bd0b0a
5312a6fedb49c1bbd88fd75d8b9a09486c60123dfa1d73c1cc3169
761b17476d3c6b7cbbd727acd0e2c942f4dd96ae3da5de368d26b3
2286e32de7e5a8cb2949f866a0b80c58116b29fa7fabb3ea7d520e
e603e0c25bcaf0b9a5e92ec6a1fe4e0391d1cdbce8c68a
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
len_in_bytes = 0x80
DST_prime = 515555582d5630312d435330322d776974682d657870616e6465
722d5348413235362d31323826
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000613531325f6161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
Faz-Hernandez, et al. Expires 17 December 2022 [Page 152]
Internet-Draft hash-to-curve June 2022
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161616161616161616161616161
616161616161616161616161616161008000515555582d5630312d
435330322d776974682d657870616e6465722d5348413235362d31
323826
uniform_bytes = 546aff5444b5b79aa6148bd81728704c32decb73a3ba76e9
e75885cad9def1d06d6792f8a7d12794e90efed817d96920d72889
6a4510864370c207f99bd4a608ea121700ef01ed879745ee3e4cee
f777eda6d9e5e38b90c86ea6fb0b36504ba4a45d22e86f6db5dd43
d98a294bebb9125d5b794e9d2a81181066eb954966a487
K.2. expand_message_xmd(SHA-256) (long DST)
name = expand_message_xmd
DST = QUUX-V01-CS02-with-expander-SHA256-128-long-DST-111111
111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111
hash = SHA256
k = 128
msg =
len_in_bytes = 0x20
DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4
fb4d16c0a23620
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000002000412717974da474d0f8c420f320
ff81e8432adb7c927d9bd082b4fb4d16c0a23620
uniform_bytes = e8dc0c8b686b7ef2074086fbdd2f30e3f8bfbd3bdf177f73
f04b97ce618a3ed3
msg = abc
len_in_bytes = 0x20
DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4
fb4d16c0a23620
Faz-Hernandez, et al. Expires 17 December 2022 [Page 153]
Internet-Draft hash-to-curve June 2022
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000616263002000412717974da474d0f8c4
20f320ff81e8432adb7c927d9bd082b4fb4d16c0a23620
uniform_bytes = 52dbf4f36cf560fca57dedec2ad924ee9c266341d8f3d6af
e5171733b16bbb12
msg = abcdef0123456789
len_in_bytes = 0x20
DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4
fb4d16c0a23620
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000061626364656630313233343536373839
002000412717974da474d0f8c420f320ff81e8432adb7c927d9bd0
82b4fb4d16c0a23620
uniform_bytes = 35387dcf22618f3728e6c686490f8b431f76550b0b2c61cb
c1ce7001536f4521
msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqq
len_in_bytes = 0x20
DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4
fb4d16c0a23620
msg_prime = 0000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000713132385f7171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171717171717171717171717171717171717171
717171717171717171002000412717974da474d0f8c420f320ff81
e8432adb7c927d9bd082b4fb4d16c0a23620
uniform_bytes = 01b637612bb18e840028be900a833a74414140dde0c4754c
198532c3a0ba42bc
msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
len_in_bytes = 0x20
Faz-Hernandez, et al. Expires 17 December 2022 [Page 154]
Internet-Draft hash-to-curve June 2022
>= node_width(n):
p = parent_step(p)
return p
# The other child of the node's parent.
def sibling(x, n):
p = parent(x, n)
if x < p:
return right(p, n)
else:
return left(p)
# The direct path of a node, ordered from leaf to root.
def direct_path(x, n):
r = root(n)
if x == r:
return []
d = []
while x != r:
x = parent(x, n)
Barnes, et al. Expires 14 April 2022 [Page 95]
Internet-Draft MLS October 2021
d.append(x)
return d
# The copath of a node, ordered from leaf to root.
def copath(x, n):
if x == root(n):
return []
d = direct_path(x, n)
d.insert(0, x)
d.pop()
return [sibling(y, n) for y in d]
# The common ancestor of two nodes is the lowest node that is in the
# direct paths of both leaves.
def common_ancestor_semantic(x, y, n):
dx = set([x]) | set(direct_path(x, n))
dy = set([y]) | set(direct_path(y, n))
dxy = dx & dy
if len(dxy) == 0:
raise Exception('failed to find common ancestor')
return min(dxy, key=level)
# The common ancestor of two nodes is the lowest node that is in the
# direct paths of both leaves.
def common_ancestor_direct(x, y, _):
# Handle cases where one is an ancestor of the other
lx, ly = level(x)+1, level(y)+1
if (lx <= ly) and (x>>ly == y>>ly):
return y
elif (ly <= lx) and (x>>lx == y>>lx):
return x
# Handle other cases
xn, yn = x, y
k = 0
while xn != yn:
xn, yn = xn >> 1, yn >> 1
k += 1
return (xn << k) + (1 << (k-1)) - 1
Authors' Addresses
Richard Barnes
Cisco
Email: rlb@ipv.sx
Barnes, et al. Expires 14 April 2022 [Page 96]
Internet-Draft MLS October 2021
Benjamin Beurdouche
Inria & Mozilla
Email: ietf@beurdouche.com
Raphael Robert
Email: ietf@raphaelrobert.com
Jon Millican
Facebook
Email: jmillican@fb.com
Emad Omara
Google
Email: emadomara@google.com
Katriel Cohn-Gordon
University of Oxford
Email: me@katriel.co.uk
Barnes, et al. Expires 14 April 2022 [Page 97]