[Matroska-devel] Re: Compromise Encryption Proposal

Paul Bryson paul at msn.com
Thu Jan 26 21:35:08 CET 2006


"Joseph Ashwood" <ashwood at msn.com> wrote...
> From: "Steve Lhomme" <steve.lhomme at free.fr>
>> 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.

The size of a full length movie can be very relative, especially where most 
video encryption occurs on very low bitrate streamable video.  Regardless, I 
would suspect that the overhead of a few bytes/frame is within the realm of 
acceptable to people that need encryption/DRM.

I would strongly resist the temptation to change the basic structure of the 
how the format works right now.  I'm guessing this would require a lot of 
rewrite of current parsers to support instead of possibly adding another 
layer for data to pass through.

It sounds like the primary reason you want to add this is to prevent "hints" 
from being given away by context of the container.  If I wanted to obfuscate 
the contained data a little more to prevent a vulnerability, I would 
probably start by adding random data onto the beginning of encrypted blocks.

For instance, In the header, I would encrypt a random number of random 
bytes.
[68][3f][12]
Then at the beginning of every encrypted block, I would add a random amount 
random data that is terminated by one of these three random bytes.
[3a][45][56][85][12][08][3f][a3][2c]
In this example, the real data would be [a3][2c]. So any block of data would 
be prefaced by one to any number of random bytes.  Blocks of data could also 
be followed by random data in the same manner.  Once encrypted, it would be 
impossible to know for sure the exact length, or position of specific data 
within the encrypted section.  Once decrypted, you can read the terminating 
bytes that were encrypted in the header and easily remove the random junk. 
This would all be part of whatever encryption "codec" and not part of the 
spec itself.

In my mind, it seems like this would remove most serious attacks by hints 
from the container as you are unsure exactly what any of the decrypted data 
should look like.  However, I don't know anything of worth about encryption, 
so I could be completely wrong.


Atamido 






More information about the Matroska-devel mailing list