Skip to main content
BlindCast has two data flows — upload and playback — connected by a shared key hierarchy. The server never handles plaintext video.

​
Data flow

​
Key hierarchy

All encryption keys derive from a single master key using HKDF-SHA-256. You store and protect one secret — everything else is derived deterministically.
  • Master key: Generated once with blindcast keygen. Stored in a secret manager. Never sent to browsers.
  • Content key: Derived per contentId. The key server issues this to authenticated viewers.
  • Segment key (optional): Derived per epoch for key rotation. The manifest includes a new EXT-X-KEY tag every N segments.

​
Content IDs

A content ID is an arbitrary string that uniquely identifies a piece of content. It serves two critical purposes:
  1. Key derivation context — the key server uses it as the HKDF info parameter: different content ID = different encryption key. Two pieces of content encrypted with the same master key but different content IDs produce completely different ciphertext.
  2. Storage path prefix — by convention, encrypted segments are stored under content/<contentId>/ in S3/R2. The manifest EXT-X-KEY URI also embeds the content ID.
Content IDs must be consistent across the entire pipeline — the same string must be used when encrypting (CLI or uploader), when rewriting the manifest, and when the player fetches the key. A mismatch means the player gets a different key and decryption fails silently. Recommended format: lowercase alphanumeric with hyphens (e.g., my-video-001, lecture-2026-03). Avoid special characters — the content ID appears in URLs and S3 key paths.

​
Control plane vs. data plane

The BlindCast Server separates control plane (content management, API keys) from data plane (key derivation, encrypted byte storage):
  • Control plane handles content registration, API key management, and admin operations. All state lives in Postgres.
  • Data plane handles key derivation and presigned URLs. The key server checks the content registry before deriving keys — unregistered or disabled content returns 404.
For standalone deployments (no content registry), you can use the Key Server directly.

​
What each tool does

ToolResponsibilityRuns on
CLIGenerate keys, encrypt segments, upload to S3, run dev serverYour machine or CI
UploaderEncrypt segments in-browser, upload via presigned URLsCreator’s browser
ServerFull backend — content registry, API keys, key derivation, presign, admin dashboardDocker container
Key ServerStandalone key derivation and viewer authDocker container or Cloudflare Worker
PlayerFetch manifest, get key, decrypt segments, render videoViewer’s browser

​
Next steps