skip to content

When an SRTP session moves from AES_CM_128_HMAC_SHA1_80 to RFC 7714's AEAD_AES_128_GCM, what changes in the packet, the keys and the operator's obligations?

level: seniorimportance: should knowfreq 12%

answer

  1. one tag instead of two steps
  2. sixteen octets, never truncated
  3. 96-bit salt, 12-octet IV
  4. SSRC, ROC and SEQ in the IV
  5. collisions prevented, not detected

basics

~20 s

AEAD_AES_128_GCM replaces HMAC-SHA1 with one untruncated 16-octet AEAD tag, so packets grow 16 bytes, not 10. The salt shrinks to 96 bits to form a 12-octet IV, no separate authentication key is used, and the IV inputs must never repeat under one key.

solid answer

~50 s

Under RFC 7714 the AEAD tag is part of the ciphertext and MUST be a full 16 octets, so each SRTP packet grows by 16 bytes instead of 10, and the old SRTP/SRTCP authentication tag field SHOULD NOT be present. The master key stays 128 bits, the master salt drops from 112 to 96 bits, and no separate authentication key is used. The 12-octet IV is two zero octets, the SSRC, the ROC and the SEQ, XORed with the salt. SRTP packets MUST be both encrypted and authenticated, so there is no integrity-only GCM SRTP; SRTCP stays authenticated but may skip encryption per packet with the E flag. The operator's new duty is uniqueness: with a shared master key, RFC 7714 requires SSRC collisions to be prevented outright, and processing must stop before the packet index wraps. In DTLS-SRTP the profile is `SRTP_AEAD_AES_128_GCM {0x00,0x07}`.

go deeper

for a junior

Recall that the GCM profiles use one 16-byte tag in place of the HMAC-SHA1 tag, and are named AEAD_AES_128_GCM and AEAD_AES_256_GCM.

for a middle

Explain how the 12-octet IV is formed from SSRC, ROC and SEQ with a 96-bit salt, and compare per-packet overhead with the 80-bit HMAC profile.

for a senior

Name the operating duties GCM adds: SSRC collision prevention with shared keys, stopping before the index wraps, and authenticated-but-optional SRTCP encryption.

for a principal

Weigh GCM's stronger, untruncated tag and hardware efficiency against six more bytes per packet and stricter uniqueness rules across every media server.

## Side by side **AEAD_AES_128_GCM** (RFC 7714) replaces SRTP's two-step protection, counter-mode encryption then an HMAC-SHA1 tag, with one AES-GCM operation that encrypts the payload and authenticates both the payload and the header. The parameters change as follows: | Parameter | `AES_CM_128_HMAC_SHA1_80` | `AEAD_AES_128_GCM` | |---|---|---| | Master key | 128 bits | 128 bits | | Master salt | 112 bits | **96 bits** | | Session authentication key | 160 bits | **none used** | | Tag | 80-bit HMAC-SHA1, after the payload | **16-octet AEAD tag, inside the ciphertext** | | Added to each SRTP packet (no MKI) | 10 bytes | **16 bytes** | | Added to each SRTCP packet | 14 bytes (4-byte flag and index + tag) | **20 bytes** (16-byte tag + 4-byte flag and index) | | Key derivation | AES-CM PRF | AES-CM PRF (AES-256-GCM uses `AES_256_CM_PRF`) | | DTLS-SRTP name | `SRTP_AES128_CM_HMAC_SHA1_80` `{0x00,0x01}` | `SRTP_AEAD_AES_128_GCM` `{0x00,0x07}` | `AEAD_AES_256_GCM` is the same with a 256-bit key, code point `{0x00,0x08}`, and RFC 7714 §12 says any AES-GCM SRTP implementation MUST support both sizes. ## How the 12-octet IV is built Counter mode in the default profile builds a 128-bit counter block from a 112-bit salt and a 16-bit block counter. GCM splits the 16-byte block differently: a **12-octet IV** and a **32-bit block counter**. RFC 7714 §8.1 forms the SRTP IV in three steps: 1. Concatenate two octets of zero, the 4-octet **SSRC**, the 4-octet **rollover counter (ROC)** and the 2-octet **sequence number (SEQ)**: 12 octets. 2. XOR that value with the 12-octet (96-bit) **session salt**. 3. Use the result as the IV; the block counter starts at 1 for each packet, and the first block is reserved for the tag. For SRTCP (§9.1) the IV comes from the SSRC and the 31-bit SRTCP index instead. That is why the salt is 96 bits: 96 bits of IV plus 32 bits of block counter make one AES block. ## Where the tag goes GCM's output is the encrypted payload **followed by the 16-octet tag**, so the tag is counted inside the ciphertext. RFC 7714 §7.1 says the AEAD tag MUST be the primary authentication, the optional SRTP/SRTCP authentication tag field SHOULD NOT be present, and this knowingly overrides RFC 3711's rule that SRTCP carry its own tag. The tag MUST NOT be truncated: §13.2 records the working group's view that truncated GCM tags are too risky. The order of checks on receipt, authenticate before releasing anything, is a receiver concern handled with the replay window. ## The operator's new obligations - **No integrity-only mode for media.** RFC 7714 §8.2: all SRTP packets MUST be both authenticated and encrypted. Integrity-only media needs a NULL-cipher HMAC profile instead. - **SRTCP encryption is optional; authentication is not.** The sender sets the E flag per packet (§9). - **The IV inputs must never repeat under one key.** §8.4 requires that a (ROC, SEQ, SSRC) triple is never used twice with the same master key. With a shared master key, SSRC collisions MUST be **prevented**, not merely detected: each sender gets a disjoint SSRC pool, issued SSRCs are remembered, and SSRC signalling is integrity protected. - **Stop before wrap.** §13.1: processing MUST cease if the 48-bit SRTP index or 31-bit SRTCP index cycles back to its starting value, until a new master key is in place. - **Why it is stricter.** RFC 7714 §6 notes that repeating an IV under GCM compromises integrity for all future use of that key, not only confidentiality of the colliding packets; the general theory belongs to cryptographic foundations. ## Choosing between them - **For GCM:** an untruncated 16-octet tag, header and payload authenticated in one pass, and an operation RFC 7714 describes as well suited to fast hardware. - **For the counter-mode profile:** universal support (it is WebRTC's mandatory profile under RFC 8827), 6 fewer bytes per packet, and tolerance of the looser SSRC handling RFC 3711 allows. - A common stance is to offer GCM first and keep `_80` as the interoperable fallback, provided every endpoint and media server can meet the uniqueness rules. - Pick the key size at session set-up: RFC 7714 says it SHOULD NOT be altered afterwards, and `AEAD_AES_256_GCM` switches key derivation to RFC 6188's `AES_256_CM_PRF`. - Budget the bytes: 16 per media packet against 10, which on a 20-byte voice payload at 50 packets per second is 6.4 against 4.0 kbit/s per direction.

  • Why is the GCM master salt 96 bits when the counter-mode salt is 112 bits?
    Both fill one 128-bit AES block. The default counter mode reserves the low 16 bits for an in-packet block counter, leaving 112 for salt, SSRC and index. RFC 7714 fixes the GCM IV at 12 octets with a 32-bit block counter, so the salt XORed into that IV is 96 bits.
  • Can an AES-GCM SRTP session switch encryption off to send integrity-only media?
    Not for media. RFC 7714 §8.2 says every SRTP packet MUST be both authenticated and encrypted under the GCM profiles. Only SRTCP may go unencrypted, packet by packet via the E flag, and it stays authenticated. Integrity-only media needs a NULL-cipher profile such as `SRTP_NULL_HMAC_SHA1_80`.
  • Why does GCM with a shared master key need SSRC pools per sender?
    The SSRC is part of the IV, so two senders using the same SSRC under one master key can produce identical IVs. RFC 7714 §8.4 therefore requires each sender to draw SSRCs from its own disjoint pool, never reissue one within the key's lifetime, and rekey before any pool runs out.

saying these in an interview costs you the question

  • AES-GCM SRTP still appends the 80-bit HMAC-SHA1 tag after the GCM tag.
  • GCM SRTP uses the same 112-bit master salt as the counter-mode profiles.
  • Under GCM, an SSRC collision is harmless because the tag will catch it.
  • AEAD_AES_128_GCM uses a separate HMAC authentication key like the counter-mode profiles.
  • With GCM, SRTCP packets no longer need to be authenticated.