[Matroska-devel] Compromise Encryption Proposal

Joseph Ashwood ashwood at msn.com
Thu Dec 22 19:10:12 CET 2005


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 struct).

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?
                Joe 





More information about the Matroska-devel mailing list