home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / security / misc / 1648 < prev    next >
Encoding:
Internet Message Format  |  1992-11-05  |  1.9 KB
  1. Path: sparky!uunet!gumby!destroyer!cs.ubc.ca!unbc.edu!lyndon
  2. From: lyndon@unbc.edu (Lyndon Nerenberg)
  3. Newsgroups: comp.security.misc
  4. Subject: Re: NEED GENERAL INFORMATION ON WIRELESS LANS
  5. Summary: Just some clarification ...
  6. Message-ID: <356@unbc.edu>
  7. Date: 5 Nov 92 17:42:57 GMT
  8. References: <jenn_b.5@aci_1.aci.ns.ca> <1992Nov4.112621.2790@lut.ac.uk>
  9. Organization: University of Northern B.C.
  10. Lines: 30
  11.  
  12. jon_care@hicom.lut.ac.uk writes:
  13.  
  14. > 1) Wireless LANS, at frequencies below 10GHz, are easy to monitor relatively
  15. > cheaply. (At the 10Ghz range, one has to intercept the path of the microwave
  16. > signal).
  17.  
  18. Yes and no. There are LANs operating at 23 GHz that transmit an omni-directional
  19. signal. As you increase frequency it is easier to narrow the beamwidth of a
  20. point-to-point link, however a wireless LAN by definition wants wide area
  21. coverage, not PTP. Even fixed PTP links are easy to intercept.
  22.  
  23. > Commercial receivers are available that will happily monitor any frewuency
  24. > up to about 950 Mhz - If a TNC (with modem chip set for the correct baud rate)
  25. > is then connected in to a PC, packets received can be decoded and analysed
  26. > very easily.
  27.  
  28. Well, sort of. This isn't your basic 1200 bps AX.25 packet radio that you find
  29. on 145.01. The 900 MHz systems all run spread spectrum. To intercept a signal
  30. you require the same brand of LAN transciever (or at least one that uses the
  31. same modulation encoding scheme), and you must then determine which particular
  32. spreading code is being used. The former is relatively easy due to the limited
  33. number of products currently available. The latter can be dealt with using a
  34. brute force approach if you're patient.
  35.  
  36. > An answer to this could be to use some form of publickey encryption.
  37.  
  38. This is the obvious solution, and a good one. I'm curious why more vendors
  39. don't provide this. Is it simply due to the silly DES export restrictions?
  40.  
  41. --lyndon
  42.