This is all wishful thinking. A 26-MHz wide channel such as 902-928MHz has a channel capacity of 2*26 Mbs or 6.5 megabytes/sec. So if someone
That is not what Mr Shannon says, Shannon's law relates date rate, bandwidth and signal to noise ratio - the "channel capacity" of 26 mhz of spectrum is determined by the signal to noise ratio in the 26 mhz channel and ranges from much less than 26 mbs to several times that rate depending on the signal to noise ratio (and of course how clever the modulation technology is at exploiting it). Witness a 28.8 kb modem which stuffs 28.8 kb into less than 3.2 khz given about 32 db gross SNR. But more significant to the predection recording technique you are talking about is how many samples a second it takes to reproduce information in the 26 mhz bandwidth. Crudely, as a rule of thumb the Nyquist criterion would suggest that you need to sample at twice the highest frequency (or 26 mhz if you downtranslate to DC). This means 52 megasamples per second. Now depending on how much junk there is in the 902-928 mhz band at the location of interest and how far below the other signals the signal of interest is, you might be able to get away with 8 bit samples (providing about 35 db dynamic range) but would probably need more bits than that for things to work reliably. Say 12 bits (72 Mbytes sec) or 16 bits (104 Mbytes/sec), Yes, perhaps compression could buy you back some of that, but you are still realisticlly talking about recording somewhere between maybe 20 and 100 Mbytes/sec. The low end of this range is about the upper limit of present day high performance disk system bandwidth. So you are not talking about a simple configuration with off the shelf disks and controllers (unless you run several in parallel). And one minute of audio gobbles up way more than a gigabyte, or less than 2 minutes per $K of disk cost. And that assumes some compression.
can tell *that* you are transmitting somewhere within that channel then they simply record *everything* at that data rate in the entire channel, your transmission and everyone else's, for the necessary time. A $600 3.5Gb Sequel drive can record a ten-minute transmission; then the eavesdropper can use one Pentium or two dozen, budget permitting, to extract your message from that data. If all you are doing is frequency hopping or spread spectrum, reconstruction is a very undemanding algorithmic task, and one Pentium should be able to reconstruct your signal the same day, two dozen the same hour.
I will agree that such techniques can be used, and am well aware that they have been used for the last 25 or so years by the NSA and other like organizations for handling this kind of problem (originally in the HF radio spectrum for finding and reading covert burst transmissions - at least so I have heard).
But to get back to the original point of this thread - while such techniques are possible (as is full hard encryption), it is my understanding that actual conusmer 900 mhz digital cordless phones that use frequency hopping use a very limited set of frequencies and a small set of fixed hopping patterns and don't hop very fast.
Hopping speed is almost completely irrelevant to the computational complexity of this problem.
I agree in general, though the degenerate case of very slow hopping permits of some simplifications and speedups since demodulating bits between hops can be done with less computation per sample than estimating where the next hop frequency is when it is unknown. And a phone that slowly hops in a fixed simple pattern onto a small number of channels can be demodulated by very simple approaches indeed, including much less sophisticated and costly ones than fast DSP of wideband sampled channels.
You can never overestimate the cost of decryption. What looks expensive enough today to decrypt can plummet by orders of magnitude on alarmingly short notice. We used to think TCP was mildly secure until easily installed sniffers became freely available on the internet that would reconstruct a telnet connection and print out the first 100 characters, making it child's play to extract passwords.
I must say that I was not amoung those who ever thought that TCP was secure, perhaps because I have spent too much time looking at packet dumps from protocol analyzers and bus traffic on logic analyzers. And even the oldest and slowest systems could reconstruct TCP - it was not a leap of system technology at all, but a leap of hacker application skills and awareness. I hate to even whisper the other places in the fragile web of our infrastructure that are vulnerable to intelligent attack ... there are many unexploited holes left even as we plug some of the obvious ones. The good thing is that people are begining to think about them.
If you think that you are secure because the effort of an attack seems on the high side, bear in mind that the tasks in a systematic attack can by definition of "systematic" be programmed, greatly easing the attacker's task. And once programmed, the program can be distributed to all and sundry on the internet.
That I agree with and think the current rash of sophisticated hacker tools in the hands of relatively unsophisticated kids who could in no way have created them proves your point well.
If a given level of cryptographic strength seems adequate for a message, add several orders of magnitude and maybe you'll be lucky.
I wouldn't consider hopping or spread spectrum cryptography. Historically they have been viewed as techniques for avoiding jamming and interference and sometimes also for making signals harder to find rather than as information security techniques. Their use in cordless phones is primarily to aviod interference from other users of the 902-928 band and not for security.
I know of only two really satisfactory places to hide information worth hiding: combinatorial search space (read: real encryption such as DES or RSA, with a hefty key),
I think we all agree that security by obscurity is not real security at all. But even the security of mathematical crypto is mostly unproven as of yet - we merely think things are difficult to compute because we don't know an easy way to do it, not because there is a clear proof that is true. Dave Emery