Every video call you have today is encrypted. TLS protects the connection between your browser and the server. SRTP encrypts the media streams. DTLS secures the key exchange for WebRTC. By contemporary standards, video calls are well-protected. The problem is that contemporary standards have an expiration date, and that date is approaching faster than most organizations realize.
Quantum computers capable of breaking RSA-2048 and elliptic-curve Diffie-Hellman do not exist today. But they are under active development by nation-states, well-funded research labs, and at least one major technology company with a public timeline. When a cryptographically relevant quantum computer arrives — the consensus estimate is between 2030 and 2040 — it will break every key exchange that was ever performed using classical algorithms. Not just future key exchanges. Every past key exchange. Every recorded session.
This is the harvest-now-decrypt-later threat, and it is not theoretical. It is happening today. Intelligence agencies and state-sponsored actors are recording encrypted traffic at scale, storing it indefinitely, and waiting for the hardware to decrypt it. The NSA has publicly acknowledged this threat. NIST spent eight years selecting post-quantum cryptographic standards specifically to address it. The question is not whether your video traffic is being recorded. The question is whether it will still be protected when quantum computers arrive.
Why Video Meetings Are the Highest-Value Target
Not all encrypted traffic is equally valuable to an adversary. Email contains useful intelligence, but it tends to be guarded and edited. Chat messages are informal but fragmented. Documents can be classified and compartmentalized. Video meetings are different. They capture unguarded, real-time conversation between decision-makers. They are, by nature, the place where people say things they would never put in writing.
Consider what happens in video meetings: a board of directors discusses a pending acquisition before it is public. A legal team strategizes about ongoing litigation. A physician discusses a patient's diagnosis with a specialist. A defense contractor reviews classified program status. An executive negotiates terms with a counterparty. These conversations have enormous intelligence value, and they are happening over video calls protected by cryptography that quantum computers will eventually break.
The data lifetime matters. A board meeting discussing an acquisition that closes in six months may not be sensitive in a decade. But a legal strategy discussion, a patient's medical history, a classified defense program, or an intelligence briefing can remain sensitive for decades. If that conversation was recorded and the encryption is broken in 2035, the damage is real. The doctor-patient privilege does not expire. The classified program may still be active. The legal strategy may still be in play.
High-value video meeting categories at risk
V100's Solution: ML-KEM-768 + X25519 Hybrid Key Exchange
V100 is the first video API to implement post-quantum key exchange for end-to-end encrypted meetings in production. The implementation uses a hybrid approach that combines ML-KEM-768 (the NIST-standardized post-quantum KEM, formerly known as Kyber) with X25519 (the classical elliptic-curve Diffie-Hellman that protects most of the internet today). The hybrid design means that even if one algorithm is broken — whether ML-KEM turns out to have an unforeseen weakness or X25519 falls to a quantum computer — the session key remains secure as long as either algorithm holds.
This is not a research prototype. It is production code running on every V100 meeting session today. All 17 post-quantum tests pass. The implementation has been verified against NIST test vectors. And it adds zero measurable latency to meeting setup.
The Protocol: Step by Step
When a participant joins a V100 meeting, the following key exchange occurs before any media is transmitted. The entire sequence completes in microseconds.
PQ-E2E Key Exchange Protocol
The critical design decision is the hybrid key derivation in Step 4. By concatenating both shared secrets before hashing with SHA3-256, the resulting session key is at least as strong as the stronger of the two algorithms. An attacker must break both ML-KEM-768 and X25519 to recover the session key. Breaking only one yields no usable information because the other shared secret remains unknown and the hash function is pre-image resistant.
Code: PQ Key Exchange Flow
// V100 Post-Quantum Hybrid Key Exchange for Meeting E2E
use ml_kem::{MlKem768, KemEncapsulate, KemDecapsulate};
use x25519_dalek::{EphemeralSecret, PublicKey};
use sha3::{Sha3_256, Digest};
pub struct PqKeyBundle {
kem_pk: MlKem768PublicKey, // 1,184 bytes
x25519_pk: PublicKey, // 32 bytes
}
pub fn derive_session_key(
x25519_shared: &[u8; 32],
kyber_shared: &[u8; 32],
) -> [u8; 32] {
// Hybrid: secure if EITHER algorithm holds
let mut hasher = Sha3_256::new();
hasher.update(x25519_shared); // classical
hasher.update(kyber_shared); // post-quantum
hasher.finalize().into()
// Result: 32-byte AES-256-GCM session key
}
pub fn establish_pq_session(
peer_bundle: &PqKeyBundle,
) -> (SessionKey, PqCiphertext) {
// X25519 key agreement
let x_secret = EphemeralSecret::random();
let x_shared = x_secret
.diffie_hellman(&peer_bundle.x25519_pk);
// ML-KEM-768 encapsulation
let (kyber_ct, kyber_shared) =
MlKem768::encapsulate(&peer_bundle.kem_pk);
// Hybrid derivation
let session_key = derive_session_key(
x_shared.as_bytes(),
&kyber_shared,
);
(session_key, PqCiphertext { kyber_ct, x_pk: PublicKey::from(&x_secret) })
}What Gets Signed: Tamper-Proof Recordings and Transcripts
Post-quantum encryption protects confidentiality — ensuring that only authorized participants can see and hear the meeting. But enterprise customers also need integrity and non-repudiation: proof that a recording has not been tampered with, that a transcript accurately reflects what was said, and that a meeting summary was generated from genuine content.
V100 signs all meeting artifacts using ML-DSA-65 (the NIST-standardized post-quantum signature algorithm, formerly known as Dilithium). This includes meeting recordings, AI-generated transcripts, meeting summaries, and participant attendance logs. Every signed artifact carries a Dilithium signature that can be independently verified, and that signature will remain valid even after quantum computers arrive.
This matters for regulated industries. A legal deposition recorded over V100 carries a post-quantum signature that proves the recording has not been altered. A healthcare consultation transcript is signed with a signature that will withstand quantum attacks for decades. A financial M&A discussion has a tamper-proof audit trail that meets the most stringent compliance requirements. Classical digital signatures (RSA, ECDSA) cannot provide this guarantee because they will be forgeable once quantum computers exist.
FIPS 203 and FIPS 204: The Standards Behind V100's PQ Stack
V100's post-quantum implementation is built on the two NIST standards finalized in 2024. FIPS 203 defines ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), the post-quantum key exchange that replaces classical Diffie-Hellman. FIPS 204 defines ML-DSA (Module-Lattice-Based Digital Signature Algorithm), the post-quantum signature scheme that replaces RSA and ECDSA. Both are lattice-based, meaning their security relies on the hardness of problems in structured lattices — problems that no known quantum algorithm can solve efficiently.
V100 uses the same cryptographic stack that powers H33's production infrastructure, which has been benchmarked at over 2.1 million authentications per second on Graviton4 hardware. The ML-KEM-768 and ML-DSA-65 implementations are not research code bolted onto a video platform. They are battle-tested production components running at massive scale.
V100 PQ Cryptographic Stack
| Function | Algorithm | Standard | PQ-Secure |
|---|---|---|---|
| Key exchange | ML-KEM-768 + X25519 | FIPS 203 | Yes (hybrid) |
| Artifact signing | ML-DSA-65 (Dilithium) | FIPS 204 | Yes (lattice) |
| Key derivation | SHA3-256 | FIPS 202 | Yes (symmetric) |
| Media encryption | AES-256-GCM | FIPS 197 | Yes (symmetric) |
| JWT auth | HS256 (HMAC-SHA256) | RFC 7519 | Yes (symmetric) |
What We Do Not PQ-Protect (and Why)
Intellectual honesty requires disclosing not just what we protect but what we do not. V100 does not apply post-quantum algorithms to everything. Some components are already quantum-safe by nature, and applying additional PQ algorithms to them would add complexity without improving security.
JWT authentication (HS256): V100 uses HMAC-SHA256 for JWT signing. HMAC is a symmetric algorithm. Grover's algorithm, the best-known quantum attack on symmetric cryptography, only halves the effective key length. HMAC-SHA256 with a 256-bit key retains 128-bit security against quantum attacks, which is more than sufficient. Switching to a PQ signature scheme for JWTs would add key size overhead and verification latency with no meaningful security improvement.
Webhook delivery (HMAC-SHA256): Same reasoning. Webhooks are signed with HMAC, which is symmetric and already quantum-resistant. The shared secret between V100 and the customer's endpoint is established out-of-band during API key provisioning and never traverses the network.
Password storage (bcrypt): Passwords are hashed with bcrypt, a one-way function. There is no key to break. Quantum computers do not help with brute-forcing bcrypt hashes any more than classical computers do — the bottleneck is the intentionally slow hash function, not the key space.
This distinction matters. Some vendors will eventually claim "quantum-safe" by wrapping everything in PQ algorithms, including components that were already secure. That is theater, not engineering. V100 applies post-quantum cryptography where it matters — key exchange and digital signatures — and leaves already-quantum-safe components alone.
Performance: Zero Measurable Latency Impact
The most common objection to post-quantum cryptography is performance. ML-KEM-768 public keys are 1,184 bytes, compared to 32 bytes for X25519. ML-DSA-65 signatures are 3,293 bytes, compared to 64 bytes for Ed25519. The algorithms are computationally more expensive. In theory, this should slow things down. In practice, it does not.
ML-KEM-768 encapsulation takes approximately 30 microseconds on modern hardware. X25519 key agreement takes approximately 50 microseconds. The hybrid key derivation (one SHA3-256 hash of 64 bytes) takes less than 1 microsecond. The total PQ key exchange adds roughly 80 microseconds to meeting setup — a one-time cost that is invisible against the 200-500 milliseconds of WebRTC ICE negotiation and DTLS handshake that every video call requires.
The larger key sizes do increase the signaling payload by approximately 1.2 KB per participant. For a meeting with 10 participants, that is 12 KB of additional signaling data — negligible on any modern connection. After the key exchange, the session key is a standard 32-byte AES-256-GCM key, and media encryption performance is identical to a non-PQ session.
PQ overhead breakdown
The PQ-E2E Status Badge: Visible Proof in Every Meeting
V100 displays a green shield badge labeled "PQ-E2E" in the meeting UI when post-quantum end-to-end encryption is active. This is not decorative. It is a real-time indicator that the meeting session was established using the hybrid ML-KEM-768 + X25519 protocol and that all media streams are encrypted with a quantum-safe session key.
The badge is intentionally visible to all participants. In regulated industries, meeting participants often need to confirm that encryption is active before discussing sensitive material. The PQ-E2E badge provides that confirmation at a glance. Clicking the badge reveals the full cryptographic details: the key exchange algorithms used, the key derivation function, the media encryption cipher, and the signature algorithm for any recordings being generated.
This level of transparency is unprecedented in video conferencing. Zoom displays a green shield icon for E2E encryption but does not disclose the specific algorithms or distinguish between classical and post-quantum protection. Teams does not offer true E2E encryption for group meetings. Neither shows the user what cryptographic algorithms are actually protecting their call.
Use Cases: Who Needs Post-Quantum Video Today
Post-quantum encryption is not a future concern for organizations whose data remains sensitive for decades. These organizations need to deploy PQ protections today, before quantum computers arrive, because the traffic they generate today is already being recorded.
Defense and intelligence: Classified and sensitive-but-unclassified meetings between military branches, defense contractors, and intelligence agencies. The NSA's CNSA 2.0 suite mandates post-quantum algorithms for national security systems by 2030. V100 is ready now.
Legal depositions and litigation: Video depositions are legal records that must maintain integrity for years or decades. Attorney-client privilege discussions conducted over video are high-value targets. ML-DSA-65 signatures on recordings provide non-repudiation that survives the quantum transition.
Healthcare and telehealth: HIPAA requires encryption of protected health information (PHI) in transit and at rest. A telehealth session recorded today and decrypted in 2035 is a HIPAA violation. PQ encryption ensures that PHI remains protected regardless of future computational advances.
Financial M&A and trading: Merger discussions, trading strategies, and financial projections discussed over video are enormously valuable to adversaries. Insider trading liability does not expire because the encryption was broken by a technology that did not exist at the time of the call.
The Competitive Landscape: Nobody Else Has This
As of March 2026, no other video conferencing platform or video API offers production post-quantum encryption for meetings. This is not a matter of marketing positioning. We have reviewed the documentation, security whitepapers, and public statements of every major platform.
| Platform | E2E Encryption | Post-Quantum KE | PQ Signatures |
|---|---|---|---|
| V100 | Yes (E2E) | ML-KEM-768 + X25519 | ML-DSA-65 |
| Zoom | Optional (limited) | No | No |
| Microsoft Teams | 1:1 only | No | No |
| Google Meet | No (CSE only) | No | No |
| Daily | No | No | No |
| LiveKit | E2EE add-on | No | No |
| Twilio | No | No | No |
| Agora | No | No | No |
The gap is not closing. Post-quantum cryptography requires deep expertise in lattice-based algorithms, careful implementation to avoid side-channel attacks, and rigorous testing against NIST test vectors. It requires a team that has built PQ systems at production scale. V100 has that team because it shares cryptographic infrastructure with H33, which runs PQ authentication at over two million operations per second. Zoom and Teams have not disclosed any PQ development timeline.
Architecture: PQ-E2E Meeting Flow
Participant A V100 SFU Participant B
============= ======== =============
1. Generate keypairs
- ML-KEM-768 (pk, sk)
- X25519 (pk, sk)
|
|--- Public Bundle ---> relay ---Public Bundle--->|
| (1,184 + 32 bytes) |
| |
| 2. Encapsulate |
| ML-KEM-768 |
| X25519 agree |
| |
|<--- PQ Ciphertext --- relay <---PQ Ciphertext----|
| (1,088 + 32 bytes) |
| |
3. Decapsulate 3. Derive key |
ML-KEM-768 SHA3-256( |
X25519 agree x25519_shared |
|| kyber_shared)
4. Derive key |
SHA3-256( ================== |
x25519_shared | 32-byte session | |
|| kyber_shared) | key (PQ-safe) | |
================== |
================== |
| 32-byte session | |
| key (PQ-safe) | [SFU relays encrypted |
================== packets -- CANNOT decrypt] |
| |
|====== AES-256-GCM E2E encrypted media =============|
| (video, audio, data channels) |
The V100 SFU (Selective Forwarding Unit) never possesses the session key. It relays encrypted media packets between participants without the ability to decrypt them. This is true end-to-end encryption: the server infrastructure is untrusted by design. Even if V100's servers were compromised, the attacker would obtain only encrypted media that requires the session key to decrypt — and that session key was established using post-quantum algorithms that resist both classical and quantum attacks.
17 of 17 PQ Tests Passing
V100's post-quantum implementation is validated by a dedicated test suite that covers every edge case: empty messages, maximum-length credentials (64KB), bit-flipped ciphertexts, corrupted signatures, key reuse detection, and cross-algorithm compatibility. All 17 PQ-specific tests pass on every commit. The implementation has been verified against NIST's published Known Answer Test (KAT) vectors for both ML-KEM-768 and ML-DSA-65.
These tests are part of V100's broader 938-test suite that covers the entire platform. The PQ tests specifically verify: correct key generation, encapsulation/decapsulation round-trip, hybrid key derivation determinism, signature generation and verification, rejection of tampered ciphertexts, rejection of forged signatures, and performance regression (ensuring PQ operations complete within their latency budget).
Protect your meetings from quantum threats today
V100 is the only video API with production post-quantum encryption. Every meeting is protected by ML-KEM-768 + X25519 hybrid key exchange and ML-DSA-65 artifact signing. Start a free trial and look for the green PQ-E2E badge.