Why We Deliver Our Festival DCPs Without Encryption

Most of our festival DCPs go out unencrypted. Not because we forgot the extra step, and not because we don't understand what a Key Delivery Message does — we understand it well enough to know it's solving a problem festival screenings mostly don't have.

That's the decision, stated plainly. Encryption gets added when a distributor or a paid theatrical booking asks for it. For a single festival slot, in a program we don't control the projection booth for, we've watched the security layer cause more screening problems than it prevents.

This is what a KDM actually locks, where we've seen it break, and what we send to festivals instead.

What a KDM Actually Locks

A DCP's content essence is encrypted with AES-128 in CBC mode. The AES key itself is never distributed directly — it's wrapped in RSA-2048 and delivered as a Key Delivery Message, an XML file that only unlocks against the specific hardware it was generated for. Every cinema playback system holds its own private key, buried in secure hardware inside the media block, tied to that unit's serial number. A KDM built for one projector will not play on another, and it will not play outside the exact date/time window it was authored with.

That's a well-built system, for the job it's built to do. It assumes a theatrical release window, multiple venues, and a real piracy risk worth managing against a title with money behind it. A festival screening, in most cases, has none of that threat profile: one venue, one slot, a programmer who already vetted the film to get it on the schedule. There's no distribution chain to protect yet, because there's no distribution deal yet — just a projector, a scheduled hour, and an audience that bought a ticket to see the film play.

Before we commit a title to that layer of hardware-specific locking, we go through the same DCP-house vetting checklist we use for any delivery decision — because encryption isn't free, and the cost shows up at showtime, not on our end. Every extra layer between a finished master and a lit screen is a place something can fail on someone else's hardware, at a moment we're not in the room to fix it.

The Failures We've Watched Happen

The failure modes are specific, and they're not rare enough to ignore. A KDM generated against the wrong media block certificate simply won't decrypt — the wrong serial number was on file when it was authored, sometimes because the venue swapped a server between when they confirmed specs and when the film screened. Clock drift on a projection server closes a validity window early, or a timezone calculation error means the key expires before house lights go down on the correct local time. Corrupted key files from a bad transfer are their own separate failure, on top of everything above.

That's why festivals that do require encryption typically ask for a test key ahead of the event, then a separate final key issued closer to the actual screening. It's a sensible safeguard — and it's also a quiet admission that the system is fragile enough to need testing twice. We'd rather not build a delivery around something that needs its own rehearsal.

None of this is a knock on the projectionists or the festival's tech team — most of these failures trace back to a mismatch between what a lab authored and what a venue runs on a given night — a coordination problem, not a competence one. But it's still our film in the room when a certificate doesn't match, and a blank screen doesn't care whose process broke.

What We Send Instead

Encryption was never the default festival requirement to begin with. Most submissions don't ask for a secure DCP at all — a KDM only enters the conversation when a specific festival or distributor requests one, which tends to happen around a paid theatrical booking, not a premiere slot.

So here's our day-to-day practice: an unencrypted DCP as the primary delivery, formatted to spec, tested on our own playback chain before it leaves the building. Alongside it, on the same drive, a ProRes file or a Blu-ray as backup — the same approach we take across our full festival deliverable list. That backup isn't a hedge we hope stays unused — more than once it's been the file that played, after a projection booth we'd never met before hit a snag with something else entirely.

We still label every drive clearly and confirm specs with the festival's tech coordinator ahead of shipping — the encryption decision doesn't replace that conversation, it just removes one variable from it. And if a distributor picks up the film afterward and wants a locked master for a real theatrical run, that's a separate delivery, built for that separate job, with its own KDM and its own testing pass. The two situations aren't the same problem, so we stopped treating them like they needed the same answer.

Working note

Encryption is a distribution-security tool. We reach for it selectively — a real theatrical run, a distributor mandate — not by default, because the festival context it usually gets applied to doesn't carry the threat model it was designed for. The version of this decision that matters most isn't cryptographic; it's whether the film screens on time, in the room, in front of the people who came to see it. That's the job a DCP delivery is there to do, long before it's a film anyone else gets to see.