End-to-End Secure Objects for Media over QUIC Transport

1.1. 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.¶

E2EE:

End-to-End Encryption¶

HBH:

Hop-by-Hop¶

varint:

[MoQ-TRANSPORT] variable length integer (Section 1.4.1).¶

3.1. Properties

MoQT defines mutable and immutable properties for objects. This specification uses MoQT immutable properties to convey end-to-end authenticated metadata and adds encrypted object properties (see Section 4.2). The Encrypted Properties List is serialized and encrypted along with the Object payload, decrypted and deserialized by the receiver. This specification further defines the Secure Object Key ID property (see Section 4.1), which is transmitted within the immutable properties.¶

3.2. Setup Assumptions

The application assigns each track a set of (Key ID, track_base_key) tuples, where each track_base_key is known only to authorized original publishers and end subscribers for a given track. How these per-track secrets and their lifetimes are established is outside the scope of this specification. The application also defines which Key ID should be used for a given encryption operation. For decryption, the Key ID is obtained from the Secure Object Key ID property (that is contained within the immutable properties of the Object). The scope of a Key ID is the namespace so if two tracks inside the same namespace have different tracks_base_keys, then they need to have different Key ID values. This design is to support a single key across many tracks where a client uses subscribe namespace to get new tracks as they are created in the namespace.¶

Applications determine the ciphersuite to be used for each track's encryption context. See Section 7.2 for the list of ciphersuites that can be used.¶

3.3. Application Procedure

This section provides steps for applications over MoQT to use mechanisms defined in this specification.¶

Serialized Full Track Name = Serialize(Track Namespace)
                             + Serialize(Track Name)

pt = Serialize(original_payload)
     + Serialize(Encrypted Properties List)

ciphertext = encrypt(pt)

pt = decrypt(ciphertext)

3.4. Encryption Schema

MoQT secure object protection relies on an ciphersute to define the AEAD encryption algorithm and hash algorithm in use (Section 7.2). We will refer to the following aspects of the AEAD and the hash algorithm below:¶

• AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption functions for the AEAD. We follow the convention of RFC 5116 [RFC5116] and consider the authentication tag part of the ciphertext produced by AEAD.Encrypt (as opposed to a separate field as in SRTP [RFC3711]).¶

• AEAD.Nk - The size in bytes of a key for the encryption algorithm¶

• AEAD.Nn - The size in bytes of a nonce for the encryption algorithm¶

• AEAD.Nt - The overhead in bytes of the encryption algorithm (typically the size of a "tag" that is added to the plaintext)¶

• AEAD.Nka - For cipher suites using the compound AEAD described in (Section 4.5.1 of [SFRAME]), the size in bytes of a key for the underlying encryption algorithm¶

• Hash.Nh - The size in bytes of the output of the hash function¶

3.5. Metadata Authentication

The Key ID, Full Track Name, Immutable Properties, Group ID, Object ID, and Publisher Priority for a given MoQT Object are authenticated as part of secure object encryption. This ensures, for example, that encrypted objects cannot be replayed across tracks and that the publisher's intended priority cannot be modified without detection.¶

When protecting or unprotecting a secure object, the following data structure captures the input to the AEAD function's AAD argument:¶

SECURE_OBJECT_AAD {
    Group ID (64),
    Object ID (32),
    Publisher Priority (8),
    Serialized Immutable Properties (..)
}

The Group ID and Object ID fields are encoded as 64-bit and 32-bit unsigned integers respectively in big-endian (network) byte order. This fixed-width encoding ensures that both sender and receiver construct identical AAD values without ambiguity, as variable-length integer encodings permit multiple valid representations of the same value.¶

Serialized Immutable Properties MUST include the Secure Object Key ID property containing the Key ID. This serves as the semantic equivalent of the KID field in SFrame.¶

3.6. Nonce Formation

The Group ID and Object ID for an object are used to form a 96-bit counter (CTR) value, which is XORed with a salt to form the nonce used in AEAD encryption. The counter value is formed by encoding the Group ID as a 64-bit big-endian unsigned integer, followed by the Object ID encoded as a 32-bit big-endian unsigned integer. This encryption/decryption will fail if applied to an object where group ID is larger than 2^64-1 or the object ID is larger than 2^32-1 and the MoQT Object MUST NOT be processed further.¶

MOQT supports Object IDs larger than 32 bits. However, for common AEAD ciphers such as AES-GCM, performance is better when the nonce is 96 bits. For MOQT’s primary use cases, applications can typically design their track, group, and object structure so that Object IDs do not need to exceed 32 bits, making this a reasonable performance tradeoff.¶

The Group ID and Object ID could both have been limited to, for example, 48 bits each. However, because 32 bit Object IDs were large enough for the identified use cases, the Object ID field was left at 32 bits.¶

3.7. Key and Salt Derivation

Encryption and decryption use a key and salt derived from the track_base_key associated with a Key ID. Given a track_base_key value, the key and salt are derived using HMAC-based Key Derivation Function (HKDF) [RFC5869] as follows:¶

def derive_key_salt(key_id,track_base_key,
                    serialized_full_track_name):
  moq_secret = HKDF-Extract("", track_base_key)
  moq_key_label = "MOQ 1.0 Secure Objects Secret key "
                + serialized_full_track_name
                + cipher_suite + key_id
  moq_key =
    HKDF-Expand(moq_secret, moq_key_label, AEAD.Nk)
  moq_salt_label = "MOQ 1.0 Secret salt "
                 + serialized_full_track_name
                 + cipher_suite + key_id
  moq_salt =
    HKDF-Expand(moq_secret, moq_salt_label, AEAD.Nn)

  return moq_key, moq_salt

In the derivation of moq_secret:¶

• The + operator represents concatenation of byte sequences.¶

• The Key ID value is encoded as an 8-byte big-endian integer.¶

• The cipher_suite value is a 2-byte big-endian integer representing the cipher suite in use (see [SFRAME]).¶

The hash function used for HKDF is determined by the cipher suite in use.¶

3.8. Encryption

MoQT secure object encryption uses the AEAD encryption algorithm for the cipher suite in use. The key for the encryption is the moq_key derived from the track_base_key Section 3.7. The nonce is formed by first XORing the moq_salt with the current CTR value Section 3.6, and then encoding the result as a big-endian integer of length AEAD.Nn.¶

The Encrypted Properties List and Object payload field from the MoQT object are used by the AEAD algorithm for the plaintext.¶

The encryptor forms an SecObj header using the Key ID value provided.¶

The encryption procedure is as follows:¶

1. Obtain the plaintext payload to encrypt from the MoQT object. Extract the Group ID, Object ID, and the Serialized Immutable Properties from the MoQT object headers. Ensure the Secure Object Key ID property is included, with the Key ID set as its value.¶

2. Retrieve the moq_key and moq_salt matching the Key ID.¶

3. Form the aad input as described in Section 3.5.¶

4. Form the nonce by as described in Section 3.6.¶

5. Apply the AEAD encryption function with moq_key, nonce, aad, MoQT Object payload and serialized Encrypted Properties List as inputs (see Section 3.3).¶

The final SecureObject is formed from the MoQT transport headers, followed by the output of the encryption.¶

3.9. Decryption

For decrypting, the Key ID from the Secure Object Key ID property contained within the immutable properties is used to find the right key and salt for the encrypted object. The MoQT track information matching the Key ID along with Group ID and Object ID fields of the MoQT object header are used to form the nonce.¶

The decryption procedure is as follows:¶

1. Parse the SecureObject to obtain Key ID, the ciphertext corresponding to MoQT object payload and the Group ID and Object ID from the MoQT object headers.¶

2. Retrieve the moq_key, moq_salt and MoQT track information matching the Key ID.¶

3. Form the aad input as described in Section 3.5.¶

4. Form the nonce by as described in Section 3.6.¶

5. Apply the AEAD decryption function with moq_key, nonce, aad and ciphertext as inputs.¶

6. Decode the Encrypted Properties List, returning both the properties and the object payload.¶

If extracting Key ID fails either due to missing Secure Object Key ID property within immutable properties or error from parsing, the client MUST discard the received MoQT Object.¶

If a ciphertext fails to decrypt because there is no key available for the Key ID value presented, the client MAY buffer the ciphertext and retry decryption once a key with that Key ID is received. If a ciphertext fails to decrypt for any other reason, the client MUST discard the ciphertext. Invalid ciphertexts SHOULD be discarded in a way that is indistinguishable (to an external observer) from having processed a valid ciphertext. In other words, the decryption operation should take the same amount of time regardless of whether decryption succeeds or fails.¶

4.1. Key ID Property

Key ID (Property Type 0x2) is a variable length integer and identifies the keying material (keys, nonces and associated context for the MoQT Track) to be used for a given MoQT track.¶

The Key ID property is included within the Immutable Properties. All objects encoded MUST include the Key ID property when using this specification for object encryption.¶

4.2. Encrypted Properties List

The Encrypted Properties List (Property Type 0xA) is a container that holds a sequence of Key-Value-Pairs (see Section 1.4.3 of [MoQ-TRANSPORT]) representing one or more Object Properties. These properties can be added by the Original Publisher and are encrypted along with the Object Payload, making them accessible only to End Subscribers.¶

Encrypted Properties List {
  Type (0xA),
  Length (i),
  Key-Value-Pair (..) ...
}

4.3. Padding Property

The Padding Property (Property Type 0x32) allows the Original Publisher to pad the encrypted payload to obscure the actual size of the object payload, helping mitigate traffic analysis attacks.¶

Padding Property {
  Type (0x32),
  Length (16),
  Padding (...)
}

Unlike other properties where the Length field uses the MOQ variable- length integer encoding, the Padding Property always encodes its Length as a 2-byte (16-bit) unsigned integer in network byte order. This fixed- size encoding simplifies computing the amount of padding to add.¶

The Padding field contains Length bytes, all of which SHOULD be set to zero (0x00). Receivers MUST ignore the contents of the Padding field.¶

This property is included within the Encrypted Properties List, ensuring that the padding bytes are encrypted along with the object payload and other encrypted properties. The Padding Property MUST be the last property in the Encrypted Properties List if present.¶

6.1. Threat Model

MoQT Objects are published by Original Publishers and delivered to End Subscribers, potentially through one or more Relays. Each MoQT connection is protected hop-by-hop using TLS. Security on cross Relay links is outside the scope of MoQT, but this specification assumes protection equivalent to TLS on those links.¶

Because security is hop-by-hop, each Relay terminates a security association and can observe, modify, drop, delay, reorder, or replay MoQT data. Some message fields are expected to be modified by Relays during normal operation, while other fields are expected to be visible but immutable. See [MoQ-TRANSPORT] for details.¶

This specification assumes that the Original Publisher and End Subscriber share one or more symmetric keys per Track, each identified by a Key ID. Key distribution and key negotiation are out of scope for this document (e.g., MLS could be used).¶

In MoQT, sending multiple Objects with the same Track, Group ID, and Object ID but different values is a Malformed Track Error. This specification therefore assumes the Original Publisher does not publish modified versions of the same Object.¶

This specification enables an End Subscriber to:¶

1. detect Relay modification of an Object's Original Payload, Encrypted Properties, Immutable Properties, Publisher Priority, Group ID, or Object ID;¶

2. detect delivery of an Object under the wrong Track Name or with a modified Key ID;¶

3. verify that the Original Payload and Encrypted Properties remained confidential from Relays; and¶

4. detect some (but not all) Object drops or replays in limited cases (see Section 6.4).¶

This specification does not enable an End Subscriber to reliably detect:¶

• complete suppression of all Objects by a Relay;¶

• Relay-induced delay or reordering of Objects.¶

6.2. Cryptographic Design

The cryptographic computations described in this document are exactly those performed in the SFrame encryption scheme defined in [SFRAME], The scheme in this document is effectively a "virtualized" version of SFrame:¶

• The CTR value used in nonce formation is not carried in the object payload, but instead synthesized from the GroupID and ObjectID.¶

• The AAD for the AEAD operation is not sent on the wire (as with the SFrame Header), but constructed locally by the encrypting and decrypting endpoints.¶

• The format of the AAD is different but contains the same semantic information:¶

  • The Group ID and Object ID are combined to form what is the CTR in SFrame.¶

  • The Key ID (KID) is contained in the Serialized Immutable Properties rather than a separate header field.¶

  • The SFrame Header is constructed using MoQT-style varints, instead of the variable-length integer scheme defined in SFrame.¶

• The metadata input in to SFrame operations is defined to be the FullTrackName value for the object.¶

• The labels used in key derivation reflect MOQ usage, not generic SFrame.¶

The security considerations discussed in the SFrame specification thus also apply here.¶

The SFrame specification lists several things that an application needs to account for in order to use SFrame securely, which are all accounted for here:¶

1. Header value uniqueness: Uniqueness of CTR values follows from the uniqueness of MoQT (GroupID, ObjectID) pairs. We only use one Key ID value, but instead use distinct SFrame contexts with distinct keys per track. This assures that the same (track_base_key, Key ID, CTR) tuple is never used twice.¶

2. Key management: We delegate this to the MoQT application, with subject to the assumptions described in Section 3.2.¶

3. Anti-replay: Replay is not possible within the MoQT framework because of the uniqueness constraints on ObjectIDs and objects, and because the group ID and object ID are cryptographically bound to the secure object payload.¶

4. Metadata: The analogue of the SFrame metadata input is defined in Section 3.5.¶

Any of the ciphersuites defined in Section 7.2 registry can be used to protect MoQT objects. The caution against short tags in Section 7.5 of [SFRAME] still applies here, but the MoQT environment provides some safeguards that make it safer to use short tags, namely:¶

• MoQT has hop-by-hop protections provided by the underlying QUIC layer, so a brute-force attack could only be mounted by a relay.¶

• In some usecases MoQT tracks have predictable object arrival rates, so a receiver can interpret a large deviation from this rate as a sign of an attack.¶

• The binding of the secure object payload to other MoQT parameters (as metadata), together with MoQT's uniqueness properties ensure that a valid secure object payload cannot be replayed in a different context.¶

6.3. AEAD Invocation Limits

AEAD algorithms have limits on how many times a single key can be used before the cryptographic guarantees begin to degrade. Exceeding these limits can compromise confidentiality (allowing an attacker to distinguish encrypted content from random data) or integrity (allowing an attacker to forge valid ciphertexts). The severity of these risks depends on the specific algorithm in use.¶

Implementations MUST track the number of encryption and decryption operations performed with each moq_key and ensure that these counts remain within the limits specified in [AEAD-LIMITS] for the cipher suite in use. When approaching these limits, implementations MUST arrange for new keying material to be established (e.g., by rotating to a new Key ID with a fresh track_base_key) before the limits are exceeded.¶

For the AES-GCM cipher suites defined in this document, the primary concern is the confidentiality limit, which restricts the number of encryptions performed with a single key. For AES-CTR-HMAC cipher suites, both encryption and decryption operations count toward the applicable limits.¶

6.4. Detecting Deletion by Malicious Relays

A malicious relay could selectively delete objects or groups before forwarding them to subscribers. While this specification does not mandate detection of such deletions, it does provide mechanisms that applications can use to detect when content has been removed.¶

Some applications may not require deletion detection, or may be able to detect missing data based on the internal structure of the object payload (e.g., sequence numbers embedded in the media format). For applications that do require deletion detection at the MoQT layer, the following approaches are available:¶

6.5. Signaling End of Content

For applications that need to reliably detect lost objects at the end of a subgroup, group, or track, it is RECOMMENDED to signal completion using object status values defined in [MoQ-TRANSPORT]. By explicitly marking the final object in a sequence, subscribers can distinguish between "more objects may arrive" and "all objects have been sent," enabling detection of trailing deletions that would otherwise be undetectable.¶

Publishers SHOULD send an End of Group status (0x3) as the final object in each group. This allows subscribers to determine whether all objects up to that Object ID have been received, enabling detection of any missing objects at the end of the group.¶

Publishers SHOULD send an End of Track status (0x4) when the track is complete (e.g., end of a recorded stream or live session). This allows subscribers to determine whether all objects up to that location have been received, enabling detection of any missing objects at the end of the track.¶

For subgroup boundaries, the transport stream closure (FIN) signals that all objects in the subgroup have been delivered.¶

7.1. MOQ Object Properties Registry

This document defines new MoQT Object properties under the MOQ Object Properties registry.¶

Note: The Encrypted Properties List type (0xA) appears only within the encrypted payload structure defined in Section 3.3, not as a regular MoQT Object Property. It is registered here to reserve the type value and prevent conflicts with the property type field used in the encrypted payload format.¶

7.2. Cipher Suites

This document establishes a "MoQ Secure Objects Cipher Suites" registry. Each cipher suite specifies an AEAD encryption algorithm and a hash algorithm used for key derivation.¶

The following values are defined for each cipher suite:¶

• Nh: The size in bytes of the hash function output¶

• Nka: The size in bytes of the encryption key for the underlying cipher (CTR suites only)¶

• Nk: The size in bytes of the AEAD key¶

• Nn: The size in bytes of the AEAD nonce¶

• Nt: The size in bytes of the AEAD authentication tag¶

The "R" column indicates whether the cipher suite is Recommended:¶

• Y: Indicates that the IETF has consensus that the item is RECOMMENDED. Requires Standard Action as defined [RFC8126].¶

• N: Indicates the IETF has made no statement about the suitability of the associated mechanism. Requires First Come First Serve as defined in [RFC8126].¶

• D: Indicates that the item is discouraged and SHOULD NOT be used. Requires Standard Action or IESG Approval as defined in [RFC8126].¶

Cipher suite values are 2-byte big-endian integers. The algorithms are the same as defined in SFrame ciphersuites defined in the IANA SFrame Cipher Suites -registry [CIPHERS].¶

AES-GCM cipher suites (0x0004, 0x0005) use AES-GCM for authenticated encryption with a full 128-bit authentication tag.¶

AES-CTR-HMAC cipher suites (0x0001, 0x0002, 0x0003) use AES in counter mode combined with HMAC for authentication in an encrypt-then-MAC construction. These suites support truncated authentication tags, providing lower overhead at the cost of reduced forgery resistance.¶

Implementations MUST support AES_128_GCM_SHA256_128 (0x0004). Implementations SHOULD support AES_128_CTR_HMAC_SHA256_80 (0x0001).¶

8.1. Normative References

[AEAD-LIMITS]

Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-11, 4 December 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-11>.

[MoQ-TRANSPORT]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-18, 12 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-18>.

[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>.

[RFC5116]

McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/rfc/rfc5116>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[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>.

[SFRAME]

Omara, E., Uberti, J., Murillo, S. G., Barnes, R., Ed., and Y. Fablet, "Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media", RFC 9605, DOI 10.17487/RFC9605, August 2024, <https://www.rfc-editor.org/rfc/rfc9605>.

8.2. Informative References

[CIPHERS]

IANA, "SFrame Cipher Suites", <https://www.iana.org/assignments/sframe/sframe.xhtml#sframe-cipher-suites>.

[RFC3711]

Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/rfc/rfc3711>.

B.1. Full Track Name Serialization

Each entry tests serialization of Track Namespace tuples and Track Name into the Serialized Full Track Name byte string.¶

[
  {
    "namespace_tuples": ["example.com"],
    "track_name": "audio",
    "serialized_full_track_name":
      "010b6578616d706c652e636f6d05617564696f"
  },
  {
    "namespace_tuples": ["example.com", "meeting-123"],
    "track_name": "video",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f"
  },
  {
    "namespace_tuples": ["example.com", "meeting-123", "floor-1"],
    "track_name": "slides",
    "serialized_full_track_name":
      "030b6578616d706c652e636f6d0b6d656574696e672d31323307666c6f6f722d3106736c69646573"
  }
]

B.2. Key Derivation

Each entry tests HKDF-Extract and HKDF-Expand for deriving moq_key and moq_salt from the track_base_key. The track_base_key values are ASCII strings: "sixteen byte key" (16 bytes) for SHA-256 suites and "a]256-bit-base-key-for-test!!!!!" (32 bytes) for SHA-512 suites. Intermediate values (moq_secret, moq_key_label, moq_salt_label) are included to aid debugging.¶

[
  {
    "cipher_suite": 1,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00010000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00010000000000000007",
    "moq_key":
      "36543f1f0d00ea1c6ecacaab3ec878772ef6e4bf7e91f29a1fa99af410802420fa92560c1850654f5ae7fa0281d3d1d9",
    "moq_salt": "e905de3e41c5feb642a8ea58"
  },
  {
    "cipher_suite": 2,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00020000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00020000000000000007",
    "moq_key":
      "12acb1032ea6b0c8ee2c1f9cfe052f0d13220782a559c50e669645951bb15ed1c93ae2ff02b411649e0aa99aec19b865",
    "moq_salt": "17efc7dfcc10786fa00771b8"
  },
  {
    "cipher_suite": 4,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00040000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00040000000000000007",
    "moq_key": "eb3b95606d7c4775688c121e8f06832c",
    "moq_salt": "dc11a8d516c299f44b24be8d"
  },
  {
    "cipher_suite": 5,
    "key_id": 7,
    "track_base_key":
      "615d3235362d6269742d626173652d6b65792d666f722d746573742121212121",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "moq_secret":
      "f633519ec99705bae4bcc7fe0f88ccd3c0301355d97d2265773d8b80ccf23ca39d500bc2d5399315bf78bfc5ed69f8be7b6799cfb35691ffe2db6126ab9e897d",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00050000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00050000000000000007",
    "moq_key":
      "03a7b0a238bde6d398c0c8de14538c31c8f84a4356a01f5ca00d9a46d4046953",
    "moq_salt": "2c82451648c8d25e94b8dbdc"
  }
]

B.3. Nonce and AAD Formation

Each entry tests CTR construction from Group ID and Object ID, nonce formation by XOR with salt, and SECURE_OBJECT_AAD serialization. All entries use AES_128_GCM_SHA256_128 (cipher suite 0x0004) with Key ID 7.¶

[
  {
    "group_id": 0,
    "object_id": 0,
    "publisher_priority": 0,
    "key_id": 7,
    "serialized_immutable_properties": "",
    "moq_salt": "dc11a8d516c299f44b24be8d",
    "ctr": "000000000000000000000000",
    "nonce": "dc11a8d516c299f44b24be8d",
    "aad": "0000000000000000000000000000020107"
  },
  {
    "group_id": 42,
    "object_id": 1,
    "publisher_priority": 128,
    "key_id": 7,
    "serialized_immutable_properties": "",
    "moq_salt": "dc11a8d516c299f44b24be8d",
    "ctr": "000000000000002a00000001",
    "nonce": "dc11a8d516c299de4b24be8c",
    "aad": "000000000000002a000000018000020107"
  },
  {
    "group_id": 18446744073709551615,
    "object_id": 4294967295,
    "publisher_priority": 255,
    "key_id": 7,
    "serialized_immutable_properties": "",
    "moq_salt": "dc11a8d516c299f44b24be8d",
    "ctr": "ffffffffffffffffffffffff",
    "nonce": "23ee572ae93d660bb4db4172",
    "aad": "ffffffffffffffffffffffffff00020107"
  }
]

B.4. Full Encryption

Each entry tests the complete encryption pipeline including key derivation, nonce formation, AAD construction, and AEAD encryption. The plaintext field shows the serialized input to AEAD: varint(payload_len) || payload || encrypted_properties_list. All entries include both immutable properties (which affect the AAD) and encrypted properties (which are encrypted with the payload).¶

Common inputs (ASCII values shown for readability):¶

• track_base_key: "sixteen byte key" (16B) or "a]256-bit-base-key-for-test!!!!!" (32B)¶

• original_payload: "hello from moq"¶

• immutable_properties: property type 0x0004, value "relay-ok"¶

• encrypted_properties_list: property type 0x0100, value "for-eyes-only"¶

[
  {
    "cipher_suite": 1,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "namespace_tuples": ["example.com", "meeting-123"],
    "track_name": "video",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "group_id": 42,
    "object_id": 1,
    "publisher_priority": 128,
    "immutable_properties": "00040872656c61792d6f6b",
    "original_payload": "68656c6c6f2066726f6d206d6f71",
    "encrypted_properties_list":
      "000a1001000d666f722d657965732d6f6e6c79",
    "plaintext":
      "0e68656c6c6f2066726f6d206d6f71000a1001000d666f722d657965732d6f6e6c79",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00010000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00010000000000000007",
    "moq_key":
      "36543f1f0d00ea1c6ecacaab3ec878772ef6e4bf7e91f29a1fa99af410802420fa92560c1850654f5ae7fa0281d3d1d9",
    "moq_salt": "e905de3e41c5feb642a8ea58",
    "ctr": "000000000000002a00000001",
    "nonce": "e905de3e41c5fe9c42a8ea59",
    "aad":
      "000000000000002a00000001800002010700040872656c61792d6f6b",
    "ciphertext":
      "170654428664c29b3eab20a76e86ab2c2fc210b218b38eb556974021b7804b1d7ced925e33e3d6080e8157d4"
  },
  {
    "cipher_suite": 2,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "namespace_tuples": ["example.com", "meeting-123"],
    "track_name": "video",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "group_id": 42,
    "object_id": 1,
    "publisher_priority": 128,
    "immutable_properties": "00040872656c61792d6f6b",
    "original_payload": "68656c6c6f2066726f6d206d6f71",
    "encrypted_properties_list":
      "000a1001000d666f722d657965732d6f6e6c79",
    "plaintext":
      "0e68656c6c6f2066726f6d206d6f71000a1001000d666f722d657965732d6f6e6c79",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00020000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00020000000000000007",
    "moq_key":
      "12acb1032ea6b0c8ee2c1f9cfe052f0d13220782a559c50e669645951bb15ed1c93ae2ff02b411649e0aa99aec19b865",
    "moq_salt": "17efc7dfcc10786fa00771b8",
    "ctr": "000000000000002a00000001",
    "nonce": "17efc7dfcc107845a00771b9",
    "aad":
      "000000000000002a00000001800002010700040872656c61792d6f6b",
    "ciphertext":
      "df0fd1431b6883bcb841fa14d4588630aaf11c92363b536ecc08273a27ac4f47bd72fca55f29cd1fad9b"
  },
  {
    "cipher_suite": 4,
    "key_id": 7,
    "track_base_key": "7369787465656e2062797465206b6579",
    "namespace_tuples": ["example.com", "meeting-123"],
    "track_name": "video",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "group_id": 42,
    "object_id": 1,
    "publisher_priority": 128,
    "immutable_properties": "00040872656c61792d6f6b",
    "original_payload": "68656c6c6f2066726f6d206d6f71",
    "encrypted_properties_list":
      "000a1001000d666f722d657965732d6f6e6c79",
    "plaintext":
      "0e68656c6c6f2066726f6d206d6f71000a1001000d666f722d657965732d6f6e6c79",
    "moq_secret":
      "e5e76a372058231c56eedca06436c94e6f6bab38d759687367c92048faf93f18",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00040000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00040000000000000007",
    "moq_key": "eb3b95606d7c4775688c121e8f06832c",
    "moq_salt": "dc11a8d516c299f44b24be8d",
    "ctr": "000000000000002a00000001",
    "nonce": "dc11a8d516c299de4b24be8c",
    "aad":
      "000000000000002a00000001800002010700040872656c61792d6f6b",
    "ciphertext":
      "facafee5c450bd140759bdffa6eef6948ae6dbfdb7ba87cf3e161a641b27f952eb4f13b18e351d4e7e344675f0dc96e0cd5e"
  },
  {
    "cipher_suite": 5,
    "key_id": 7,
    "track_base_key":
      "615d3235362d6269742d626173652d6b65792d666f722d746573742121212121",
    "namespace_tuples": ["example.com", "meeting-123"],
    "track_name": "video",
    "serialized_full_track_name":
      "020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f",
    "group_id": 42,
    "object_id": 1,
    "publisher_priority": 128,
    "immutable_properties": "00040872656c61792d6f6b",
    "original_payload": "68656c6c6f2066726f6d206d6f71",
    "encrypted_properties_list":
      "000a1001000d666f722d657965732d6f6e6c79",
    "plaintext":
      "0e68656c6c6f2066726f6d206d6f71000a1001000d666f722d657965732d6f6e6c79",
    "moq_secret":
      "f633519ec99705bae4bcc7fe0f88ccd3c0301355d97d2265773d8b80ccf23ca39d500bc2d5399315bf78bfc5ed69f8be7b6799cfb35691ffe2db6126ab9e897d",
    "moq_key_label":
      "4d4f5120312e3020536563757265204f626a6563747320536563726574206b657920020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00050000000000000007",
    "moq_salt_label":
      "4d4f5120312e30205365637265742073616c7420020b6578616d706c652e636f6d0b6d656574696e672d31323305766964656f00050000000000000007",
    "moq_key":
      "03a7b0a238bde6d398c0c8de14538c31c8f84a4356a01f5ca00d9a46d4046953",
    "moq_salt": "2c82451648c8d25e94b8dbdc",
    "ctr": "000000000000002a00000001",
    "nonce": "2c82451648c8d27494b8dbdd",
    "aad":
      "000000000000002a00000001800002010700040872656c61792d6f6b",
    "ciphertext":
      "09399b821a1452a320a8bf927c004c71f8fd34449070f99746ff6ab0ef67a4f93b7f889e64d194a7b18a7a946184fed15386"
  }
]