[Matroska-devel] Re: Encryption
ashwood at msn.com
Tue Dec 20 08:25:11 CET 2005
----- Original Message -----
From: "Paul Bryson" <paul at msn.com>
Subject: [Matroska-devel] Re: Encryption
> "Joseph Ashwood" wrote...
>> I was thinking that this should actually be a wrapper around a block.
>> Since it will only add a few bytes the overhead is minimal, and it will
>> prevent a lot of mistakes that are very easy and very subtle. In fact I
>> had hoped to make this a generic wrapper, so that each level and each
>> track can be encrypted seperately if desired. The reason for this is that
>> in some instances the various taggings/tracks/etc will leak information,
>> and the encryption should be able to prevent this.
> The current system was designed to have the encryption only encrypt the
> data portion of the Block, not the entire thing. I'm guessing that any
> extra data that needed to be passed to the decrypter could be stored in
> that same Block, aware only to the decrypter itself.
Actually this presents a potential weakness, although admittedly a small
leakage. By only encrypting the payload a surprising amount of information
can be derived, allowing highly selective attacking. I see no problem with
my proposal actually being embedded inside a block, or with placing some
extra necessary information in an additional subheader.
> One reason for doing this is it allows the file to be manipulated, without
> requiring any sort of decryption to occur. For instance, the file could
> be remuxed if it were damaged.
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). That's why I'm pushing
for a generic tool that can be placed at any level of the file, if
unauthorized remuxes are to be prevented, then the encryption can be placed
higher up. If unauthorized remuxes are to be allowed, the encryption can be
placed lower. Like I said before there are a lot of very easy, and very
subtle holes that can be introduced.
> [C]urrent system. . . hasn't been implemented by anyone
Thanx, I was very interested in information about whether or not it had been
implemented, which would prevent a big rip and replace.
> So if it were possible to use some method that resulted in the same
> benefits, that would be wonderful.
I think the system I have proposed offers such benefits, even if it is in a
very subtle way. By using a design that stands in the parsing pipeline it is
possible to create a design that works at any level, even within the block
itself, and can make use of different handlers for different tracks and
different parts of the file.
More information about the Matroska-devel