How to Set Up SRT Encryption (AES-128/256)

Step-by-step guide to configuring SRT encryption with AES-128 or AES-256 for secure live video transport.

Why Encrypt Your SRT Streams?

Any video stream traversing the public internet is vulnerable to interception. SRT’s built-in AES encryption ensures that even if someone captures your packets, they can’t decode the content.

Unlike RTMP (which requires a separate TLS wrapper), SRT encryption is native to the protocol. It is always available, zero additional infrastructure required.

Choosing Your Key Length

SRT supports three AES key lengths:

Key LengthSecurity LevelPerformance ImpactRecommendation
AES-128StrongMinimal (<1% CPU)General use
AES-192StrongerMinimalRarely used
AES-256MaximumMinimal (~1-2% CPU)Sensitive content

Our recommendation: Use AES-256 for everything. The performance difference is negligible on modern hardware, and you get maximum security.

Configuration

The Passphrase

SRT encryption requires a shared passphrase between caller and listener:

  • Minimum length: 10 characters
  • Maximum length: 79 characters
  • Both sides must match: mismatched passphrases cause silent connection failure

Good passphrase practices:

  • Use 20+ characters
  • Mix uppercase, lowercase, numbers, and symbols
  • Never reuse across streams
  • Generate with a password manager or openssl rand -base64 32

SRT URL Parameters

srt://server:9000?passphrase=MySecurePass2026!&pbkeylen=32
  • passphrase: your shared secret
  • pbkeylen: key length in bytes: 16 (AES-128), 24 (AES-192), or 32 (AES-256)

Vajra Cast Configuration

In Vajra Cast, encryption is configured per ingest:

  1. Open the ingest settings
  2. Enable “Encryption”
  3. Enter your passphrase
  4. Select AES-256 (recommended)
  5. Share the passphrase with your remote encoder operator

The output side doesn’t need separate encryption configuration. It inherits from the ingest or can be configured independently for each output.

How SRT Encryption Works

Under the hood, SRT uses PBKDF2 (Password-Based Key Derivation Function 2) to derive the actual AES key from your passphrase:

  1. Listener generates a random salt
  2. Both sides derive the AES key from passphrase + salt using PBKDF2
  3. All payload data is encrypted with the derived key
  4. SRT headers remain unencrypted (necessary for packet routing)
  5. Keys are periodically renegotiated for forward secrecy

This means:

  • The passphrase never travels over the network
  • Each session uses a unique derived key
  • Compromising one session doesn’t compromise past or future sessions

Verifying Encryption

How to confirm your stream is actually encrypted:

  1. Check SRT statistics: Vajra Cast shows encryption status per stream
  2. Packet inspection: capture with Wireshark; payload should be unreadable
  3. Mismatch test: try connecting with wrong passphrase; it should fail silently (no error, just no connection)

Troubleshooting

Connection fails silently

Most common cause: passphrase mismatch. SRT doesn’t report an error. It simply refuses to connect. Double-check:

  • Exact passphrase on both sides (watch for trailing spaces)
  • Same pbkeylen on both sides
  • No typos (copy-paste is safer)

Performance concerns

AES encryption on modern CPUs uses hardware acceleration (AES-NI). Unless you’re running on very old hardware, encryption has negligible performance impact. If you see issues, check that AES-NI is enabled in your BIOS.

Key rotation

For long-running streams, consider rotating passphrases periodically:

  1. Set up a new ingest with the new passphrase
  2. Switch the encoder to the new ingest
  3. Remove the old ingest

Vajra Cast supports hot management. You can create and modify ingests without interrupting running streams.

Next Steps

← Back to main guide