Change:
Metadata (sender information) <del> Proposal and Commit messages </del> <ins> Handshake messages (Proposal and Commit) </ins> Application messages The sender information used to look up the key for the content encryption is encrypted under AEAD using a random nonce and the <del> sender_data_key which is derived from the sender_data_secret as </del> <ins> "sender_data_key" which is derived from the "sender_data_secret" as </ins> follows: <del> Each handshake message is encrypted using a key and a nonce derived from the handshake_secret for a specific sender to prevent two senders to perform in the following way: </del> <ins> 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". </ins> <del> Here the value [sender] represents the index of the member that will use this key to send, encoded as a uint32.  Each sender maintains two "generation" counters, one for application messages and one for handshake messages.  These counters are incremented by one each time the sender sends a message. </del> <ins> A sender ratchet starts from a per-sender base secret.  For application keys, the base secret is derived as described in astree. For handshake keys, base secrets are derived directly from the "handshake_secret". </ins> <del> For application messages, a chain of keys is derived for each sender in a similar fashion.  This allows forward secrecy at the level of application messages within and out of an epoch.  A step in this chain (the second subscript) is called a "generation".  The details of application key derivation are described in the astree section below. </del> <ins> The base secret of for each sender is used to initiate 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.  In particular, each key/nonce pair MUST NOT be used to encrypt more than one message. </ins> <del> For handshake messages (Proposals and Commits), the same key is used for all messages, but the nonce is updated according to the generation of the message: </del> <ins> Keys, nonces and secrets of ratchets are derived using Derive-App- Secret.  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 ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet. </ins> <del> where "encode_big_endian()" encodes the generation in a big-endian integer of the same size as the base handshake nonce. </del> <ins> Here, AEAD.nonce_length and AEAD.key_length denote the lengths in bytes of the nonce and key for the AEAD scheme defined by the ciphersuite.  "ratchet" should be understood to mean "handshake" or "application" depending on the context. </ins> 7.11.

Discussion:
The current draft uses a hash ratchet to derive single-use keys for application messages, but for handshake messages, re-uses the same key with a sequence of different nonces. This results in a lot of unnecessary extra code. This PR uses the same hash ratchet for handshake and application messages. The only difference is in the base key for the hash ratchet. In the application case, we use the AStree. In the HS case, we derive the base keys directly from the handshake secret. The lack of a tree in the HS case means that either the client will do a linear number of derivations on the first send/receive, or it will keep the handshake secret around and not get FS for handshake messages within the epoch.
NAME - would appreciate your thoughts here
As discussed on the PR call: There's no point to FS for Proposals because clients have to cache the plaintext anyway Given that, the "flat derivation" approach should be fine We should have separate keys per sender to it easier to avoid nonce collisions Unclear whether we should derive nonces on a hash ratchet or use a counter
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :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 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - 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 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - 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 .
Please merge when you have chance.