[Matroska-devel] Compromise Encryption Proposal

Joseph Ashwood ashwood at msn.com
Thu Jan 26 04:41:44 CET 2006

----- Original Message ----- 
From: "Steve Lhomme" <steve.lhomme at free.fr>
Subject: Re: [Matroska-devel] Compromise Encryption Proposal

> From what I understood you want to encrypt the content of blocks, 
> including the block itself.

Actually it substantially and notably changed, for starters the new proposal 
is that all elements contain an optional additional entry (which I will 
tentatively call TransformID), specifically to take care of:

> The main one is that we want to be able to parse the file.

In order to keep the capability of the authentication and authorization 
though it is necessary that the decryptor be able to change everything. That 
is the reason for the substantial change in the parsing that the decryptor 
is made capable of replacing it's current element and creating new siblings 
(it is disallowed from removing or altering current siblings). Except is 
rare and obscure cases where specific security requirements are necessary 
(or where substantial space savings can occur, and the reason I refer to it 
as TransformHandler) it will simply rewrite the TranformID to a 
NullTransform and decrypt the payload.

> I still think the system we have that allows any kind of (chained) 
> encryption of the Block and the Codec private data (ie everything that is 
> not part of the container) is flexible and secure enough.

I could not locate any usable specification for it, and what I did find I 
broke several messages ago.

> Also, we created EBML to avoid C-struct formats that have fixed length 
> elements at defined place and can hardly evolve. So please don't use that 
> kind of format to enhance matroska.

I was just using the term because the correct one escaped me at the time, I 
expected that the format would be changed, format is largely irrelevant in 
cryptography, but contained and exposed data is critical.

> You also mentioned adding a few bytes to each frame wouldn't change the 
> overhead much. But it actually does. A video Block (without the data) is 
> typically 5 long. And there are 130,000 ones for a full length video 
> track. So adding a few bytes increases the overhead a lot. That's why we 
> put information that is repeted a lot in headers.

It is certainly an option to use the header for most of the information, but 
I should point out that a full length movie is 600+MB, and that a 4 byte 
(optional) overhead would represent only 1/2MB for an additional overhead of 
<0.08%. Since the header information is already assumed a repeated part of 
the block, if this is made explicit, and overridable at the block level, for 
the TransformHandler the overhead could be practically eliminated. I only 
placed in in the block for convenience. In fact each element could easily 
contain an (optional) DescendentTransformID to act as a default, but I don't 
know how useful this would be outside of the header.

As you can probably see, I have no problem making even sweeping changes to 
the design, moving information around, etc, as long as the cryptographic 
features remain.

> Other than that, if you agree on what I said, could you layout the 
> changes/additions you need in the specs, so that I can add them (and we 
> comment more first) ?

I firmly believe we need more comments, #3 below was added just as a result 
of your reply.

My proposed changes so far (the ones that have been largely discussed):
1) each element has an implicit TransformID, the implicit is NullTransform, 
explicit allows it to be changed.
2) an additional top-level or near top level (open to debate on placement) 
element for TranformInitializer. TransformInitializer is {TransformID, 
TransformName, InitializationData}. TransformID is a binary blob used to 
identify the transform later, fixed or dynamic size doesn't matter, 
TransformName is a unique name used in order to locate and load the 
transform handler, and InitializationData is the initialization data that is 
passed to the initialization of the transform.
3) The header (possibly others?) include an implicit DescendentHandlerID to 
provide the default HandlerID for Blocks
4) When there is a DescendentHandlerID in the Header associated with a 
Block, a TransformID in the Block takes precedence.
5) The transform handler (identified by TransformID) be allowed to alter 
it's element in any way.
6) TransformID 0 is always reserved for the NullTransform (i.e. does nothing 
except remove the TransformID from the element). It can be safely omitted 
from any location and is only useful for clarity.
7) If there are duplicate TransformIDs the decoder only needs to 
successfully initialize one of them, as such the encoder should locate the 
more specific ones earlier in the file, and the decoder should process the 
earlier file located ones first.

Proposed but I think needs more discussion due to potential parsing issues
8) The transform handler be allowed to create siblings to it's element, 
useful if transform handler offers compression or inclusion from an outside 
file. There are also security implications from this, but they are obscure 
and convuluted enough to be ignored as they reduce to the same security 
implications as the ability to replace the transform handler

Anything I missed?

> Thanks in advance.
I'd also like to thank everyone. This has evolved greatly from it's original 
inception and I feel we are making great progress towards something useful 
for everyone.

More information about the Matroska-devel mailing list