jiebi/CodeConvo huggingface dataset:
Code change:
Adding this check would be the first step in recognizing that an Update operation may have maliciously excluded a person from the group.
This would go better in the "Ratchet Tree Updates" section, right after "Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret". That would align better with where in the code you want the checks to be. Other than that, LGTM.
Fixed
Thanks Michael !
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Related discussion:
text: node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that <del> node using the KDF keyed with the decrypted secret </del> <ins> node using the KDF keyed with the decrypted secret * The recipient SHOULD verify that the received public keys agree with the public keys derived from the new node_secret values </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For
Code change:
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Related discussion:
text: The creator of the group constructs an Init message as follows: <del> Fetch a ClientInitKey for each member (including the creator) </del> <ins> Fetch one or more ClientInitKeys for each member (including the creator) </ins> Identify a protocol version and cipher suite that is supported by all proposed members.
Code change:
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Related discussion:
text: needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del> <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf
Code change:
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Related discussion:
text: direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the ClientInitKey in the Add corresponding to the ciphersuite in use, as well as the credential under which the ClientInitKey was signed </del> <ins> containing the public key from the ClientInitKey in the Add, as well as the credential under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.
Code change:
You can also strike this sentence further down: " In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children."
Note that this severs the connection between the HPKE key in the leaf and the parent of the leaf. Whereas before, the leaf HPKE key was derived from a path secret, and the parent HPKE key was derived from the next path secret. Now the parent path secret is set directly, and the leaf HPKE key is set completely independently, with no dependency on a path secret. So we're losing a bit of internal structure in the tree. But this seems OK because that structure was never observable to the group -- only the holder of the leaf knows the leaf path secret, so nobody else could verify that the leaf was related to its parent.

Related discussion:
text: D.ietf-trans-rfc6962-bis.) The _direct path_ of a root is the empty list, and of any other node <del> is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct </del> <ins> 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 </ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. For example, in the below tree: <del> The direct path of C is (C, CD, ABCD) </del> <ins> The direct path of C is (CD, ABCD, ABCDEFG) </ins> The copath of C is (D, AB, EFG)
Code change:
You can also strike this sentence further down: " In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children."
Note that this severs the connection between the HPKE key in the leaf and the parent of the leaf. Whereas before, the leaf HPKE key was derived from a path secret, and the parent HPKE key was derived from the next path secret. Now the parent path secret is set directly, and the leaf HPKE key is set completely independently, with no dependency on a path secret. So we're losing a bit of internal structure in the tree. But this seems OK because that structure was never observable to the group -- only the holder of the leaf knows the leaf path secret, so nobody else could verify that the leaf was related to its parent.

Related discussion:
text: 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 leaf node.  There is one encrypted path secret <del> for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </del> <ins> for each public key in the resolution of the non-updated child. </ins> The recipient of a path update processes it with the following steps:
Code change:
This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.

Related discussion:
text: unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. <del> Create an initial, partial GroupInfo object reflecting the following values: Group ID: The group ID for the group Epoch: The epoch ID for the next epoch Tree: The group's ratchet tree after the commit has been applied Prior confirmed transcript hash: The confirmed transcript hash for the current state of the group (not the provisional state) </del> Create a DirectPath using the new tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree", and "prior_confirmed_transcript_hash"
Code change:
This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.

Related discussion:
text: the "confirmation" value in the MLSPlaintext.  Sign the MLSPlaintext using the current epoch's GroupContext as context. <del> Complete the GroupInfo by populating the following fields: </del> <ins> Update the tree in the provisional state by applying the direct path </ins> <del> Confirmed transcript hash: The confirmed transcript hash including the current Commit object </del> <ins> Construct a GroupInfo reflecting the new state: </ins> <del> Interim transcript hash: The interim transcript hash including the current Commit object </del> <ins> Group ID, epoch, tree, confirmed transcript hash, and interim transcript hash from the new state </ins> <del> Confirmation: The confirmation from the MLSPlaintext </del> <ins> The confirmation from the MLSPlaintext object </ins> Sign the GroupInfo using the member's private signing key Encrypt the GroupInfo using the key and nonce derived from the <del> "init_secret" for the current epoch (see welcoming-new-members) </del> <ins> "epoch_secret" for the new epoch (see welcoming-new-members) 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 Compute the path secret corresponding to the commonn ancestor node Compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch and the path secret for the common ancestor. </ins> <del> For each new member in the group, compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch. </del> Construct a Welcome message from the encrypted GroupInfo object and the encrypted key packages.
Code change:
This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.

Related discussion:
text: the new state is the "prior_confirmed_transcript_hash" in the GroupInfo object. <del> Process the "path" field in the GroupInfo to update the new group state: </del> <ins> Update the leaf at index "index" with the private key corresponding to the public key in the node. </ins> <del> Apply the DirectPath to the tree, as described in synchronizing-views-of-the-tree. </del> <ins> Identify the lowest common ancestor of the leaves at "index" and at "GroupInfo.signer_index".  Set the private key for this node to the private key derived from the "path_secret" in the KeyPackage object. </ins> <del> Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. </del> <ins> 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 correspondns to the public key in the node. </ins> Use the "epoch_secret" from the KeyPackage object to generate the epoch secret and other derived secrets for the current epoch.
Code change:
The first commit is editorial. I removed all the DH terminology I could find and replaced it with KEM terminology. The second commit is related to URL It would massively reduce complexity of implementations if people were able to rely on HPKE to do all private key parsing, key validation, public key computation, etc. Currently, all the information in the deleted CFRG and NIST sections is either redundant (performed by HPKE) or outdated and performed correctly by HPKE (e.g., old P-256 DH secret representation). Instead of having all this duplicated, it would be easier to keep it in one place. An issue with the new definition of : Repeatedly calling can be computationally expensive. Each call requires computing the group hash (which, okay, it could be cached) and serializing a struct. It would be nice to do something that's cheaper but still ties context into the secret key generation.
Update: This now uses HPKE's function to do all the heavy lifting

Related discussion:
text: A hash function <del> A Diffie-Hellman finite-field group or elliptic curve group </del> <ins> A key encapsulation mechanism (KEM) </ins> An AEAD encryption algorithm A signature algorithm <del> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps octet strings with length Hash.length to HPKE key pairs. </del> <ins> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public <del> keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE specification for more information). </del> <ins> keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree
Code change:
A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits

Related discussion:
text: 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- <del> Compromise Security (PCS) guarantees than a Commit message. </del> <ins> Compromise Security (PCS) guarantees as a Commit message. </ins> 7.10.