W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Encrypted Media proposal: Summary of the discussion so far

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 9 Mar 2012 17:19:55 -0600
Message-Id: <4C9FBBB5-0320-43DD-B08A-2DE8A80C4D41@jumis.com>
Cc: "public-html@w3.org" <public-html@w3.org>
To: Kornel Lesiński <kornel@geekhood.net>
On Mar 9, 2012, at 12:56 PM, Kornel Lesiński <kornel@geekhood.net> wrote:

> On Fri, 09 Mar 2012 18:09:10 -0000, Charles Pritchard <chuck@jumis.com> wrote:
> 
>> It fulfills the requirements that content vendors place on distribution by obfuscating the file stream. A user can not simply download the file and then view it in a media player. It obfuscates the stream over wireless so apps like Firesheep can not simply snoop the video automatically.
> 
> Firesheep-like tools could do that. Masking key is sent in the clear in the frames themselves. Even if the masking key was somehow hidden, it's just a 32-bit value XORed with the data, so a few bytes of known plaintext or relatively small amount of brute-force can be used to recover the key.
> 
> So I think websocket framing format is not appropriate for securing files stored with untrusted CDNs


I did not cite that as the use case. Yes, JS can be reverse engineered. If you want a file on an untrusted CDN, encrypt it and send the secure key through other means.
> 

That's what the "enc:*" prefix and aes, chacha keysystems provide for.

A baseline CDN with websockets is not intended for security, only obfuscation to meet the two needs I mentioned.
Received on Friday, 9 March 2012 23:20:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT