Every major video conferencing platform advertises end-to-end encryption. Zoom has it. Signal has it. Google Meet offers client-side encryption. The marketing materials all say the same thing: your video and audio are encrypted, and nobody — not even the platform provider — can see or hear your meeting. This is technically true for the media content. It is profoundly misleading about everything else.
Even with perfect end-to-end encryption on the media streams, the server that orchestrates the meeting sees an enormous amount of information. It knows who joined. It knows when they joined and when they left. It knows their IP addresses, which reveal their physical locations. It knows the participant list. It knows the meeting duration. It knows how much bandwidth each participant consumed. It knows the meeting schedule. In many cases, it knows the meeting title and agenda. This is metadata, and it tells the story of your meeting without a single frame of video being decrypted.
The Metadata Problem: Why E2E Encryption Is Only Half the Story
Former NSA and CIA director Michael Hayden said publicly: "We kill people based on metadata." This is not hyperbole. It is an operational reality of modern intelligence. Metadata — the data about data — is often more valuable than content because it reveals patterns, relationships, and behaviors that content alone cannot.
Consider a law firm's video conferencing metadata. The content of the calls is end-to-end encrypted — no one can hear the legal strategy being discussed. But the metadata reveals that the firm's lead M&A partner had three calls this week with executives at Company X, each lasting over an hour. That pattern alone is enough to infer a pending acquisition, trade on insider information, or compromise the deal. The encryption on the media streams is irrelevant. The metadata told the entire story.
Healthcare organizations face the same exposure. A telehealth platform encrypts the video of a psychiatric consultation. But the server's logs show that Patient A connected to Dr. B (a psychiatrist specializing in addiction medicine) every Tuesday at 3 PM for six months. That metadata reveals a mental health diagnosis as clearly as reading the medical chart. The HIPAA encryption requirement is technically satisfied. The patient's privacy is thoroughly compromised.
Intelligence agencies understand this intimately. The NSA's bulk metadata collection programs — revealed by Edward Snowden in 2013 — did not intercept call content. They collected call metadata: who called whom, when, for how long, and from where. That metadata was sufficient to map entire terrorist networks, identify informants, and predict operations. The same analytical techniques applied to video conferencing metadata would reveal corporate strategies, legal proceedings, medical conditions, and intelligence operations.
What the server sees with "end-to-end encrypted" video
Current "E2E Encryption" Is Half the Story
Zoom's end-to-end encryption, launched in 2020 after significant public pressure, encrypts the media streams between participants so that Zoom's servers cannot decode the audio or video. This is real and valuable. But Zoom's servers still orchestrate the connection, maintain the participant list, track join and leave times, log IP addresses, and compute billing based on meeting duration. The server must see this metadata to function.
Signal, widely regarded as the gold standard for encrypted communication, faces the same architectural limitation for group calls. Signal's server must know which devices are in a group call to route the encrypted media between them. The content is encrypted. The fact that these specific devices are communicating, at this time, for this duration, is visible to the server.
This is not a failure of engineering. It is a fundamental architectural limitation. A server cannot route packets between participants it does not know about. It cannot bill for usage it cannot measure. It cannot enforce meeting capacity limits if it does not know how many people are in the room. Every video platform that has ever existed — until now — has accepted this tradeoff as unavoidable. The server must see the metadata to do its job.
V100 eliminates this tradeoff entirely, using a technology that was considered impractical for real-time applications until very recently: Fully Homomorphic Encryption.
V100 + H33 FHE: Computing on Data You Cannot See
Fully Homomorphic Encryption (FHE) is a cryptographic technique that allows computation on encrypted data without decrypting it first. You can add encrypted numbers together and get an encrypted result that, when decrypted, equals the sum of the original numbers. You can compare encrypted values. You can search encrypted text. All without ever seeing the underlying plaintext. The server does its job — routing, billing, analytics — while the data remains encrypted throughout.
FHE has been theoretically possible since Craig Gentry's groundbreaking 2009 paper. For 15 years, it was too slow for production use. A single FHE operation could take seconds or minutes. Running a video conferencing server on FHE was science fiction. That changed with H33.
H33 operates the fastest production FHE engine ever built. The BFV (Brakerski/Fan-Vercauteren) engine completes a single authentication operation in 38.5 microseconds. That is 2.17 million operations per second sustained on production hardware. This is not a research prototype. It is production code benchmarked at scale on AWS Graviton4 metal instances with sub-1% variance over 120-second sustained runs.
V100 integrates H33's FHE engine to encrypt every category of meeting metadata. The result is the first video conferencing platform where the server is mathematically unable to see who is in your meeting.
FHE-encrypted metadata layers in V100
The H33 Stack That Makes This Possible
Production FHE for real-time applications requires extraordinary engineering. The raw mathematics of FHE — polynomial multiplication over large moduli, noise management, key switching — is computationally intensive. Making it fast enough for a video conferencing server requires optimizations at every level of the stack: algorithmic, architectural, and hardware. H33 has spent years building this.
H33 Production Cryptographic Stack (powering V100)
| Component | Function | Latency | PQ-Secure |
|---|---|---|---|
| BFV Engine | Exact arithmetic FHE (metadata, participant IDs, search) | 38.5µs/op | Yes (lattice) |
| CKKS Engine | Approximate arithmetic (billing, analytics, scoring) | ~50µs/op | Yes (lattice) |
| ML-KEM-768 | Post-quantum key exchange for media streams | ~30µs | Yes (FIPS 203) |
| ML-DSA-65 | Post-quantum signatures on recordings/transcripts | 291µs/batch | Yes (FIPS 204) |
| SIMD Batching | 32 users packed into single ciphertext | 939µs/batch | Yes |
The BFV engine uses Montgomery NTT (Number Theoretic Transform) with Harvey lazy reduction for the polynomial multiplications at the heart of FHE. Twiddle factors are stored in Montgomery form, eliminating all division from the hot path. Parallel NTT across moduli via Rayon, batch CBD sampling (one RNG call per 10 coefficients), and NTT-domain fused inner products (one final inverse NTT instead of per-chunk) bring individual operation latency down to 38.5 microseconds — fast enough that metadata operations do not introduce perceptible delay in a video conferencing context.
SIMD batching packs 32 users into a single ciphertext (4096 polynomial slots divided by 128 biometric dimensions). This means a 32-person meeting's entire participant list can be processed in a single FHE operation — 939 microseconds for the batch, less than one millisecond for all participants combined.
Architecture: The Zero-Knowledge Meeting Flow
Client A V100 Server (FHE) Client B
======== ================ ========
1. Encrypt metadata
- user_id --> BFV(user_id)
- ip_addr --> BFV(ip_addr)
- join_ts --> CKKS(join_ts)
|
|--- Encrypted metadata ---> Server receives ONLY <--- Encrypted metadata ---|
| (BFV ciphertexts) ciphertexts. Cannot (BFV ciphertexts) |
| decrypt any field. |
| | |
| 2. FHE Routing (on ciphertext) |
| BFV inner-product match: |
| enc(token_A) * enc(token_B) |
| = enc(match_score) |
| Route if match_score > threshold |
| (threshold comparison on ciphertext) |
| | |
|<========== AES-256-GCM E2E Encrypted Media (PQ key exchange) ===================>|
| Video + Audio + Screen Share |
| | |
| 3. FHE Billing (CKKS) |
| enc(minutes) * enc(rate) |
| = enc(charge) |
| Server bills without seeing amount |
| | |
| 4. FHE Analytics (BFV + CKKS) |
| enc(attention_scores) --> enc(avg) |
| enc(speaking_times) --> enc(distribution) |
| Server computes metrics on ciphertext |
| |
5. Decrypt results locally 5. Decrypt results locally
CKKS(charge) --> charge BFV(analytics) --> report
BFV(analytics) --> report
The critical insight is in Step 2: FHE routing. The server performs a BFV inner-product operation between encrypted connection tokens. The result is an encrypted match score. The server then performs a comparison operation — still on ciphertext — to determine if the two clients should be connected. At no point does the server decrypt the tokens or learn the identities of the participants. It performs the routing logic entirely on encrypted data and relays the encrypted media without knowing who is on either end.
Performance: What FHE Metadata Costs
FHE is not free. The mathematical operations on ciphertexts are more expensive than the same operations on plaintext. The question is whether the overhead is acceptable for a real-time video conferencing application. The answer, with H33's engine, is yes — by a wide margin.
FHE overhead per meeting operation
A single FHE metadata operation takes 38.5 microseconds. A full 32-user batch takes approximately 1 millisecond. For context, the WebRTC ICE negotiation that every video call requires takes 200-500 milliseconds. The DTLS handshake takes another 50-100 milliseconds. Codec initialization takes 10-50 milliseconds. The FHE metadata overhead is a rounding error against the existing setup costs.
Once the meeting is running, FHE operations happen in the background for billing and analytics. These are batch operations that execute asynchronously — they do not sit in the media pipeline's critical path. The video frames, audio packets, and screen share data flow through the standard AES-256-GCM encrypted media pipeline with zero additional latency from FHE.
Who Needs Zero-Knowledge Video Conferencing
Defense and intelligence: Classified briefings where even the participant list is sensitive. If an adversary knows that General X met with Contractor Y three times this week, the content of the meeting is secondary — the relationship pattern is the intelligence. FHE metadata encryption ensures that even a compromised server reveals nothing about who is communicating with whom.
Legal — attorney-client privilege: The fact that a client is meeting with a specific type of attorney is itself privileged information. A corporate executive meeting regularly with a criminal defense attorney signals an investigation that has not been disclosed. FHE protects the meeting pattern, not just the meeting content.
Healthcare — beyond HIPAA compliance: HIPAA requires encryption of protected health information in transit. It does not require encryption of the metadata about who is receiving care from whom. V100's FHE metadata encryption goes beyond compliance to provide true zero-knowledge telehealth — the platform cannot determine that a patient is seeing a particular specialist, even from server logs.
Corporate M&A — leak-proof deal rooms: The biggest risk in M&A is not that someone will intercept the negotiation content. It is that someone will observe the pattern of meetings between the acquiring and target companies and trade on that information before the deal is announced. FHE metadata encryption makes the meeting pattern invisible.
Journalism — source protection: A journalist's meeting with a whistleblower is dangerous even if the conversation is encrypted. If the server logs show that Reporter X connected with Government Employee Y, the source is compromised. FHE ensures that the platform cannot produce this information even under legal compulsion.
What V100 Cannot See — Even Under Subpoena
This is not a privacy policy. It is a mathematical guarantee. V100's FHE metadata encryption means the server never possesses the plaintext for the following data, and therefore cannot produce it in response to any legal process:
Data V100 cannot produce (FHE-encrypted, keys held by participants)
V100 can produce encrypted ciphertexts. But without the decryption keys — which are held exclusively by the meeting participants — these ciphertexts are computationally indistinguishable from random noise. A court order cannot compel V100 to produce data it does not possess. The decryption keys never touch V100's servers.
The Competitive Moat: Why Nobody Else Can Do This
FHE metadata encryption for video conferencing requires production-grade homomorphic encryption running at real-time speeds. This is not something you achieve by adding a library. The FHE operations must complete in microseconds, not milliseconds or seconds. The implementation must handle polynomial multiplication over large moduli, noise budget management, key switching, and SIMD batching — all at a throughput that does not bottleneck a video server handling thousands of concurrent connections.
H33 is the only company operating FHE at internet scale. The production benchmark is 2,172,518 authentications per second sustained over 120 seconds with plus or minus 0.71% variance. This throughput comes from years of deep optimization: Montgomery NTT with Harvey lazy reduction, NEON-accelerated Galois operations, NTT-domain persistence, batch attestation, and in-process DashMap caching. Each optimization was validated in production on Graviton4 metal instances, and several promising optimizations (arena pooling, fused NTT pre-twist, jemalloc) were tested and rejected because they regressed production performance.
No other video platform has this capability. Zoom, Microsoft, Google, Daily, LiveKit, Twilio, and Agora would need to either build an FHE engine from scratch (years of work) or license one that operates at sufficient throughput (no such offering exists outside H33). V100 has this capability because it is built on the same cryptographic infrastructure as H33's production authentication platform.
Code: FHE Metadata Encryption in V100
// V100 FHE Metadata Encryption — Zero-Knowledge Meeting Setup
use h33::{BfvEngine, CkksEngine, Plaintext, Ciphertext};
pub struct EncryptedMeetingMetadata {
participant_tokens: Vec<Ciphertext>, // BFV-encrypted IDs
join_timestamps: Vec<Ciphertext>, // CKKS-encrypted times
duration_minutes: Ciphertext, // CKKS-encrypted duration
billing_total: Ciphertext, // CKKS(minutes * rate)
}
pub fn route_encrypted(
bfv: &BfvEngine,
token_a: &Ciphertext, // Encrypted participant A
token_b: &Ciphertext, // Encrypted participant B
) -> Ciphertext {
// Inner product on ciphertext — result is encrypted
// Server learns NOTHING about who A or B are
bfv.multiply_plain_ntt(token_a, token_b)
// Returns enc(match_score) — route if above threshold
}
pub fn compute_billing(
ckks: &CkksEngine,
enc_minutes: &Ciphertext, // CKKS(usage_minutes)
enc_rate: &Ciphertext, // CKKS(per_minute_rate)
) -> Ciphertext {
// Approximate arithmetic on encrypted values
// Server computes charge without seeing amount
ckks.multiply(enc_minutes, enc_rate)
// Returns enc(total_charge) — only customer can decrypt
}Honest Limitations
We believe in full transparency about what this technology can and cannot do today.
FHE metadata adds approximately 1ms overhead per batch operation. This is negligible for meeting setup (where ICE negotiation takes 200-500ms) but it is not zero. For applications that require sub-millisecond metadata processing at extreme scale, the overhead is measurable.
Client-side key management is required. Because V100's server never possesses the decryption keys, participants must manage their own FHE keys. If a participant loses their key, V100 cannot recover their encrypted metadata. This is the fundamental tradeoff of true zero-knowledge: the platform cannot help you if you lose your keys, because it never had them.
FHE metadata encryption is on the product roadmap for Q3 2026. The H33 FHE engine is production-ready and benchmarked. The V100 integration for participant routing, billing, and analytics is in active development. The post-quantum key exchange and media encryption described in our PQ encryption article is live today. FHE metadata encryption is the next layer and is targeted for production release in Q3 2026.
Network-level metadata (IP addresses) requires additional infrastructure. FHE encrypts the application-level metadata processed by V100's servers. IP addresses visible at the network layer require additional measures such as onion routing or VPN tunneling. V100 is evaluating integration with privacy-preserving network transports for a future release.
Build on the only zero-knowledge video platform
V100 is the first video API where the server is mathematically unable to see your meeting metadata. Post-quantum media encryption is live today. FHE metadata encryption ships Q3 2026. Start building now and your applications will inherit zero-knowledge capabilities automatically.