Re: OT --US Military Drone Video Feeds Will Not Be Encrypted Until At Least 2014



miso@xxxxxxxxx wrote:
I seriously doubt you could do OTP for video. Think of direct sequence
spread spectrum communications. The hardest part is getting

Spread spectrum works by sending each and every bit many times, our common favorite the gps sats does this 1023 times. Each sat has a unique sequence of those 1023 bits. If you want to use DSSS as an encryption technique then your spreading code becomes your encryption key, but with the limitation that an aggressor don't need to determine all of the bits in order to decode the signal, just a large majority of them.

syncronized. With OTP, getting synchronized would be difficult. You
would have to insert some sort of non-encoded framing bits with data
to indicate where in that huge code you should be.

How do you think HDMI links can support encryption of all the Blueray videos you are watching?

Of course there are framing bits which are known, and can be used to synchronize with the stream, that is both perfectly OK and as designed!

You encrypt the payload, not the envelope surrounding it.

Using DSSS is mostly orthogonal to this.

The encryption doesn't have to be that strong, just better than what
they do now. The last thing you want is to lock something down so
tight that it might not be functional when you need it.

For drone data there are two scenarios:

Tactical (war theater) security, which only needs to be good enough to keep things secure for some hours to days, and

Forward security: Often you would not like an enemy to be able to capture the encrypted stream and then some time in the future become able to decode it and work out exactly what you were looking at, this requires orders of magnitude stronger encryption.

Using something like AES256 with a per-session unique key would ensure this.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
.