Re: Fwd: Re: Fwd: Re: FH radios [Dave Emery] [Vaughan Pratt]

["Dave Emery" <die@pig.die.com>]

> 
> 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