[Matroska-devel] Compromise Encryption Proposal
steve.lhomme at free.fr
Wed Jan 25 07:14:07 CET 2006
I tried to read all the previous posts in depth, but I currently lack
From what I understood you want to encrypt the content of blocks,
including the block itself. As Paul replied, there are good reasons not
to do that. The main one is that we want to be able to parse the file.
The track ID and the timecode information is in the Block itself. So if
you want to skip in the movie, you'd have to decrypt all blocks in a
Cluster to find the one you're looking for... I understand showing
everyone the timecode and track part of the movie may expose some
vulnerability. But I don't think the key information is there. And the
encryption would be very weak if such information could help discover
the encryption scheme/key.
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.
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.
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.
We don't have any system at the container level to allow switching the
encryption in the middle. But that should be the job of the encryption
"codec" anyway to cover that.
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) ?
Thanks in advance.
Joseph Ashwood wrote:
> I think this compromise accomplishes the desires of both sides. I'm
> having trouble locating the correct terminology, so I'm just going to go
> all the way back to C-structs (Segment is in this case an example of a
> Keep the initializer proposal I made. With some changes though. In
> addition to sitting alonog side Segment at the highest level, any struct
> can contain them, effectively defining local variables. Local
> definitions supercede those that are global to them. For duplicate
> definitions at the same level, behavior is not defined.
> Each struct contains a single, optional field called Transform (name can
> and should be changed as needed). Transform is a 32-bit bitfield,
> defining the (previously initialized) transform to be used. The inverse
> transform is free to make any changes to the struct, so for example, it
> is free to change timecodes. An inverse transform may return a single
> struct, multiple structs, or no structs, each of which can be of any
> type, and may contain an additional Transform requirement. The inverse
> transform SHOULD avoid changing the information except where security
> trumps this requirement.
> This allows the parser to perform look-ahead processing, as Paul
> desired, but also allows the inverse transform to force non-malleability
> in cases where it is warranted. 99+% of the time, the biggest change
> will be if the transform results in multiple SimpleBlocks.
> Is this a worthwhile compromise?
More information about the Matroska-devel