Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA
Path: utzoo!linus!decvax!ucbvax!ucbtopaz!newton2
From: newton2@ucbtopaz.CC.Berkeley.ARPA
Newsgroups: net.audio
Subject: Re: Video descrambling notes - (nf)
Message-ID: <527@ucbtopaz.CC.Berkeley.ARPA>
Date: Mon, 13-Aug-84 02:41:47 EDT
Article-I.D.: ucbtopaz.527
Posted: Mon Aug 13 02:41:47 1984
Date-Received: Tue, 14-Aug-84 19:23:26 EDT
References: <18500034@uiucuxc.UUCP>
Organization: Univ. of Calif., Berkeley CA USA
Lines: 19

Regarding the problem of real-time highspeed DES encryption of digitized
audio in the MA/com linkabit HBO scrambler: I doubt that the actual audio
bitstream is DES-encrypted in real time; more likely a seed for a family of
scramble tables is transmitted under DES, this key is decrypted at leisure
giving information needed to set up the receiver to correctly transpose the
bits. This just requires slightly faster than realtime cpu instruction
cycles (I mean faster than the audio bit rate); incoming bits are buffered
and read out in the correct sequence  by consulting the table. New tables
can be sent as often as reasonable to spoil the fun for anyone who finally 
cracks a fewe seconds of audio.

I don't know for sure that this is what's being done, but it's what *I* would
do- and have done on projects for clients whose needs are similar to HBO's.

I think the video line transposition works the same way- each frame might
have a different transposition vector, as it were. I agree with you that there'sa lot of redundancy in most images that might be a chink in the armor, but
many systems propose transposing segments of each line as well (or instead).
And realtime autocorrelation among 525 lines of video is a little beyond
the resources of the vendors of pirate TVRO's, methinks.