“Zero-knowledge” describes a specific trust property: the server that stores your video cannot read it. It holds encrypted bytes — ciphertext — but never the key needed to decrypt them. Only the creator and authorized viewers hold keys.
The trust boundary
Every component in a BlindCast deployment sits on one side of a trust boundary:
| Component | Trust level | What it sees |
|---|
| Creator’s browser | Trusted | Plaintext video + keys |
| Viewer’s browser | Trusted | Plaintext video after decryption |
| Key server | Partially trusted | Master key, derived keys — never plaintext video |
| S3 / CDN | Untrusted | Encrypted bytes only |
What “zero-knowledge” means here — and what it doesn’t
BlindCast’s zero-knowledge property is about the storage layer, not the key server:
- S3 / CDN cannot read your video. They store ciphertext. Without the content key, the bytes are meaningless.
- The key server does hold the master key. It derives per-content keys on demand via HKDF. You must trust and secure your key server.
BlindCast is not end-to-end encrypted in the Signal/WhatsApp sense. The key server is a trusted intermediary — it can issue keys to any viewer who passes authentication. If the key server is compromised, content keys can be obtained.Zero-knowledge here means your storage provider (S3, CDN) learns nothing about your content.
How encryption works
BlindCast uses the HLS encryption model (RFC 8216 §4.3.2.4):
- Each video is split into short
.ts segments by an HLS packager (e.g. FFmpeg).
- Each segment is encrypted with AES-128-CBC using a per-content key derived from the master key via HKDF.
- The HLS manifest (
.m3u8) is rewritten to include EXT-X-KEY tags pointing at the BlindCast key server.
- At playback, the browser fetches segments from S3/CDN and requests the content key from the key server.
- The browser decrypts each segment locally using the Web Crypto API before handing frames to the video element.
The plaintext segment data never leaves the browser during playback.
Key derivation: why it matters
BlindCast doesn’t store one key per video. It stores one master key and derives content-specific keys on demand via HKDF (HMAC-based Key Derivation Function, RFC 5869):
Master Key + Salt → HKDF → Content Key (per contentId)
Content Key → HKDF → Segment Key (per epoch, for rotation)
- Rotating access for a specific video requires only invalidating or revoking the lease for that content ID — not re-encrypting the video.
- Adding a new video doesn’t require generating or storing a new root key.
- The master key can be stored in a secret manager; derived keys are computed at request time.
See Architecture Overview for the full key hierarchy and how derivation fits into the system. 
