[Matroska-devel] Encryption

Steve Lhomme steve.lhomme at free.fr
Sun Dec 18 19:00:23 CET 2005


ivanburnin at hushmail.com wrote:
> I've got some spare cycles now so I'm looking into the encryption. 
> I've got a few questions though. A link was poste before without 
> much information, is there a document with deeper information? Has 
> anyone ever implemented encryption for Matroska files? (if so 
> everything should be compatible) And lastly, would anyone mind if I 
> changed things radically?

Jory has a DirectShow encryption filter, I'm not sure if it uses the 
built-in Matroska one. The encryption works on par with the compression 
system. And that compression systems is used a lot already. You can even 
chain compression and encryption. So if you want to change something 
(because the compression part is mostly unused there might not even be 
ways to use it right now in a muxer).

> At this point I'm considering something along the lines of an 
> encryption header that contains
> {integer identifier, UTF-8 String name, blob of bits to pass to the 
> initializer} this would occur once per encrypter per file and only 
> for the encryptor(s) that are used in that file, the name would be 
> the name of the method (used for universal identification), 
> identifier would be an in file identification number to allow for 
> multiple encryptors per file.

I don't see a radical change with what we have now.

> Then each encrypted segment (for some paring specific definition of 
> segment that does not necessarily have anything to do with segment 
> in the video sense) is composed of
> 
> {integer identifier, blob of bits to pass to the decryptor}

Where would you store this ? With each frame/block ? Or in the 
encryption private data of the track ?

> I would also propose that 0x00000000 be defined as the null 
> encryptor, allowing it to be used for the sake of sanity when 
> writing certain processors. It is also important to note that the 
> identifier for a given encryptor/decryptor can change across files 
> and that the per file header is the only dependable source for this 
> information. A smaller sized integer would be acceptable, I simply 
> chose 32-bits because it is commonly and quickly available.

That's definitely something to store in one of the binary fields of 
ContentEncryption.

> This moves an enormous quantity of the cryptography decision out of 
> the core Matroska document, creating small supplimental documents 
> for each type. I would of course be writing a number of these in 
> order to build a baseline that people could depend on. 

Yes, that's how codec works (track or chapters). The same can be done 
for encryption with many different ones just defined by their 
ContentEncAlgo.

> This format allows me to work very quickly, for other competing 
> designers to work quickly, and security. There are a lot of 
> implementation details that I haven't covered, for example there 
> should be a version number embedded in there, and a definition for 
> the signature that is mentioned briefly in the current spec, I 
> haven't addressed either of these. Actually binary format is 
> relatively unimportant from a security standpoint, and can be 
> addressed by someone more familiar with the inner workings than I 
> am.

We can add an encryption page the same way there is a codec page and a 
chapter codec page.




More information about the Matroska-devel mailing list