Why aren't known-plaintext attacks against digital media trivial ?
(full disclosure: I am not a video/media person at all - I have only a loose understanding of their job and workflow) Let's say I am authoring a video clip for blu-ray. I have a scene transition that goes to solid black. Let's further say that the tool I am using allows me to insert such "screens" and I define them with hex color values ... so I simply say "fill screen with #000000 for 2 seconds". Which essentially turns into a display resulting in 1920x1080 pixels of that hex code. For 30-60 frames per second. Why aren't events like this huge sources of known-plaintext ? Presumably this could occur in any digital medium - programmatic silence in a digital audio clip, or screens/fillers/pages like the one described above in both satellite and cable TV broadcasts (although the blu-ray example is easier to deal with, since you're not dealing with noise/errors/etc.)
On Thu, 2009-10-08 at 05:39 +0000, John Case wrote:
Let's say I am authoring a video clip for blu-ray. I have a scene transition that goes to solid black. Let's further say that the tool I am using allows me to insert such "screens" and I define them with hex color values ... so I simply say "fill screen with #000000 for 2 seconds".
Which essentially turns into a display resulting in 1920x1080 pixels of that hex code. For 30-60 frames per second.
Why aren't events like this huge sources of known-plaintext ?
They are. This was how the 40-bit cipher used for DVD's CSS was cracked. With modern 128-bit ciphers it's a lot harder to crack even with known plaintext; the MPAA learned their lesson. -- Shawn K. Quinn <skquinn@speakeasy.net>
On Thu, 8 Oct 2009, Shawn K. Quinn wrote:
On Thu, 2009-10-08 at 05:39 +0000, John Case wrote:
Let's say I am authoring a video clip for blu-ray. I have a scene transition that goes to solid black. Let's further say that the tool I am using allows me to insert such "screens" and I define them with hex color values ... so I simply say "fill screen with #000000 for 2 seconds".
Which essentially turns into a display resulting in 1920x1080 pixels of that hex code. For 30-60 frames per second.
Why aren't events like this huge sources of known-plaintext ?
They are. This was how the 40-bit cipher used for DVD's CSS was cracked. With modern 128-bit ciphers it's a lot harder to crack even with known plaintext; the MPAA learned their lesson.
Thanks. Are there authoring constraints as well ? There is some cost involved in authoring a blu-ray disc, but they're not astronomical. Presumably there is some kind of mechanism to stop someone from authoring and releasing a copy-protected disc with 10 minutes each of black, white, and all the primary colors ? :)
John Case <case@sdf.lonestar.org> writes:
Let's say I am authoring a video clip for blu-ray. I have a scene transition that goes to solid black. Let's further say that the tool I am using allows me to insert such "screens" and I define them with hex color values ... so I simply say "fill screen with #000000 for 2 seconds".
Which essentially turns into a display resulting in 1920x1080 pixels of that hex code. For 30-60 frames per second.
Which after compression turns into a handful of bytes, encoding (initially) "big block of nothing" and then "same as before".
Why aren't events like this huge sources of known-plaintext ?
See above. Peter.
participants (3)
-
John Case -
Peter Gutmann -
Shawn K. Quinn