jiebi/CodeConvo huggingface dataset:
Code change:
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, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :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: 6.1. <ins> 6.1.1. </ins> This ciphersuite uses the following primitives: Hash function: SHA-256
Code change:
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, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :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: curves, they SHOULD perform the additional checks specified in Section 7 of <del> 6.1.1. </del> <ins> 6.1.2. </ins> This ciphersuite uses the following primitives:
Code change:
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, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :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: The creator of the group constructs an Init message as follows: <del> Fetch a UserInitKey for each member (including the creator) </del> <ins> Fetch a ClientInitKey for each member (including the creator) </ins> Identify a protocol version and cipher suite that is supported by all proposed members. Construct a ratchet tree with its leaves populated with the public <del> keys and credentials from the UserInitKeys of the members, and all other nodes blank. </del> <ins> keys and credentials from the ClientInitKeys of the members, and all other nodes blank. </ins> Generate a fresh leaf key pair for the first leaf
Code change:
This PR begins filling in the IANA Considerations section, starting with a Ciphersuites registry. This addresses the concerns in as discussed at the interim (2019-10), namely by reserving for vendor use chunk of the code points space large enough to be selected at random without huge risk of collision (2^12 values). Depends on
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :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 .*
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today

Related discussion:
text: A hash function <del> A Diffie-Hellman finite-field group or elliptic curve </del> <ins> A Diffie-Hellman finite-field group or elliptic curve group </ins> An AEAD encryption algorithm
Code change:
In the latest HPKE draft (draft-irtf-cfrg-hpke-04), "Initiator (I)" was renamed to "Sender (S)".

Related discussion:
text: where "node_public_key" is the public key of the node that the path secret is being encrypted for, group_context is the current <del> GroupContext object for the group, and the functions "SetupBaseI" and </del> <ins> GroupContext object for the group, and the functions "SetupBaseS" and </ins> "Seal" are defined according to I-D.irtf-cfrg-hpke. Decryption is performed in the corresponding way, using the private
Code change:
NAME - I seem to recall you had some opinions on node hashing?
Right now the LeafNodeHashInput struct uses the index of the node among the leaves, while the ParentNodeHashInput struct uses the index of the node among all nodes. This means that, for example, the index value will be the same for the second leaf and its parent ( in both cases). We should probably just use the node index in both cases.
URL is a better solution

Related discussion:
text: left and right children, respectively.  When computing the hash of a leaf node, the hash of a "LeafNodeHashInput" object is used: <ins> Note that the "node_index" field contains the index of the leaf among the nodes in the tree, not its index among the leaves; "node_index = 2 * leaf_index". </ins> 7.6. Each member of the group maintains a GroupContext object that
Code change:
Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by

Related discussion:
text: An AEAD encryption algorithm <ins> A hash algorithm </ins> A signature algorithm The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke
Code change:
Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by

Related discussion:
text: Application messages <del> The sender information used to look up the key for the content encryption is encrypted under AEAD using a random nonce and the "sender_data_key" which is derived from the "sender_data_secret" as follows: </del> <ins> 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. </ins> For handshake and application messages, a sequence of keys is derived via a "sender ratchet".  Each sender has their own sender ratchet,
Code change:
Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by

Related discussion:
text: each key/nonce pair MUST NOT be used to encrypt more than one message. <del> Keys, nonces and secrets of ratchets are derived using </del> <ins> Keys, nonces, and the secrets in ratchets are derived using </ins> DeriveAppSecret.  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 index of the sender's leaf in the
Code change:
Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by

Related discussion:
text: GroupContext for the current epoch, so that signatures are specific to a given group and epoch. <del> The ciphertext field of the MLSCiphertext object is produced by </del> <ins> 8.2. The "ciphertext" field of the MLSCiphertext object is produced by </ins> supplying the inputs described below to the AEAD function specified by the ciphersuite in use.  The plaintext input contains content and signature of the MLSPlaintext, plus optional padding.  These values
Code change:
Just to recap the options as I understand them: a) Today: encryptedsenderdata = AEAD(senderdatakey, senderdatanonce, (groupID, epoch), senderdata) encryptedcontent = AEAD(appkey[i][j], appkey[i][j], (groupID, epoch, encryptedsenderdata), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encryptedcontent = AEAD(appkey[i][j], appnonce[i][j], (groupID, epoch), content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encryptedcontent = Enc(appkey[i][j], appnonce[i][j], content) encryptedsenderdata = AEAD(senderdatakey, sample(encryptedcontent), (groupID, epoch, encryptedcontent), senderdata)
Earlier, we had considered a "masking" approach for sender data, much like QUIC does for . This approach would save 28 bytes of overhead (nonce + tag), but was abandoned because of uncertainty around the security of the masking approach. Since then, Bellare et al. published , which includes what is effectively a proof of the security properties of the QUIC scheme. The QUIC scheme is essentially scheme HN1 of the paper, the main difference being that QUIC encrypt not the nonce directly, but a packet number which is used to compute the nonce. Our application would be similar, since we would encrypt metadata used to encrypt the key and the nonce. Given this new analysis, is it time to bring back masking?
Fixed by

Related discussion:
text: The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS10_128_HPKE25519_AES128GCM_SHA256_Ed25519" which uses <del> Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES- 128-GCM with Ed25519 for symmetric encryption and signatures. </del> <ins> Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, AES for metadata masking, and Ed25519 for signatures. </ins> Values with the first byte 255 (decimal) are reserved for Private Use.
Code change:
cc NAME
NAME is the build expected to fail?
No, but the problem seem unrelated to your change, so we are all good.
Looks like it was a transient failure. Re-running resulted in success.
NAME points out that the HPKE version is not pinned. This is probably needed for interop. Version -07 should come sometime this week, so that seems like a perfectly fine version to use. I can send a PR when that version is cut.
Fixed by

Related discussion:
text: A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg- <del> hpke ) public key that can be used to encrypt to that client. </del> <ins> hpke) public key that can be used to encrypt to that client. </ins> A key package that is prepublished by a client, which other clients can use to introduce the client to a new group.
Code change:
cc NAME
NAME is the build expected to fail?
No, but the problem seem unrelated to your change, so we are all good.
Looks like it was a transient failure. Re-running resulted in success.
NAME points out that the HPKE version is not pinned. This is probably needed for interop. Version -07 should come sometime this week, so that seems like a perfectly fine version to use. I can send a PR when that version is cut.
Fixed by

Related discussion:
text: A signature algorithm <del> The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke for the purpose of public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </del> <ins> MLS uses draft-07 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. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol
Code change:
I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!

Related discussion:
text: Name: The name of the ciphersuite <del> 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. </del> <ins> 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. </ins> Reference: The document where this ciphersuite is defined
Code change:
I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!

Related discussion:
text: 16.3. This registry lists identifiers for types of credentials that can be <del> used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the </del> <ins> used for authentication in the MLS protocol.  The credential type field is two bytes wide, so valid credential type values are in the </ins> range 0x0000 to 0xffff. Template:
Code change:
I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!

Related discussion:
text: Name: The name of the credential type <del> Recommended: Whether support for this extension is recommended by </del> <ins> Recommended: Whether support for this credential is recommended by </ins> 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. <del> Reference: The document where this extension is defined </del> <ins> Reference: The document where this credential is defined </ins> Initial contents:
Code change:
The definition of blank node needs to move ahead into ## Ratchet Tree Terminology as it is used in the section immediately following (## Views of a Ratchet Tree).

Related discussion:
text: Each leaf is given an _index_ (or _leaf index_), starting at "0" from the left to "n-1" at the right. <ins> Finally, a node in the tree may also be _blank_, indicating that no value is present at that node (i.e. no keying material).  This is often the case when a leaf was recently removed from the tree. </ins> There are multiple ways that an implementation might represent a ratchet tree in memory.  For example, left-balanced binary trees can be represented as an array of nodes, with node relationships computed
Code change:
The definition of blank node needs to move ahead into ## Ratchet Tree Terminology as it is used in the section immediately following (## Views of a Ratchet Tree).

Related discussion:
text: The conditions under which each of these values must or must not be present are laid out in views. <del> 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 with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </del> <ins> 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 with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </ins> The resolution of a non-blank node comprises the node itself, followed by its list of unmerged leaves, if any