skip to content

A narrow VoIP trunk team proposes SRTP's AES_CM_128_HMAC_SHA1_32 to save bandwidth; what does the 32-bit tag save, what does it risk, and why does SRTCP keep 80 bits?

level: seniorimportance: should knowfreq 14%

answer

  1. six bytes per packet
  2. fifty packets a second
  3. forgery odds per packet
  4. stateful codecs amplify
  5. RTCP is rare and critical

basics

~20 s

The 32-bit tag saves 6 bytes per SRTP packet, 2.4 kbit/s on a 50-packet-per-second stream, but a forged packet passes with probability 2^-32 instead of 2^-80. RFC 3711 forbids weak SRTCP authentication, so RTCP keeps 80 bits.

solid answer

~50 s

`AES_CM_128_HMAC_SHA1_32` differs from the default only in the SRTP tag: 4 bytes instead of 10. For G.729 at 20 ms (20-byte payload, 40 bytes of IPv4, UDP and RTP header, 50 packets per second) that is 64 versus 70 bytes per packet, 25.6 versus 28.0 kbit/s per direction at the IP layer. Confidentiality is unchanged. The cost is forgery resistance: each forged packet succeeds with probability 2^-32. RFC 3711 §7.5 argues that for a 20 ms voice codec this lets an attacker control at most 20 ms of audio over about 994 days on average, but warns that a codec carrying state across packets spreads one forgery further. RFC 3711 §5.2 calls shorter SRTP tags NOT RECOMMENDED but permissible after careful consideration, and forbids them for SRTCP: RTCP is a small share of traffic and carries session control, so the profile keeps its 80-bit tag.

go deeper

for a junior

Recall that the 32-bit profile only shortens the integrity tag on media packets, from 10 bytes to 4, and leaves encryption untouched.

for a middle

Compute the per-packet and per-stream saving from payload size and packet rate, and explain what tag length means for forgery odds.

for a senior

Judge the trunk case honestly: the codec's statefulness, the real share of the tag in the packet, and why RTCP keeps 80 bits under RFC 3711.

for a principal

Decide whether a few kilobits per call justify a weaker integrity guarantee across the estate, and where that exception is written down and reviewed.

## What the 32-bit profile changes, and what it leaves alone `AES_CM_128_HMAC_SHA1_32` (DTLS-SRTP `SRTP_AES128_CM_HMAC_SHA1_32`, `{0x00,0x02}`) is identical to the default `AES_CM_128_HMAC_SHA1_80` except for one number: the **SRTP authentication tag is 32 bits** instead of 80. The cipher, the 128-bit master key, the 112-bit salt and the 160-bit HMAC-SHA1 key are all unchanged, so **confidentiality is exactly the same**. Only integrity on media packets is weakened, and only on media packets: RFC 4568's table and RFC 5764 both give the SRTCP tag as **80 bits** for this profile. ## The bandwidth arithmetic Take a trunk carrying voice in 20 ms packets, 50 packets per second per direction, over IPv4 with 40 bytes of IP, UDP and RTP header and no MKI: | Codec payload | Plain RTP | `_80` (+10 B) | `_32` (+4 B) | `AEAD_AES_128_GCM` (+16 B) | |---|---|---|---|---| | G.729, 20 bytes | 60 B, 24.0 kbit/s | 70 B, 28.0 kbit/s | 64 B, 25.6 kbit/s | 76 B, 30.4 kbit/s | | G.711, 160 bytes | 200 B, 80.0 kbit/s | 210 B, 84.0 kbit/s | 204 B, 81.6 kbit/s | 216 B, 86.4 kbit/s | Each rate is bytes x 8 x 50. The saving of `_32` over `_80` is **6 bytes x 8 x 50 = 2.4 kbit/s per stream per direction**, or 2.4 Mbit/s per direction for 1,000 concurrent calls. On a small-payload codec that is real: the 10-byte tag is half the size of the G.729 payload. On G.711 the 6-byte saving is about 3% of the packet. Link-layer framing adds more on top, and the proportions shift the same way. ## What a short tag hands an attacker A tag of *n* bits means a forged packet, built without the key, passes verification with probability about 2^-n. RFC 3711 §7.5 works the voice case: 1. A G.729 stream with 20 ms packets and a 32-bit tag gives each forgery attempt a 1 in 2^32 chance. 2. At 50 packets per second, 2^32 packets take about 85.9 million seconds, roughly **994 days**. 3. So an attacker controls, on average, **no more than 20 ms of audio in a 994-day period**. The same section adds the caveat that decides most real cases: if the codec is **stateful** (relative or predictive compression across packets), one accepted forgery corrupts the decoder state and affects far more than 20 ms of output. The argument holds for a restricted set of applications, not for media in general. RFC 3711 also names the environments the short tag was meant for: - links where **bandwidth is scarce and expensive**, such as wireless voice with compressed headers, where a full tag would add nearly fifty percent overhead; - links with **fixed-width fields** that cannot absorb a tag at all. ## Why SRTCP keeps 80 bits RFC 3711 §5.2 says the pre-defined HMAC-SHA1 **MUST NOT** be used for SRTCP with a tag or key shorter than the defaults, and §9.5 that SRTCP must not use weak or NULL authentication. Two reasons make that cheap and necessary: - **RTCP is rare.** RFC 3550 recommends fixing RTCP bandwidth at 5% of the session, so 6 extra bytes on RTCP packets cost little. - **RTCP carries session control.** Reports, source descriptions and BYE packets steer the session; a forged one can mislead rate adaptation or end a stream, which is worse than 20 ms of noise. Each SRTCP packet also carries a 4-byte field of encryption flag and index, so under either HMAC profile SRTCP adds 14 bytes. ## Expressing the choice in signalling The profile is only chosen if the offer says so. With SDES, the answerer takes the first offered line it supports, so a trunk that lists `AES_CM_128_HMAC_SHA1_80` before `AES_CM_128_HMAC_SHA1_32` will normally end up on the 80-bit tag whenever the peer supports both; to get the short tag you must list it first or offer it alone. With DTLS-SRTP, the client lists `SRTP_AES128_CM_HMAC_SHA1_32` and `SRTP_AES128_CM_HMAC_SHA1_80` in its preferred order, but the server makes the final pick. ## How to decide on the trunk - Prefer the 80-bit profile unless the bandwidth number above actually matters on that link. - Check the codec: a stateful or predictive codec weakens RFC 3711's 994-day argument. - Do not look to GCM for a short tag: RFC 7714 forbids truncating the 16-octet AEAD tag. - Make the choice explicit in the offer rather than inheriting whatever an endpoint proposes first.

  • Why does a 32-bit tag hurt more when the codec predicts each frame from the previous ones?
    RFC 3711 §7.5's 994-day figure assumes one forged packet costs only its own 20 ms. A codec using relative or predictive compression carries state across packets, so a single accepted forgery corrupts that state and distorts later output too. The forgery odds are the same; the damage per success is larger.
  • Could the trunk use an AES-GCM profile with a truncated tag to save the same bytes?
    No. RFC 7714 requires the AEAD tag to be a full 16 octets and forbids truncation in SRTP and SRTCP, judging truncated GCM tags too risky. GCM therefore costs 16 bytes per packet, 6 more than the 80-bit HMAC profile, so it moves the trunk in the opposite direction.

saying these in an interview costs you the question

  • A 32-bit tag also weakens encryption of the voice payload.
  • Under the 32-bit profile, SRTCP packets also carry a 32-bit tag.
  • One-in-2^32 odds mean a short tag is always safe for any media.
  • The AES-GCM profiles allow an 8-byte tag for narrow links.
  • Switching to the 32-bit tag roughly halves the per-call bandwidth.