home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / crypt / 4436 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.8 KB  |  58 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!uw-beaver!uw-coco!nwnexus!ken
  3. From: ken@halcyon.com (Ken Pizzini)
  4. Subject: Re: Encrypted phones, keys, taps, ...
  5. Message-ID: <1992Nov7.150423.26670@nwnexus.WA.COM>
  6. Sender: sso@nwnexus.WA.COM (System Security Officer)
  7. Organization: The 23:00 News and Mail Service
  8. References: <1992Nov6.012330.4470@shearson.com> <1992Nov7.045122.15675@netcom.com>
  9. Date: Sat, 7 Nov 1992 15:04:23 GMT
  10. Lines: 46
  11.  
  12. In article <1992Nov7.045122.15675@netcom.com> rcain@netcom.com (Robert Cain) writes:
  13. >pmetzger@snark.shearson.com (Perry E. Metzger) writes:
  14. >: 
  15. >: If "standard" means analog, well, analog phone scramblers are almost
  16. >: all easily broken, and are pretty poor in general. Why use one when
  17. >: digital techniques that are virtually unbreakable are available?
  18. >
  19. >How is this done in the case of randomly hopping variable split band
  20. >spectrum inverters?  Current technology allows hopping between any of
  21. >32 frequency split points at a 60 hz hopping rate.  From 16.67 ms
  22. >fragments how on earth does one gather any information as to its
  23. >content or split point?
  24.  
  25. Well, first the disclaimer: Metzger did say "almost all" and "in general".
  26.  
  27. >                         According to Micheal Washvill a voice and
  28. >data security specialist with a "federal agency":
  29. >
  30. >    VSB scrambling can be broken but not in real time. The only
  31. >    practical attack is through trial and error.  The scrambled
  32. >    speech must first be recorded, then divided into finite time
  33. >    segments according to the hop rate.  Each segment is processed
  34. >    through a variety of split points until clear speech results."
  35. >
  36. >He claims a 60 to one decode time.  Gimme a break!  Who decides when
  37. >clear speech results?  Automatic speech recognition is nowhere near
  38. >capable of this which leaves a human to determine what is clear
  39. >speech.  Think of the combinatorics here to decide on a second!  Does
  40. >it actually seem reasonable that this could be done in finite human
  41. >time or is this guy blowing self serving smoke to discourage its use?
  42. >
  43. >Or are there more sophisticated methods?  I have some experience in
  44. >signal processing and in speech recognition and certainly can't think
  45. >of one.  I've seen the statement that it is easy but I'd sure like to
  46. >see that backed up with an algorithm.
  47.  
  48. If indeed "the only practical attack is through trial and error", then
  49. I agree that this is a pretty secure method.  But what is the random
  50. number generator chosing the splits?  If this is not cryptographically
  51. strong then there is a nice weakness to exploit.  And keep in mind that
  52. to crypto folk a scheme is usually considered insecure if there is a
  53. way to break the code (or protocol, or whatever) that is cheaper than
  54. brute-force trial-and-error; "finite human time" isn't usually the metric
  55. used.
  56.  
  57.         --Ken Pizzini
  58.