[Matroska-devel] Re: EncryptedBlock format

Steve Lhomme steve.lhomme at free.fr
Mon Jul 10 16:29:27 CEST 2006


Joseph Ashwood wrote:
>> Let's just put this in the ODRL management, since that's where rights 
>> are managed, not at the container level. So the container design 
>> shouldn't influence for one right or the other.
> 
> That'll work. The I'd suggest we go with the Matroska exclusive version, 
> leaving the header information outside the MAC.

OK, I'll do that.

>>>> I don't understand what the TransformHandler is for: encryption ? 
>>>> What's
>>>> the difference with the EncryptedBlock above ?
>>>
>>> The TransformHeader/TransformInitializer is to assign the UID for the 
>>> transform within the file, and to provide initialization data for the 
>>> transform, this provides a place to put some potentially very large 
>>> information (20KB may not be unusual for some of the initializers, 
>>> and 1MB is conceivable). The only output of this will probably be an 
>>> error/success code. This header is the Blob_0 we've discussed before.
>>
>> So what about TransformHandler ? Or you mean TransformHeader ?
> 
> Ok I think I've at some point switched terminology, so just to begin 
> from the basic concepts
> TransformHandler is an implementation of the specified transform
> TransformInitializer/TranformHeader is the initialization information 
> given to TranformHandler prior to attempting to decode any of the 
> EncryptedBlocks, this also supplies the demuxer with the UID for the 
> TransformHandler within the file
> EncryptedBlock is an encrypted (Simple)Block with a UID for the 
> TransformHandler.

OK. I get it now.

>>> An EBML version should have some extra capabilities that haven't been 
>>> discussed here, like; the ability to explode into several elements 
>>> instead of just one, external referencing, etc. basically if you look 
>>> at XML-ENC and XML-SIG that's what a generic EBML encryptor should 
>>> do, it's actually quite a bit more complex. What we've done so far is 
>>> really very targetted at what is needed for DRMing files, that's a 
>>> big part of why I'm favoring it as a Matroska instead of an EBML.
>>
>> Well, the EBML based solution we have in mind would just be the same 
>> as the matroska one. The Transforms init in the EBML header, a 
>> Transform element that contains the element(s) to be un-Transformed. 
>> That's more generic, and still used the same principles. That means 
>> you could encrypt chapters, tags, codec information too.
> 
> As long as it is kept inside Matroska, even if it is a strange 
> hybrid-level structure, I would consider that DRM. I thought the DRM vs 
> EBML was intended to extend beyond Matroska where it would quickly hit 
> the limits of it's capabilities.

Yes, in EBML it's also to be used for something else. But given this 
solution can be used for a lot of other formats (encryption only as some 
levels and ODRL rights that can apply to a lot of things), I think it's 
a good opportunity to make it generic, as it's not much different. 
Pumping the EBML version would also make it easier to track DRMed 
Matroska files and disable playback in other parsers (provided they do 
check the EBML version)...

>> But that also means the ODRL rights should be put in the EBML level 
>> too. I'm not sure ODRL is generic enough to handle other things than 
>> multimedia ???
> 
> It appears to be capable, although it is in large part a matter of 
> pounding a square peg into a round hole.

True. But if it's done well, you only need a small set of fields to 
define common rights...

>>>> There are more people on the list (not necesseraly subscribed, but 
>>>> lurking
>>>> via gmane).
>>>
>>> Yep, and they all ignored the crypto conversation as well. :)
>>
>> Damn right :(
>>
>> Now that matroska is mature and stable, there aren't so many technical 
>> discussions anymore :(
> 
> That happens a lot in user-level software, "Developer" starts to mean 
> "Person that knows how it works" instead of "Person with technical 
> knowledge and abilities to advance the design." I still favor bringing 
> it onto the main list, if for no other reason than to prepare them for 
> the introduction.

OK, done now :)

-- 
robUx4 on blog <http://robux4.blogspot.com/>



More information about the Matroska-devel mailing list