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: Set group_id, epoch, content_type and authenticated_data fields from the MLSPlaintext object directly <del> Randomly generate the sender_data_nonce field </del> Identify the key and key generation depending on the content type <del> Encrypt an MLSSenderData object for the encrypted_sender_data field from MLSPlaintext and the key generation Generate and sign an MLSPlaintextTBS object from the MLSPlaintext object </del> Encrypt an MLSCiphertextContent for the ciphertext field using the <del> key identified, the signature, and MLSPlaintext object </del> <ins> 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. </ins> <del> Decryption is done by decrypting the metadata, then the message, and then verifying the content signature. </del> <ins> Decryption is done by decrypting the sender data, then the message, and then verifying the content signature. </ins> The following sections describe the encryption and signing processes in detail. 8.1. <del> The "sender data" used to look up the key for the content encryption is encrypted under AEAD using the MLSCiphertext sender_data_nonce and the sender_data_key from the keyschedule.  It is encoded as an object of the following form: 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 content-signing-and-encryption. The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely: When parsing a SenderData struct as part of message decryption, the recipient MUST verify that the sender field represents an occupied leaf in the ratchet tree.  In particular, the sender index value MUST be less than the number of leaves in the tree. 8.2. The signature field in an MLSPlaintext object is computed using the </del> <ins> The "signature" field in an MLSPlaintext object is computed using the </ins> signing private key corresponding to the credential at the leaf in the tree indicated by the sender field.  The signature covers the plaintext metadata and message content, which is all of MLSPlaintext