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.