net/srtp: encrypt RTP header extensions (RFC 6904)

[haaspors]

Implements RFC 6904 encryption of RTP header extensions in the SRTP layer, the first of the SRTP feature gaps split out of #221.

What

Encrypts the bodies of the RFC 8285 header-extension elements whose IDs are marked for encryption, while leaving the 4-byte extension header, each element's ID/length bytes, padding, and the bodies of unmarked elements in the clear. The extension therefore stays parseable on the wire, and the SRTP auth tag covers the encrypted form.

• The keystream is derived per stream with the header-extension key/salt KDF labels (0x06 / 0x07), distinct from the payload keys, and applied with the packet's own SRTP IV (same SSRC and packet index). Distinct keys mean the header-extension keystream can never coincide with the payload keystream for a packet.
• On send the extension is encrypted before the auth tag is computed; on receive it is decrypted only after the tag verifies, so the tag always covers the ciphertext and there is no decryption oracle.
• New API r_srtp_set_encrypted_header_extension (ctx, id, encrypted) registers which extension IDs are encrypted. The extra keys are derived when a stream is first used, so IDs must be registered during setup, before packets flow.
• Both the one-byte (0xBEDE) and two-byte (0x100x) RFC 8285 forms are handled; other profiles are authenticated but not encrypted.

Testing

• encrypt_hdr_ext_rfc6904 asserts the produced ciphertext equals the RFC 6904 Appendix A.2 worked example byte-for-byte (SSRC CAFEBABE, seq 0x1234, ROC 0, IDs 1/3/4 encrypted). This validates the key derivation, IV, AES-CM keystream and the per-element mask end to end against the spec.
• One-byte and two-byte round-trips, a tamper test proving the auth tag covers the encrypted extension, the invalid-argument contract, and the "register after the stream exists is a no-op" caveat.
• Existing SRTP packets that carry a header extension keep round-tripping in the clear, since no IDs are registered by default.
• Full suite green on the linux and ASan tiers; both tiers compile warning-free.

Security review

Audited for memory safety and cryptographic correctness. The element parse loop is bounds-checked against attacker-controlled length fields on the decrypt path, the encrypt-then-authenticate / verify-then-decrypt ordering holds on all paths including error returns, and the replay window is neither bypassed nor advanced on a failed packet. Derived key and salt scratch is cleared at teardown.

Scope

Header-extension encryption only. MKI and EKT remain tracked separately.

Closes #443

🤖 Generated with Claude Code