SAT-Usenet 28/97

from: owner-sat-usenet@tags1.dn.net
Date: Sat, 14 Jun 1997 06:56:55 -0400 (EDT)
SAT-Usenet 
28/97
get the best from Newsgroups via eMail!

This service is sponsored by
TELE-satellite
INTERNATIONAL
http://www.tele-satellite.com

Editor for TS:
Marc Ruenger
eMail: MRuenger@aol.com
http://members.aol.com/mruenger/sat-tv.htm

ALL MATERIAL PROVIDED HERE IS FOR PERSONAL INFORMATION ONLY, AND MAY NOT BE
USED FOR ANY COMERCIAL REASONS, WITHOUT PRIOR PERMISSION FROM THE EDITOR.

ubject: Re: Real time Sky Sat codes
From: myo@nedernet.nl
Date: 24 May 1997 14:00:36 GMT
Message-ID: <3385d377.4021729@news.euro.net>

On Thu, 22 May 1997 21:03:01 +0100, Simon Atkinson <simes@127.0.0.1> wrote:

>In article: <33849904.2781E494@nospam.guildford.ericsson.se>  Paul 
>Sengupta <paul.sengupta@nospam.guildford.ericsson.se> writes:
>
>>Hmmm. At what speed is RealAudio or whatever it's called transmitted?
>>There could be a "RealCode" transmission... :-)

Actually RealAudio relies on the fact that audio can be compressed. The
8-byte
seed cannot be compressed because the numbers have been 'designed' to be
random
(in order not to give any tips to hackers regarding the algorithm used if one
had many 0x74 packets and matching 0x78 packets to compare). But the amount
of
data is not the issue here, it's the delays between sending and receiving the
information.

>>And ok, the data is at 9600bps going in and out of the card, but
>>doesn't a clear transmission last 4 or 5 seconds...? So where in
>>this time are the new codes sent to the card, ie. how long can the
>>delay be between the request being transmitted to the card and
>>the picture going scrambled?
>
>I seem to remember (!) that the maximum delay between the decoder 
>sending the seed and the reply from the card without a period of 
>scrambling was about 0.5 of a second.  This is repeated every 2.5 
>seconds.  I guess the 'over the net' solution may work locally,  but I 
>can't see it working across Europe.

Yes, we have to remember that it's not the receival of the 0x74 packet which
counts, but the actual 0x78 packet. 

>The data therefore has to be sent every 2.5 secs and has to be sent 
>quickly - with little time for PPP retransmissions,  time outs,  server 
>errors etc.
>
>maybe worth a try one fine day - it could be done by modifying an IRC 
>prog and using IRC to 'transmit' the card reply to the various viewers.

Agreed, would be a very nice thing to try just for the fun of it. I guess it
would also be a fairly simple task to make a program which could do this.
Although the decoder-card traffic is 9600bps, the actual transmission from
VideoCrypt-server to VideoCrypt-client would only consist of 8 bytes every
2.5
seconds. The problem is getting across those bytes in the very short time
frame.
I guess when phone costs drop even more (or become free for local calls) and
the
time thing is solved this could work very well. VideoCrypt would be a prime
candidate for such a test. The decoder doesn't need any authentication at
all,
every card works on every decoder. All it'll need from the server is the
60-bit
seed every 2.5 secs. Perhaps 2 persons who live in the same neighbourhood and
have accounts with the same ISP could try it out.

Regards,
Mijo.

---
Mijo Saftic                        VCL Central - http://www.nedernet.nl/~myo
myo@nedernet.nl                          PGP public key available on request




#####

For information on how to subscribe or unsubscribe, send email to
Majordomo@tags1.dn.net (_not_ to me, please) and include the line
help
in the body of your message.
[Other mailing lists]