Discord Audio & Video End-to-End Encryption (DAVE) Protocol

The Discord Audio & Video End-to-End Encryption (DAVE) protocol (version 1.1) provides E2EE for DM/GDM calls, server voice channels, and Go Live streams.

Core Workflow

1. Protocol Negotiation: The Voice Gateway selects the appropriate DAVE protocol version for the media session members.
2. Group Key Exchange: Members perform a group key exchange using the Messaging Layer Security (MLS) protocol. The Voice Gateway acts as the MLS delivery and authentication service.
3. Key Extraction: Once the MLS group is established, members export a ratcheted per-sender symmetric media encryption key for every sender in the session.
4. Media Encryption (Send-side): Using the WebRTC encoded transform API, senders encrypt encoded audio/video frames with their ratcheted symmetric sender key. The encrypted frame is then packetized by WebRTC into RTP packets and sent to the Selective Forwarding Unit (SFU).
5. Media Decryption (Receive-side): The WebRTC depacketizer reconstructs the E2EE frame from RTP packets. A receive-side frame transformer then uses the sender's specific ratcheted symmetric sender key to decrypt the frame before returning the decoded frame to WebRTC.

Key Components

• Voice Gateway: A websocket server that handles RTC signaling, coordination, and acts as the MLS delivery/authentication service.
• Selective Forwarding Unit (SFU): Relays RTP audio and video traffic between members.
• MLS (Messaging Layer Security): The underlying group key exchange protocol.
• WebRTC Encoded Transform API: The interface used to intercept and transform encoded frames for encryption/decryption.

The encrypting frame transformer is codec-aware. It determines which parts of a frame must remain unencrypted so they can pass through WebRTC packetizers/depacketizers.

Supported Codec Behaviors:

The DAVE protocol is designed to protect audio and video communications against passive and active eavesdroppers, including insiders (Discord employees/infrastructure maintainers), outsiders (unauthorized network actors), and participants (former or future call members).

Security Goals

• Confidentiality: Only active, authorized participants can access call contents. Forward secrecy ensures departed participants cannot access future communications, and backward secrecy ensures new participants cannot access prior communications.
• Integrity: Prevents non-participants from tampering with, forging, or replaying encrypted calls.
• Authenticity: Ensures participants can identify each other and trust they are communicating with expected parties.

Explicit Limitations

• Metadata Disclosure: Metadata (call existence, participants, duration, etc.) remains visible to insiders and outsiders.
• Software/Device Compromise: The protocol cannot protect against vulnerabilities in Discord's software or a compromise of a participant's underlying device (e.g., credential theft or code execution).
• Denial of Service: The protocol does not guarantee availability; insider adversaries can still deny service to specific users.

To be considered a valid protocol frame for decryption, an incoming frame must satisfy several criteria. If a frame fails these checks, it will not be processed. In 'passthrough mode', only frames that fail this check (or are specific silence packets) are passed through untransformed.

Criteria for a protocol frame:

• Minimum Size: Must be large enough to contain the minimum expected protocol supplemental data.
• Magic Marker: Must contain the magic marker bytes 0xFAFA in the expected position.
• Supplemental Data Size:
  • Must be larger than the minimum protocol supplemental data size.
  • Must be smaller than the total size of the frame.
• Nonce: Must contain a ULEB128 encoded nonce.
• Unencrypted Ranges: Must contain valid ULEB128 encoded unencrypted ranges that are:
  • Ordered by ascending range offset.
  • Distinct and non-overlapping.
  • Not overflowing the total size of the interleaved media frame.

Note on Magic Markers: For video frames spanning multiple packets, only the last packet of the protocol frame includes the magic marker. If the SFU drops this last packet, the receiver cannot reconstruct the frame.

The DAVE protocol uses an interleaved media frame format to allow unencrypted metadata to pass through WebRTC packetizers/depacketizers while encrypting the actual media.

Payload Structure:

1. Interleaved protocol media frame (variable): Contains the actual media data. Some parts are unencrypted (plaintext) and some are encrypted (ciphertext). The unencrypted ranges are defined in the footer.
2. Truncated 8-byte AES-GCM authentication tag: A 64-bit tag used for integrity.
3. Truncated ULEB128 synchronization nonce (variable): A compressed nonce.
4. Unencrypted range ULEB128 offset/length pairs (variable): Defines the locations and sizes of the plaintext segments.
5. Protocol supplemental data size (1 byte): Size of the footer.
6. Magic Marker (2 bytes): The constant 0xFAFA.

/* Payload Layout Diagram */
// 0                   1                   2                   3
// 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// /                                                               /
// +            Interleaved protocol media frame (variable)        +
// /                                                               /
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |                                                               |
// +          Truncated 8-byte AES-GCM authentication tag          |
// |                                                               |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// /       Truncated ULEB128 synchronization nonce (variable)      /
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// /    Unencrypted range ULEB128 offset/length pairs (variable)   /
// +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// /               |  Suppl. Size  |      Magic Marker 0xFAFA      |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

During the transition period where E2EE is not yet mandatory, sessions may switch between transport-only encryption and E2EE.

Upgrade (Transport-only $\rightarrow$ E2EE)

When the participant list changes to include only DAVE-supporting clients, the gateway announces a protocol change via dave_protocol_prepare_epoch (opcode 24) and initiates MLS group creation.

Downgrade (E2EE $\rightarrow$ Transport-only)

When a non-supporting client joins:

1. The gateway broadcasts dave_protocol_prepare_transition (opcode 21) to announce a transition to protocol version 0.
2. Clients enable Passthrough Mode on receive-side frame transforms and report readiness via dave_protocol_ready_for_transition (opcode 23).
3. Upon dave_protocol_execute_transition (opcode 22), clients immediately switch send-side transforms to passthrough mode.

Passthrough Mode

In non-E2EE sessions or during transitions, WebRTC encoded transforms use a passthrough mode. This allows media frames to pass to WebRTC without modification. Only frames that fail the protocol frame check are passed through.

The Discord voice gateway acts as the MLS delivery service. It manages the current epoch, group members, and leaf node indexes.

External Sender Requirements:

• The gateway must be added as an external_sender using the MLS group extension external_senders.
• Before initial group negotiation or adding new members, the gateway must send its credential and signature public key to all members via dave_mls_external_sender_package (opcode 25).
• Security Requirement: New members must verify there is exactly one external sender with a credential/signature public key matching what was received from the gateway.

Proposal Handling:

• Only Add and Remove proposals sent by the gateway's external sender are permitted.
• Proposals are broadcast via dave_mls_proposals (opcode 27).
• Clients must reject any proposal that is not an allowed type or is not from the expected external sender.