Subject: [Cellar] Encryption in Matroska

From: Michael Bradshaw <[email-masked]>
Date: Wed, 20 Jul 2016 20:44:52 +0200

There are currently 5 "supported" encryption algorithms in Matroska: DES,
3DES, Twofish,  Blowfish, and AES. WebM only uses AES (128-bit)
<https://www.webmproject.org/docs/webm-encryption/>.

   - *Should Matroska keep all these algorithms?* DES is considered
   "broken" (though still generally impractical to attack) for example, so I'm
   not sure it's worth encouraging it's use. I'm not sure that all the
   algorithms are still desirable.
   - *Should Matroska specify a fixed key size
   <https://en.wikipedia.org/wiki/Key_size>?* AES's key size isn't
   specified, though WebM requires it to be 128-bits. DES and 3DES have a
   fixed key size, but Twofish and Blowfish have a variable key size. Matroska
   either needs to predetermine the key size, or add a new element to signal
   the key size.
   - *WebM only encrypts the contents of Block and SimpleBlock elements;
   should Matroska only support that or should other things be encryptable too
   (e.g. attachments)?* Steve and I talked about this briefly and we both
   agreed that encrypting more than Block/SimpleBlock is probably not
   worthwhile. But I think it's worth asking on the mailing list.
   - *Which block cipher modes should be supported?* Matroska doesn't
   specify any, which makes using any encryption impossible (because the
   encryptor and decryptor might not agree). WebM specifies CTR. ECB should
   probably be avoided because frames will generally be greater than a single
   block*. I'm not sure if other modes besides CTR are desirable. If more than
   just CTR, then we'll need an element to describe the block cipher mode.
   - *What key stretching <https://en.wikipedia.org/wiki/Key_stretching>
   algorithms should Matroska support?* This question assumes we're trying
   to support password-protected files.

Personally, I'm in favor of just adopting WebM's encryption specification
<https://www.webmproject.org/docs/webm-encryption/> and removing the other
encryption features of Matroska (assuming no one is using them). They can
be added if needed in future specifications. I've got more questions and
thoughts on encryption (e.g. initialization vectors) and signing in
Matroska but I'll delay asking them because this email already asks enough
questions.

*Yay for ambiguous terminology. Lowercase "block" refers to the encryption
cipher's block. Uppercase "Block" is the Matroska element.

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 20 Jul 2016 21:03:37 +0200

Hey,

> There are currently 5 "supported" encryption algorithms in Matroska:

All the elements dealing with encryption/DRM have been deprecated since
version 2. This is visible (gray text on gray background) on the
old/still official specs page[1], though it is unfortunately not clear
yet from the specs XML file (see also[2] where Dave stumbled across the
same problem).

The intention was to decide on whether or not to remove all the
deprecated elements for Matroska v4.

However, I wasn't aware…

> Personally, I'm in favor of just adopting WebM's encryption
> specification <https://www.webmproject.org/docs/webm-encryption/> and
> removing the other encryption features of Matroska (assuming no one is
> using them).

…of WebM working on encryption. Obviously we shouldn't remove the
elements used by WebM for encryption.

I know doing encryption right is incredibly hard. I'm solely an
interested bystander wrt. all things encryption, and if more
knowledgeable people work on and provide ways for it to work with
Matroska then I'm all for it.

In short: +1 for adopting WebM's encryption specification.

> *Yay for ambiguous terminology. Lowercase "block" refers to the
> encryption cipher's block. Uppercase "Block" is the Matroska element.

This is an area where clarity matters. Maybe these should be changed to
e.g. "Matroska Blocks" vs "cipher's block" — always use the full term.

Kind regards,
mosu

[1]  https://www.matroska.org/technical/specs/index.html
[2]  https://github.com/Matroska-Org/matroska-specification/pull/26

---

From: Michael Bradshaw <[email-masked]>
Date: Wed, 20 Jul 2016 21:15:38 +0200

> yet from the specs XML file (see also[2] where Dave stumbled across the

Are you sure? They aren't disabled/deprecated on the official specs page.
ContentEncryption and its children have the same coloring as other level 5
and 6 elements.

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 20 Jul 2016 21:25:49 +0200

Hey,

> Are you sure? They aren't disabled/deprecated on the official specs
> page.  ContentEncryption and its children have the same coloring as
> other level 5 and 6 elements.

Yes, I am sure. Please see the comments by Steve Lhomme and myself at
[1], especially [2] and [3] for a reason why it's currently this
confusing.

I plan on creating a pull request that'll add minver= and maxver= for
all those elements that the current Matroska specs page[4] shows as
gray-on-gray. Even though not all of the descriptions of those elements
say explicitly that they're deprecated that was the intention of using
gray-on-gray.

Unless Dave beats me to such a pull request, of course ;)

Getting back to the topic of encryption. We deprecated the elements
because we were aware that what we had specified wasn't enough to build
a proper system around it. No one on the Matroska team had any real
interest in doing the work for improving it either. Therefore:
deprecation. However, if other people (the WebM project) have done
exactly that work then I have no problems whatsoever with adopting that
work and making the corresponding elements active again.

Kind regards,
mosu

[1]  https://github.com/Matroska-Org/matroska-specification/pull/26
[2]  https://github.com/Matroska-Org/matroska-specification/pull/26#issuecomment-231005526
[3]  https://github.com/Matroska-Org/matroska-specification/pull/26#issuecomment-232134896
[4]  https://www.matroska.org/technical/specs/index.html

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 20 Jul 2016 15:30:42 -0700

Michael Bradshaw wrote:
> using them). They can be added if needed in future specifications. I've

+1

For most use cases, this is a problem that can be handled at another 
layer. Want encrypted transport? Use https. Want password-protected 
files? There are many archive formats that support this.

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 21 Jul 2016 12:07:13 +0200

2016-07-21 0:30 GMT+02:00 Timothy B. Terriberry <[email-masked]>:
> For most use cases, this is a problem that can be handled at another layer.
> Want encrypted transport? Use https. Want password-protected files? There
> are many archive formats that support this.

They are good methods to avoid access although DRM in this case also
ensures the content cannot extracted decrypted.

There's also the case where you download a file on which you will have
rights later. In that case the data in the file should be encrypted
whiled stored.

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 21 Jul 2016 12:32:18 +0200

> ContentEncryption and its children have the same coloring as other level 5

EncryptedBlock is marked as deprecated (greyed) but the Encryption
elements are not. The idea behind the EncryptedBlock elements was that
a player/transcoder that's not encryption aware (currently  all of
them except for web browsers) does not even try to use the payload
data. It seems that WebM doesn't use it but I wonder if that's
something we should bring back.

That element also defines when the (de)lacing happens compared to the
decryption step. The definition is not very clear (even to me) but I
think the encryption is done after the laced frames are assembled
together in memory. In the case of WebM the specs mention lacing is
not supported. Does that mean that audio is not encrypted or you use a
block per Vorbis/Opus frame ? That would be a huge container overhead
as they tend to have very small frames.

---

From: Moritz Bunkus <[email-masked]>
Date: Thu, 21 Jul 2016 13:04:14 +0200

Hey,

> elements are not.

Damn, you're right! I was actually looking at the _signature_ elements
(SignatureSlot and children) and wrongfully concluded that encryption
support was also deprecated without actually verifying that assumption.

I'm truly sorry for the confusion.

Michael's suggestion was to adopt the WebM encryption elements from this
point forward (and hopefully try to keep them in sync in the
future). I'm OK with that.

Kind regards,
mosu

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 21 Jul 2016 05:31:25 -0700

> ensures the content cannot extracted decrypted.

I was only speaking about "other encryption features" than those 
required for DRM support in WebM.

My personal opinion is that DRM is a user-hostile anti-feature, in spite 
of the fact that my employer ships it, so I'm not going to express 
support for that part of Michael Bradshaw's proposal. I do support the 
part I quoted, because designing good crypto is a lot of hard work, and 
a bunch of people have already done it in other layers.

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 21 Jul 2016 15:12:30 +0200

Le 20/07/2016 à 20:44, Michael Bradshaw a écrit :
> [...]

With the same assumption (do we have real file with Matroska 
encryption?), I am also in favour of removing old encryption features of 
Matroska from the draft for IETF and for only integration of WebM 
encryption elements.