[Matroska-devel] Re: Compromise Encryption Proposal
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
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.
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
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.
More information about the Matroska-devel