home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / sci / electron / 21192 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.2 KB  |  61 lines
  1. Newsgroups: sci.electronics
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!nagle
  3. From: nagle@netcom.com (John Nagle)
  4. Subject: Re: Secure voice telephony: technical questions
  5. Message-ID: <1992Dec19.193555.16759@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <1992Dec18.201341.1@novax.llnl.gov>
  8. Date: Sat, 19 Dec 1992 19:35:55 GMT
  9. Lines: 50
  10.  
  11. urbina@novax.llnl.gov writes:
  12. >1.) My design right now incorporates a 14 bit serial output ADC. I sample the
  13. >speech at 7khz which is double the bandwidth of telcom speech. The output from
  14. >the ADC is XOR'ed with a 31 stage linear feedback shift register that generates
  15. >several hours of pseudorandom "noise" before it repeats itself. (It's clocked
  16. >at 7khz to give me that long turn-around time.) This encrypted data stream gets
  17. >sent over the telco line (in theory) and the receiving party whose PN generator
  18. >is synced with mine, decodes the encrypted data stream and the remaining voice
  19. >bits are routed to his/her DAC. My question is 7khz too fast for telcom ?
  20. >I've heard of speeds of 9600 baud with modems. Appreciate any help with this.
  21.  
  22.        7kHz times 14 bits = 98,000 bits/second.  This is well beyond
  23. existing modem technology.  The usual telephone standard is 8 bits, and the
  24. D/A isn't linear, it has a psuedo-logarithmic response curve to improve
  25. the dynamic range.  There are standard IC for this, called "codecs".
  26.  
  27.        This still gets you 56Kb, which, in fact, is the rate used in the
  28. digital portions of the telephone system.  But you can't push that through
  29. a modem without some compression.  Most modern cryptosystems compress the
  30. audio down to 9600 or 4800 baud, using linear predictive compression (LPC).
  31. There are ICs for this, too.  Of course, an encrypted ISDN phone would
  32. be much easier; no compression required.  That would be a nice
  33. project.
  34.  
  35.        Then you need to encrypt.  A 31-bit recirculating shift register
  36. is a very weak encryption algorithm.  Ask in sci.crypt for a better one.
  37.  
  38.        You might be able to do the whole job in a DSP chip, including the
  39. modem.  That might be the lowest-cost solution; DSP chips are getting cheaper.
  40.  
  41. >2.) The quick and dirty way I've synced the pseudonoise generators of the
  42. >calling and receiving parties is that I've 2 LM567 tone decoders that monitor
  43. >the telco line for say...the digit 7 (852hz + 1209hz.) When it detects that..
  44.  
  45.         Using a tone decoder to indicate you want to turn the system on
  46. is fine, but you probably won't get precise enough timing from them to
  47. sync to the 100uS required at even 9600 baud.  Better to send some sync
  48. pattern in the digital data stream and sync up on that.
  49.  
  50.         AT&T is now selling a real encrypted phone for around $1300,
  51. based on the STU-III technology.  The problem still seems to requires enough
  52. parts to keep the cost high.
  53.  
  54.         If you're more of an analog person, you might look into Turing's
  55. original analog voice cryptosystem, described in "Turing - the Enigma".
  56. 1940s technology, but considered sound by Turing, who furfils the
  57. criterion set down by Friedman: "No new cryptosystem is worth looking at
  58. unless it was invented by someone who has already broken a very hard one."
  59.  
  60.                     John Nagle
  61.