3

I read that there are different ways to apply visual cryptography. One is to generate two images that when overlapped provide the original image. The main issue of using this approach with a video is that I would need to generate those two images for each frame. Is there a way to generate a single decryption image for the entire video?

In that case such image would act as a symmetric key and so all the encrypted frames could be decrypted with such key.

David
  • 161
  • 1

2 Answers2

4

The simplest form of visual cryptography use transparencies that each individually convey no recognizable information, but reveal a meaningful image when precisely aligned visual cryptography

The basic approach for doing the same with video is using such visual cryptography to encipher each frame. That works, but (as stated in the question) requires generating two images for each frame, and playing these in perfect synchronization. Also, the decoding won't be easy: the eye is good at averaging luminous intensity, and projection on an ordinary screen, even if perfertly superimposed, will lack contrast. Further, lossy video compression (as most video compression schemes are) will tend to prevent decoding.

It is tempting to make the image in one of the two video streams still, which in particular allows decoding with fair contrast simply by projecting on a screen that serves as key. But that's very insecure! What's moving in the original video will be distinguishable to the naked eye; and XORing each frame with the previous one will make that even more apparent: the XOR of two consecutive frame in the ciphertext is also the XOR of two consecutive frame in the plaintext, and is very revealing; in particular, that shows the left and right contour of something moving horizontally.

I see no secure fix.

fgrieu
  • 149,326
  • 13
  • 324
  • 622
2

Is there a way to generate a single decryption image for the entire video?

Only if it's used as an Ersatz password from which a traditional encryption key is derived. All video encryption /DRM is accomplished by encrypting the underlying video stream. In encrypted form, the stream will be a pseudo random stream of bytes and not decode at all.

Your scheme looks like a video version of a stream cipher, but operating on the decoded video frames rather than the raw underlying data. I think that you might be looking at a case of the tail wagging the dog. If your app can't use traditional video DRM, then you need to look at re-architecting your app. Can you find an example of a commercial product that does it your way? Unlikely. And if WebRTC can't perform custom decoding, how would you overlap the two videos and do some type of visual XOR on them? Further, would that mean twice the bandwidth?

There's some contemporary high level stuff here that might help.

SEJPM
  • 46,697
  • 9
  • 103
  • 214
Paul Uszak
  • 15,905
  • 2
  • 32
  • 83