Post-quantum encryption for military video and audio streams

A drone operator flies a reconnaissance mission over contested terrain. The H.264 video stream travels over a satellite link, encrypted with DTLS/SRTP using an ECDHE key exchange. On the ground, an adversary intercepts and stores the ciphertext — not to decrypt it today, but to decrypt it in 2032, when a cryptographically relevant quantum computer is available. By then, the footage reveals sensor coverage gaps, targeting geometry, and the patrol patterns of friendly forces. The intelligence value of that stored video is undiminished by the years it spent encrypted.

This is the harvest-now-decrypt-later (HNDL) problem applied to real-time military video. It is not a hypothetical. Adversaries who understand the quantum timeline are already collecting and archiving encrypted ISR feeds, drone video, and command voice traffic. The appropriate response is not to wait for quantum computers to arrive before migrating to post-quantum cryptography — the window for protecting data in transit is now, before collection occurs.

Why drone and ISR video is the highest-value HNDL target

Communications intelligence (COMINT) has obvious HNDL value, but ISR video carries a different class of information. A single mission's worth of unencrypted drone footage can reveal: the exact fields of view of sensors (and therefore blind spots), the precise timing and geometry of targeting decisions, the location and movement of friendly forces visible in the frame, and the operational patterns that define unit behavior over time. Unlike a single encrypted message, video encodes persistent contextual information — spatial, temporal, and behavioral — that rewards long-term collection and analysis.

The retention lifetime of ISR video compounds this risk. Many defence programs archive raw drone footage for years — for after-action review, for legal compliance, for intelligence exploitation. An adversary who collects encrypted ISR video in 2026 and decrypts it in 2032 is not reading stale data; they are reading a structured historical record of friendly force operations. The sensitivity of that record does not diminish with time.

Quantifying the collection surface: a single MALE drone on a 20-hour mission at standard ISR bitrates (4–8 Mbps H.264) produces 36–72 GB of compressed video per sortie. A fleet operating over a contested region generates terabytes per day. This is an extremely attractive collection target for an adversary willing to invest in long-term storage and future decryption capability.

Current state: DTLS/SRTP and TLS are classically secure but quantum-vulnerable

Most military drone video pipelines use one of two transport security models. The first is DTLS/SRTP: the WebRTC-derived model where DTLS 1.3 negotiates session keys over UDP, and SRTP uses those keys to encrypt each RTP packet. The second is a TLS-secured key distribution server (KDS): a centralized service that issues SRTP master keys to both sender and receiver over a TLS-protected API, with SRTP handling packet-level encryption. Both models ultimately depend on a classical Diffie-Hellman or Elliptic Curve Diffie-Hellman key exchange for the session key negotiation phase.

ECDHE with X25519 (the current best-practice for DTLS/TLS key exchange) provides strong classical security. Against a quantum adversary running Shor's algorithm, it provides no security. This is not a weakness in the algorithm implementation — it is a fundamental property of the underlying mathematical problem (discrete logarithm on an elliptic curve) that Shor's algorithm solves in polynomial time. Replacing X25519 with a larger curve (P-521, for example) does not help; Shor's algorithm scales efficiently across all elliptic-curve parameter sizes.

AES-256 symmetric encryption (used for the actual SRTP packet payload) is not similarly broken by quantum computers. Grover's algorithm reduces AES-256's effective security to 128 bits against a quantum adversary — still computationally infeasible to brute-force. The urgency is in the key exchange, not the bulk cipher.

ML-KEM for video key exchange: integrating post-quantum KEMs with SRTP

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardized as FIPS 203 by NIST and based on the CRYSTALS-Kyber algorithm, is the post-quantum drop-in for the key exchange phase of DTLS and TLS. A KEM works differently from Diffie-Hellman: the receiver generates a public/private key pair and publishes the public key; the sender encapsulates a random shared secret using the public key; the receiver decapsulates to recover the same shared secret. Neither party transmits the shared secret in plaintext, and an adversary who intercepts the ciphertext cannot recover the shared secret without the receiver's private key — a problem believed to be hard even for quantum computers.

Integration with SRTP is straightforward at the API level. The DTLS handshake (or KDS API call) produces a shared secret as before; the only change is that the shared secret is now derived from an ML-KEM encapsulation rather than an ECDHE exchange. The shared secret is fed into HKDF-SHA-384 to derive the SRTP master key and salt, following the same key derivation path as the classical protocol. The SRTP packet format, sequence number handling, authentication tag computation, and AES-256-GCM bulk encryption are unchanged. From the perspective of the RTP stack, nothing has changed except the provenance of the master key.

Parameter set selection: ML-KEM-768 vs ML-KEM-1024

Three ML-KEM parameter sets are defined: ML-KEM-512 (security level equivalent to AES-128), ML-KEM-768 (AES-192), and ML-KEM-1024 (AES-256). For ISR applications, the choice is between ML-KEM-768 and ML-KEM-1024. NSA's CNSA 2.0 mandate specifies ML-KEM-1024 for National Security Systems. ML-KEM-1024 produces a 1,568-byte public key and a 1,568-byte ciphertext — both larger than X25519's 32-byte key shares, but easily accommodated within the DTLS handshake or an HTTPS API response. The performance cost relative to ML-KEM-768 is marginal; for a decision that will govern data security for a decade, ML-KEM-1024 is the correct choice for classified ISR applications.

Latency budget: PQC overhead in real-time streaming

The most common objection to PQC in real-time video pipelines is latency. The concern is understandable but misplaced when the actual numbers are examined.

ML-KEM-1024 key generation on a modern x86-64 processor (AVX2-optimized implementation, e.g., liboqs or BoringSSL's built-in) takes approximately 0.3–0.5 ms. Encapsulation and decapsulation each take under 0.5 ms. The total round-trip overhead for a PQC key exchange is therefore under 2 ms, inclusive of network round-trip time on a low-latency LAN. For video streams already carrying 100–300 ms of codec pipeline and network delay (typical for tactical satellite links), this overhead is unmeasurable in practice.

The key exchange is a one-time operation per session, not a per-packet operation. A drone video session that runs for 20 hours performs one ML-KEM encapsulation at the start (and a small number of periodic re-keys). The per-packet cost is zero — SRTP packet encryption remains AES-256-GCM at hardware acceleration speeds (multiple Gbps on modern processors). Post-quantum video streaming is not a performance problem. It is an integration problem.

Hybrid mode deployment: ECDHE + ML-KEM in parallel

During the transition period — when some endpoints support ML-KEM and others do not — hybrid cipher suites are the standard-endorsed approach. In hybrid mode, the DTLS or TLS handshake includes both an ECDHE key share (X25519) and an ML-KEM key encapsulation (ML-KEM-1024). The session key is derived from both via HKDF, with the formula: session_key = HKDF(X25519_shared_secret || ML-KEM_shared_secret, "hybrid-srtp-key"). Both secrets must be successfully derived for the session to proceed.

This construction provides what cryptographers call "dual security": the session is quantum-safe if ML-KEM is secure, and classically secure if X25519 is secure. An adversary must break both to recover the session key. NSA endorses hybrid mode for the transition period in its CNSA 2.0 guidance; it does not reduce classical security in any way.

The practical benefit for ISR systems is that hybrid mode can be deployed fleet-wide before all ground stations are upgraded. Upgraded ground stations negotiate the hybrid cipher suite; legacy ground stations fall back to ECDHE-only. The high-value streams — those connecting post-quantum capable C2 nodes — gain quantum protection immediately, while backwards compatibility is maintained. See our broader discussion of the CNSA 2.0 migration approach for defense systems for the full algorithm inventory and transition timeline.

Apache Kafka as the streaming backbone for ISR distribution

Point-to-point SRTP works for single drone-to-C2 links, but operational ISR distribution is a fan-out problem. A single drone feed must be consumed simultaneously by: the primary C2 workstation, the targeting cell, the intelligence exploitation team, the recording node archiving the mission, and possibly higher-echelon commands monitoring the operation. Managing N simultaneous SRTP sessions from the encoder to each consumer is operationally fragile and cryptographically messy — each session has independent key material, and managing key distribution and rotation across N peers at once creates failure modes.

Apache Kafka solves this architectural problem. Each ISR source publishes to a dedicated Kafka topic (e.g., isr.drone.alpha-01.video, isr.sensor.ground.bravo). Consumer groups — one per role (c2-display, targeting, exploitation, archive) — subscribe independently and maintain their own offsets. Adding a new consumer does not require re-negotiating with the producer; it simply subscribes to the existing topic. Replay for late-joining consumers (a targeting analyst who comes online mid-mission) is a built-in Kafka capability, not a bespoke feature.

The post-quantum security model maps cleanly onto this architecture. Each producer authenticates to the Kafka broker over mutual TLS with hybrid ML-KEM cipher suites, establishing a quantum-safe channel for the stream. Each consumer similarly connects to the broker over TLS with hybrid ML-KEM. The broker holds the encrypted topic data on disk under AES-256 at-rest encryption. The key hierarchy — ML-KEM session key protecting the TLS connection that carries SRTP-encrypted video frames stored in AES-256-encrypted Kafka log segments — provides defense-in-depth at every layer.

Topic partitioning and consumer group design

For multi-sensor ISR deployments, partitioning within a topic provides scalability. A high-bandwidth sensor (full-motion video at 8 Mbps) benefits from a single partition per source to preserve frame ordering. Multiple lower-bandwidth sensors (telemetry, audio, narrow-field imagery) can share a topic with partitioning by sensor identifier. Consumer groups should be scoped to operational roles rather than individual workstations — this allows workstation failover within a role without losing offset continuity. Each consumer group maintains independent decryption state; key rotation on one group does not affect others.

Corvus.Quantum: post-quantum streaming for operational defense

Corvus.Quantum is the Corvus Intelligence platform for quantum-safe audio and video distribution in defense environments. It implements the architecture described in this article — ML-KEM-1024 key exchange in hybrid mode, SRTP packet encryption, Apache Kafka fan-out for multi-echelon distribution — as a hardened, operationally tested system rather than a research prototype.

The platform has been deployed in active conflict conditions in Ukraine, where it manages real-time ISR video distribution for command posts operating under electronic warfare pressure. The design priorities shaped by that environment — sub-200 ms glass-to-glass latency despite contested links, graceful degradation when consumers disconnect mid-stream, automatic key rotation without stream interruption, and air-gap capable deployment for classified networks — are production-validated, not simulated in a lab.

Corvus.Quantum integrates with existing ATAK-based C2 infrastructure through a plugin interface, allowing ISR video to flow into the common operational picture alongside cursor-on-target data. The Kafka backbone supports both cloud-hosted and air-gapped on-premise deployments. Post-quantum key exchange is enabled by default; classical-only fallback is available for legacy endpoints during hybrid transition periods. For organizations facing zero-trust network requirements for military environments, Corvus.Quantum's mutual TLS authentication for every producer and consumer satisfies device identity verification at the streaming layer without additional middleware.

The procurement path for Corvus.Quantum is available through the Brave1 defense technology marketplace and direct contract with Corvus Intelligence. Technical integration documentation is available under NDA for qualified defense organizations and prime contractors.