skip to content

In SRTP's default protection profile, AES_CM_128_HMAC_SHA1_80, what does each part of the name select, and why is there a 112-bit salt?

level: middleimportance: must knowfreq 30%

answer

  1. two transforms in one name
  2. confidentiality half, integrity half
  3. 160-bit key, 80-bit output
  4. salt plus a 16-bit block counter
  5. random, but may be public

basics

~20 s

AES_CM_128_HMAC_SHA1_80 is AES counter mode under a 128-bit master key for confidentiality, plus HMAC-SHA1 truncated to an 80-bit tag for integrity. The 112-bit salt, beside a 16-bit block counter, fills each counter block and blunts precomputation.

solid answer

~40 s

The name pairs two transforms. `AES_CM_128` is AES in counter mode with a 128-bit master key, which RFC 3711 §5 makes the default and mandatory-to-implement cipher. `HMAC_SHA1_80` is HMAC-SHA1 under a 160-bit session authentication key, its output truncated to an 80-bit tag, so each SRTP packet grows by 10 bytes. The 112-bit master salt exists because counter mode needs a 128-bit starting block per packet: the session salt, the SSRC and the packet index are XORed into its upper 112 bits, and the low 16 bits count AES blocks inside the packet. RFC 3711 §9.2 says the salt MUST be random but MAY be public; it defends against time-memory tradeoff attacks that amortise work across many keys. The same transform is `SRTP_AES128_CM_HMAC_SHA1_80`, code point `{0x00,0x01}`, in DTLS-SRTP.

go deeper

for a junior

Recall that the name joins a cipher (AES counter mode, 128-bit key) and an integrity check (HMAC-SHA1 cut to 80 bits), and that the tag adds bytes to every packet.

for a middle

Explain how the counter block is built from salt, SSRC and packet index, why that leaves 112 bits for the salt, and why the salt may be public yet still matters.

for a senior

Show you can read any profile name into key, salt, tag and overhead, and say what the default leaves exposed: clear headers, payload length, and a NULL cipher that is mandatory to implement.

for a principal

Frame the default as a floor that was tuned for 2004 voice: argue when its 128-bit master key and 80-bit tag are enough and when a platform should prefer larger keys or the GCM profiles.

## Reading the name left to right **SRTP** (RFC 3711) protects RTP media and RTCP control traffic with a *protection profile*: a fixed bundle of a cipher, a message authentication code and the lengths each one uses. The default bundle, and the one every implementation must support, is spelled `AES_CM_128_HMAC_SHA1_80` in SDP Security Descriptions (RFC 4568). Each token selects something: | Token | Selects | Length it fixes | |---|---|---| | `AES_CM` | AES in segmented integer counter mode, RFC 3711 §4.1.1 | 128-bit AES block | | `128` | the master key and the session encryption key | 128 bits | | `HMAC_SHA1` | the message authentication code, RFC 3711 §4.2.1 | 160-bit session authentication key | | `80` | how much of the HMAC output is sent | 80-bit (10-byte) tag | The salt does not appear in the name, but the profile fixes it too: a **112-bit master salt**, so the key and salt together are 30 octets. RFC 3711 §5 makes AES-CM, HMAC-SHA1 and the AES-CM key-derivation PRF the defaults, and says plainly that **mandatory-to-implement does not mean mandatory-to-use**. ## The confidentiality half: why counter mode needs a salt Counter mode turns AES into a seekable stream cipher: it encrypts a sequence of counter blocks and XORs the result onto the payload, so packet 1,000 can be decrypted without packets 1 to 999. Each packet needs its own starting block, and RFC 3711 builds it as: `IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)` 1. `k_s`, the 112-bit session salt, is shifted into the **upper 112 bits** of the 128-bit block. 2. The 32-bit **SSRC** is XORed in higher up, so streams sharing one key still get distinct keystreams. 3. The 48-bit **packet index** `i` (rollover counter and sequence number) is XORed in above the low 16 bits. 4. The **low 16 bits** are left at zero and count AES blocks within the packet; RFC 3711 caps that count at 2^16 blocks per IV. That is where 112 comes from: 112 bits of salt plus 16 bits of block counter is one 128-bit AES block. The session salt itself is produced from the master salt by SRTP's key derivation, which belongs with keying rather than with the profile. The salt is not a second secret key. RFC 3711 §9.2 says it **MUST be random but MAY be public**: its job is to defeat *time-memory tradeoff* attacks, in which an attacker who sees traffic under many keys amortises one precomputation across all of them, cutting the effective key size by log2 of the number of keys. A 112-bit salt, the RFC says, protects against scenarios with up to 2^112 keys in use. ## The integrity half: an 80-bit HMAC-SHA1 tag Encryption alone does not stop tampering: RFC 3711 §9.5 notes that AES counter mode and f8 provide no message authentication. The default profile therefore computes HMAC-SHA1 over the authenticated portion of the packet (the RTP header plus encrypted payload) concatenated with the rollover counter, and appends the first 80 bits. - The **session authentication key** is 160 bits, matching SHA-1's output, so an existing HMAC implementation plugs in unchanged (RFC 3711 §9.2). - The **tag** is 80 bits, 10 bytes per packet; RFC 3711 calls 80 bits acceptable for the applications it targets. - Effective strength is still bounded by the **128-bit master key**; RFC 3711 suggests a 192-bit master key for anyone uneasy about that, which RFC 6188's larger counter-mode suites later supplied. - For **SRTCP** the same profile authenticates every packet with the same 80-bit tag; RFC 3711 forbids weaker SRTCP authentication. ## One transform, several spellings | Where it is named | Spelling | |---|---| | SDP Security Descriptions (`a=crypto`, RFC 4568) | `AES_CM_128_HMAC_SHA1_80` | | DTLS-SRTP `use_srtp` extension (RFC 5764) | `SRTP_AES128_CM_HMAC_SHA1_80`, code point `{0x00,0x01}` | | RFC 3711 itself | the default transforms, AES-CM and HMAC-SHA1 | RFC 8827 makes `SRTP_AES128_CM_HMAC_SHA1_80` the profile every WebRTC implementation must support. ## What the default does not give you - **Headers stay in clear.** SSRC, sequence number, timestamp and payload type are readable (RFC 3711 §9.4); only the payload is encrypted. - **Lengths leak.** A stream cipher reveals the exact payload length (§9.3). - **The NULL cipher is also mandatory to implement.** It copies plaintext to ciphertext and is meant only where no confidentiality is requested; a profile such as `SRTP_NULL_HMAC_SHA1_80` keeps the HMAC tag and drops encryption, and WebRTC forbids negotiating it.

  • Does deriving a 160-bit HMAC key from the 128-bit master key give the profile 160-bit strength?
    No. RFC 3711 §9.2 says the effective key size is at most that of the master key, however long the derived session keys are. The 160-bit authentication key was chosen so standard HMAC implementations fit unchanged. Anyone who wants more margin is pointed to a larger master key, which RFC 6188's AES-192 and AES-256 counter-mode suites provide.
  • RFC 3711 makes both AES-CM and the NULL cipher mandatory to implement. Does that make the NULL cipher an acceptable choice?
    Implementing is not using: RFC 3711 §5 says mandatory-to-implement does not imply mandatory-to-use. The NULL cipher exists for sessions that need integrity but not confidentiality, which is why profiles such as `SRTP_NULL_HMAC_SHA1_80` keep the HMAC tag. RFC 8827 forbids NULL encryption in WebRTC, so on a browser call it is never acceptable.
  • If the salt may be public, why does SRTP bother with one at all?
    Because it changes every counter block without being secret. Without a per-session salt, an attacker watching many sessions could build one precomputed table and test it against all of them, cutting effective key strength by log2 of the number of keys. A random 112-bit salt makes each key's keystream space distinct, which defeats that amortisation (RFC 3711 §9.2).

saying these in an interview costs you the question

  • The 128 in the profile name is the length of the authentication tag.
  • AES counter mode alone stops an attacker from altering the media.
  • The SRTP salt must be kept as secret as the master key.
  • An 80-bit tag means HMAC-SHA1 runs with an 80-bit key.
  • SRTP encrypts the RTP header, so the SSRC and sequence number are hidden.
  • Mandatory to implement means the default profile must be the one negotiated.