Skip to main content
“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:
ComponentTrust levelWhat it sees
Creator’s browserTrustedPlaintext video + keys
Viewer’s browserTrustedPlaintext video after decryption
Key serverPartially trustedMaster key, derived keys — never plaintext video
S3 / CDNUntrustedEncrypted 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):
  1. Each video is split into short .ts segments by an HLS packager (e.g. FFmpeg).
  2. Each segment is encrypted with AES-128-CBC using a per-content key derived from the master key via HKDF.
  3. The HLS manifest (.m3u8) is rewritten to include EXT-X-KEY tags pointing at the BlindCast key server.
  4. At playback, the browser fetches segments from S3/CDN and requests the content key from the key server.
  5. 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)
This means:
  • 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.