From: Michael S. Lorrey (mike@datamann.com)
Date: Mon Apr 03 2000 - 08:11:56 MDT
Robert Bradbury wrote:
> I would think that it is feasible to produce an integrated
> camera/transmitter (in fact I think they already have these).
> The outgoing video should be time sequenced and encrypted.
> If it is tightly enough integrated with some self-checks for
> things like changes in impedances, you aren't going to be able
> to "hack-in" and divert the transmitter video feed. If the
> outgoing data sequence is time-stamp encoded, you aren't going
> to switch the feed to a different video unit.
>
> If people can make secure electronic transactions, they ought
> to be able to make secure video feeds (after all, it only has
> to go one way, while electronic transactions have to go in
> both directions).
If you can put all that data into the video feed easily, then it can easily be
counterfeited. Video feeds carry a lot of data, a lot of bandwidth. The security
of any encrypted message is directly proportional to the size of the message.
The larger the message, the easier it is to break the encryption. Encrypted
financial transactions consist of packeted records that are typically less than
a few thousand characters in length, optimally less than 400 characters. To gain
the same level of security for a hundred megabyte per minute video feed as you
do for 400 characters encrypted at a 60 bit encryption level, you'd need
something along the lines of 10,000-50,000 bit encryption on the video feed.
This high a level of encryption requires significant processing, and time to
process. You won't get anything near real-time video feeds, which will allow
sufficient lag for splicing in counterfeited data, artificial time stamping, as
well as outright destruction of the camera while it is processing video, so the
home station will never see who destroys the camera because that footage was
still being processed on the camera.
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:27:49 MST