[Matroska-devel] Re: Re: Encryption
ashwood at msn.com
Wed Dec 21 09:41:04 CET 2005
"Paul Bryson" <paul at msn.com> wrote in message
news:do9mvd$s44$1 at sea.gmane.org...
> "Joseph Ashwood" wrote...
>> And one reason for not doing it is because anyone can remux it, creating
>> an unauthorized variation of the file, without requiring any sort of
>> decryption to occur (for example removing a "sold-to" track).
> You may want to look at the SignatureSlot element. It allows contents to
> be signed for authenticity, so if the content is changed, then the signing
> would no longer match.
I have looked at it, the specification is enormously incomplete, and begins
by creating a security hole. "Signature of some (coming) elements" is
inviting the attacker to play games with your signature, invalidating the
meaning of it, without invalidating the signature itself. The signature has
to be across everything that isn't purely static (i.e. the EBML header can
be excluded) otherwise you're inviting tampering. This is why I specified a
tool to be capable across levels. In my design it is entirely possible to
The failing of my design is that if there is more than one Segment the
tamper-proofing crumbles, each Segment would be signed seperately, making
tampering potentially possible. The solution is to create a super-format to
deal with this, or specify that the encrypted area contains one-or-more of
the claimed element, and that the element should only be taken as guidance,
the actual internal data may be different. This is how hard cryptography is,
even with a decade of experience, there was a subtle, but correctable,
problem with my design, there is no gaurentee that the single element design
works, instead it needs to be one-or-more, and that it is only a hint for
the processor there is not guarantee as to what it contains, it may contain
nothing. These changes may seem insignificant, but actually they
substantially improve the security behaviors.
More information about the Matroska-devel