SRT Encryption: AES-128 vs AES-256 for Secure Streaming

Why Encryption Matters for Live Streaming

Every live video stream that crosses the public internet can be intercepted. This is not theoretical. Packet capture tools like Wireshark can reconstruct an unencrypted video stream from captured network traffic in seconds. If your stream carries proprietary content, private corporate communications, paid live events, or sensitive news footage, unencrypted transport is a liability.

RTMP has no native encryption. The workaround is RTMPS, which wraps RTMP in TLS, but this adds certificate management complexity and does not address RTMP’s other limitations (TCP head-of-line blocking, no packet loss recovery, no real-time diagnostics).

SRT was designed with encryption built into the protocol from the beginning. It is not an afterthought or a wrapper. AES encryption is part of the SRT specification, implemented at the packet level, and available in every SRT implementation.

This article covers how SRT encryption works under the hood, the practical differences between AES-128 and AES-256, passphrase management best practices, and how to configure it all in a production environment.

How SRT Encryption Works

Understanding the mechanism helps you make informed decisions about security settings.

Key Derivation

SRT does not send your passphrase over the network. Instead, it uses PBKDF2 (Password-Based Key Derivation Function 2) to derive the actual encryption key:

1. The listener generates a random salt (unique per session)
2. The listener sends the salt to the caller during the SRT handshake (in the clear; this is safe, salts are not secrets)
3. Both sides independently compute: AES_Key = PBKDF2(passphrase, salt, iterations, key_length)
4. The derived key is used for AES encryption of all subsequent packets

This means:

• The passphrase never travels over the network
• Each session uses a different derived key (because the salt is random)
• An attacker who captures one session’s traffic cannot derive keys for other sessions (even with the same passphrase)

What Gets Encrypted

SRT encrypts the payload (your video/audio data) but not the SRT headers. This is by design:

• Encrypted: All MPEG-TS payload data (video, audio, metadata)
• Not encrypted: SRT packet headers (sequence numbers, timestamps, control information)

The headers must remain unencrypted because intermediate network equipment (routers, NAT devices) needs to route the packets, and SRT itself needs the headers to manage retransmission, timing, and flow control.

An attacker who captures encrypted SRT traffic can see:

• That SRT traffic is flowing between two IPs
• The packet rate and approximate bitrate (from packet sizes and timing)
• SRT protocol metadata (latency settings, connection parameters)

They cannot see:

• The video or audio content
• Embedded metadata or captions
• The passphrase or derived key

Key Renegotiation

SRT implements periodic key renegotiation (also called key rotation at the protocol level). The encryption key is refreshed automatically during long-running sessions:

1. After a configurable number of packets, the listener generates a new salt
2. A new key is derived from the same passphrase + new salt
3. Both sides switch to the new key simultaneously
4. This happens automatically, with no interruption to the stream

This provides a degree of forward secrecy. Even if an attacker somehow compromises one derived key, they only gain access to a portion of the stream, not the entire session history.

AES-128 vs AES-256: The Real Differences

SRT supports three AES key lengths: 128-bit, 192-bit, and 256-bit. AES-192 is rarely used in practice, so this comparison focuses on AES-128 and AES-256.

Security Strength

*Grover’s algorithm theoretically halves the effective key length on a quantum computer. AES-256 weakened to 128-bit effective strength is still unbreakable. AES-128 weakened to 64-bit is theoretically vulnerable, though practical quantum computers capable of this do not exist yet.

Bottom line: Both are unbreakable with current technology. AES-256 provides a larger margin against future threats, including quantum computing.

Performance Impact

This is where misconceptions abound. Many assume AES-256 is significantly slower than AES-128. In practice:

The reason the actual impact is so small: every modern x86 CPU since Intel Westmere (2010) and AMD Bulldozer (2011) includes AES-NI, dedicated hardware instructions for AES encryption and decryption. With AES-NI, encryption happens in silicon at wire speed. The difference between 10 and 14 rounds is measured in nanoseconds, not milliseconds.

Verification: Check if your CPU supports AES-NI:

# Linux
grep -o aes /proc/cpuinfo | head -1

# macOS
sysctl -a | grep -i aes

If the output includes aes, hardware acceleration is available.

Recommendation: Use AES-256 for everything. The performance difference is unmeasurable in a streaming context, and you get future-proof security. There is no practical reason to choose AES-128 in 2026.

When AES-128 Might Still Make Sense

The only scenario where AES-128 is a defensible choice: embedded devices with no AES-NI (very old ARM processors, some IoT encoders). On these devices, AES encryption happens in software, and the 40% additional computation for AES-256 may be relevant at high bitrates. Even then, modern ARM processors (ARMv8+) include AES hardware extensions.

Passphrase Management

The encryption is only as strong as your passphrase management. A perfect AES-256 implementation with a weak or compromised passphrase provides zero security.

Passphrase Requirements

SRT enforces these constraints:

• Minimum length: 10 characters
• Maximum length: 79 characters

Beyond the minimum, the passphrase strength depends on entropy. PBKDF2 derives the key using multiple iterations, which provides some protection against weak passphrases, but it is not a substitute for a strong passphrase.

Generating Strong Passphrases

Use a cryptographically secure random generator:

# Generate a 32-character random passphrase
openssl rand -base64 32
# Output: K7xPq2mN8vR3wY6tA1cF5hJ9dL0gS4bU+eI7oW=

# Generate a 44-character passphrase (more entropy)
openssl rand -base64 44
# Output: 8Fp3Kx7NqR2mWvY6tA1cF5hJ9dL0gS4bUeI7oWzXpQ3nM==

# Or use /dev/urandom directly
head -c 32 /dev/urandom | base64

Avoid:

• Dictionary words or phrases
• Passphrases shorter than 20 characters
• Reusing passphrases across streams
• Passphrases that include the stream name, date, or other guessable context

Passphrase Distribution

The passphrase must be shared between the SRT listener and caller. This is the most vulnerable point in the system. Secure distribution methods:

Good:

• Encrypted messaging (Signal, encrypted email)
• Password manager shared vaults (1Password, Bitwarden)
• Secure API call between automated systems (HTTPS with mutual TLS)
• In-person or phone (for one-time setup)

Bad:

• Unencrypted email
• Slack / Teams / Discord messages (stored in cloud, accessible to administrators)
• Shared documents (Google Docs, Notion, Confluence)
• Embedded in scripts committed to version control

For automated deployments, store passphrases in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets with encryption at rest) and inject them at runtime.

Passphrase Rotation

For long-running deployments, rotate passphrases periodically:

Recommended rotation schedule:

• Event-based streams: New passphrase per event
• Daily streams: Rotate weekly
• 24/7 streams: Rotate monthly
• After any team member departure: Rotate immediately

Rotation process with Vajra Cast:

1. Create a new SRT ingest with the new passphrase (Vajra Cast supports multiple ingests simultaneously)
2. Share the new passphrase with the remote encoder operator
3. The encoder switches to the new ingest
4. Verify the new connection is working
5. Disable or delete the old ingest

Because Vajra Cast supports hot management, creating and deleting ingests does not affect any other running streams. The rotation is transparent to other streams.

Configuring Encryption in Vajra Cast

Per-Ingest Encryption

Each SRT ingest in Vajra Cast has independent encryption settings:

1. Create or edit an SRT ingest
2. Enable Encryption
3. Select key length: AES-256 (recommended)
4. Enter your passphrase
5. Save

The corresponding SRT URL for encoders:

srt://your-server:9000?passphrase=YourSecurePassphrase&pbkeylen=32

Parameters:

• pbkeylen=16 for AES-128
• pbkeylen=24 for AES-192
• pbkeylen=32 for AES-256

Per-Output Encryption

SRT outputs can have their own encryption settings, independent of the ingest:

• Ingest encrypted, output unencrypted: Useful when the output is on a trusted network (e.g., same LAN)
• Ingest unencrypted, output encrypted: Useful when the ingest is local but the output crosses the internet
• Both encrypted with different passphrases: Maximum isolation between ingest and output operators

This flexibility means the encryption boundary is per-connection, not per-stream. You can encrypt exactly the network segments that need protection without encrypting trusted local connections.

Verifying Encryption Status

In the Vajra Cast dashboard, each active stream shows its encryption status:

• AES-256 SECURED: encryption active with AES-256
• AES-128 SECURED: encryption active with AES-128
• UNSECURED: no encryption

You can also verify via the REST API:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://your-server:8080/api/v1/ingests/1/stats

The response includes encryption state in the SRT statistics block.

Wireshark Verification

For absolute certainty, capture and inspect the traffic:

# Capture 10 seconds of SRT traffic
tcpdump -i eth0 -w capture.pcap udp port 9000 -c 1000

Open in Wireshark and examine the UDP payloads. With encryption enabled, the payload is random-looking binary data. Without encryption, you can identify MPEG-TS sync bytes (0x47) and potentially reconstruct the video.

Compliance Considerations

Depending on your industry, encryption may be a requirement rather than a best practice.

Broadcasting

• EBU (European Broadcasting Union) recommends encryption for all contribution feeds over public networks
• SMPTE ST 2022-7 (seamless protection switching) is complementary to SRT encryption for broadcast contribution

Corporate

• SOC 2 compliance typically requires encryption of data in transit
• ISO 27001 mandates protecting information during electronic transfer
• GDPR requires appropriate technical measures for personal data. If your stream contains identifiable individuals, encryption is effectively required

Government

• FedRAMP requires FIPS 140-2 validated encryption. AES-128 and AES-256 are both FIPS-approved algorithms. However, the SRT implementation must be using a FIPS-validated cryptographic library for full compliance.
• ITAR/EAR: encryption for controlled content may have specific requirements

Healthcare

• HIPAA requires encryption for Protected Health Information (PHI) in transit. Medical streaming (telemedicine, surgical broadcasts) must be encrypted.

Finance

• PCI DSS requires strong encryption for cardholder data in transit. Financial event broadcasts may contain material non-public information requiring protection.

In all cases, AES-256 meets or exceeds the encryption requirements. AES-128 also meets all current standards, but AES-256 provides the maximum margin.

Encryption and Performance: End-to-End Impact

Let’s quantify the total impact of enabling AES-256 encryption on a typical streaming workflow:

Scenario: 1080p30 H.264 at 6 Mbps

*SRT encryption does not increase the stream bitrate. The payload size remains the same because AES is a block cipher operating on fixed-size blocks. SRT headers (which are not encrypted) also remain the same size.

The total system impact of enabling AES-256 encryption is less than 1% CPU. On any hardware produced in the last decade, this is undetectable.

Common Encryption Issues

Silent Connection Failure

The most common encryption problem: the SRT connection simply does not establish, with no error message.

Cause: Passphrase or key length mismatch between caller and listener.

Debug steps:

1. Verify the exact passphrase on both sides (copy-paste, do not retype)
2. Verify pbkeylen matches on both sides (both must be 16, 24, or 32)
3. Check for trailing whitespace or newline characters in the passphrase
4. Temporarily disable encryption on both sides to confirm basic connectivity works

”Encryption not available” Error

Cause: The SRT library was compiled without encryption support.

Fix: Install the SRT library with encryption enabled. On Linux:

# Verify SRT was built with encryption
srt-live-transmit --version
# Should show "encryption: AES-CTR" or similar

If encryption is missing, reinstall SRT with OpenSSL support:

# Build SRT from source with encryption
git clone https://github.com/Haivision/srt.git
cd srt
mkdir build && cd build
cmake .. -DENABLE_ENCRYPTION=ON -DUSE_OPENSSL=ON
make
sudo make install

Performance Degradation on Old Hardware

Cause: CPU lacks AES-NI hardware acceleration.

Symptoms: CPU usage increases significantly (10-20%) when encryption is enabled, especially at high bitrates.

Fix: Upgrade hardware. Any Intel CPU from 2010+ or AMD CPU from 2011+ has AES-NI. If upgrading is not possible, use AES-128 to reduce the computational load by approximately 30% compared to AES-256.

Key Renegotiation Glitches

Symptoms: Brief audio/video glitch at regular intervals during long-running streams.

Cause: Rare timing issue during SRT key renegotiation.

Fix: Update to the latest SRT library version. This issue has been addressed in recent releases. In Vajra Cast, ensure you are running the latest version.

Best Practices Summary

1. Always encrypt streams that cross the public internet. There is no valid reason not to.
2. Use AES-256 for everything. The performance cost is negligible.
3. Generate passphrases with openssl rand -base64 32 or equivalent. Never use dictionary words.
4. Use unique passphrases per stream. A compromised passphrase should not expose other streams.
5. Distribute passphrases securely. Use encrypted messaging or secrets managers, never plaintext email.
6. Rotate passphrases periodically and after any team changes.
7. Verify encryption is active in your gateway dashboard. Do not assume.
8. Document your encryption policy: which streams are encrypted, which key length, rotation schedule.
9. Test passphrase rotation before you need to do it in production.
10. Keep SRT libraries updated for the latest security fixes and encryption improvements.

For the complete SRT setup walkthrough including encryption, latency, and monitoring, see our SRT Streaming Gateway guide. For step-by-step encryption configuration, read SRT Encryption Setup.