Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Qualcomm Incorporated (QCOM) -- Ignore unavailable to you. Want to Upgrade?

To: Ramus who wrote (24592)	3/21/1999 11:27:00 PM
From: Ingenious	Read Replies (1) \| Respond to of 152472

It has been awhile that I read the IS-95 spec. but the randomization aspect and the 'seed' used to start the whole process keeps everyone "guessing" long enough to prevent decryption. That is, even if the general method is known, there are no computers fast enough to decrypt the information. To make things more difficult, the seed can be provided by the base station, the electronic id of the phone, or a combination of the both. If both the EID and the randomized base station numbers are used, one can quickly see how the whole system would be difficult to decrypt. Oh yeah, don't forget that the information is randomly spread throughout the wide band frequency. Though a feature used primarily to prevent jamming, spread spectrum does a number on those trying to determine which bit to put first and which to put last. Essentially, yet another barrier to decryption. NB: public-key encryption is a publicly known method of encryption but the length of the keys keep the information private. Unlike systems of past, the key is what keeps things private and not the method of jumbling the information up. CDMA is like this since the method used in IS-95 must be well known but the length and variation of the keys keeps people guessing. Also, it is interesting to note that the functions used in public-key encryption are one-way or not reversible. Once you encrypt data using a public key, you can not reverse the steps to decrypt. Instead, you must perform another process with a person's private key. Of course, since the private key is truly unknown, only the recepient of the data can decrypt.

To: Ramus who wrote (24592)	3/22/1999 12:01:00 AM
From: Clarksterh	Read Replies (1) \| Respond to of 152472

Walt - The long code itself is a PN sequence generator polynomial of length 2^42-1 bits. The mask is a sequence of 42 bits that are XOR'd with this PN sequence creating a new sequence. First, a disclaimer having read back through this thread and my various posts on this subject. Originally I started out discussing CDMA in CineComm, on which I was/am pretty confident, and gradually we have moved to eavesdropping and cloning on which I was confident but am now considerably less confident (I did some more research). That being said, you and I are saying the same thing - the XORing of the PRN generator is the same as a time shift of the generator. This is done to prevent two handsets from producing the same 'code' sequence at the same time and interfering with one another. It also has the effect of making it harder to lock onto the Reverse link if you don't know the time shift (you have to search through the various times although it should be noted that this is not an issue with the forward link which, if I remember correctly, does not use the long code although surprisingly my books conflict on this.). My mistake in earlier posts was that I assumed that there were quick ways to lock up to this long code even without knowing the time offset (I've worked with such PRN codes), but in this case I now believe this to be wrong. The implication of this is that it is probably not as easy to listen to the reverse link in real-time as I thought without a lot of computing power (somewhat like decrypting a 42 bit code in real-time). I need to think more on how long it would take with how many MIPS, but it should be noted that 42 bits is not that many by modern encryption standards. Clark PS Note that if the forward link does not use the long code (I have to find another spec to decide between conflicting specs), the forward link will be considerably easier to scan than the reverse link.