[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