Secure Phone Progress (fwd)
Path: news.delphi.com!noc.near.net!howland.reston.ans.net!math.ohio-state.edu!caen!usenet.cis.ufl.edu!usenet.ufl.edu!travis.csd.harris.com!amber!tom From: tom@ssd.csd.harris.com (Tom Horsley) Newsgroups: sci.crypt,talk.politics.crypto Subject: New IBM soundcard and secure phones Date: 28 Oct 1993 11:55:54 GMT Organization: Harris Computer Systems Division Lines: 24 Message-ID: <TOM.93Oct28075554@amber.ssd.csd.harris.com> NNTP-Posting-Host: amber.ssd.csd.harris.com Xref: news.delphi.com sci.crypt:13815 talk.politics.crypto:983
Over in the comp.sys.ibm.pc.soundcard group there have been a couple of brief mentions of the new "Windsurfer" card from IBM. It apparently incorporates a couple of DSP chips, a 14.4K modem, a soundblaster emulator, general midi, kitchen sink, etc :-). I don't know if these DSP chips will be user programmable or not, but if so, this sounds like the one board you need to build your very own secure phone. The 14.4K modem for sending the data, the DSP chips for audio compression, and the sound board for digitizing speach and playing it back. Throw in a little private key exchange via RSA or equivalent at the start of the connection, and use triple DES or IDEA on the data (of course, the person at the other end needs the same setup). Does anyone have any more details on this board (like, will it be user programmable, and will the specs be available for less than your firstborn child :-)? -- ====================================================================== domain: tahorsley@csd.harris.com USMail: Tom Horsley +=============================================+511 Kingbird Circle Don't have awk? Use this simple sh emulation: |Delray Beach, FL 33444 #!/bin/sh +======================+ echo 'Awk bailing out!' exit 2
mikeingl@news.delphi.com (MIKEINGLE@DELPHI.COM) wrote:
Over in the comp.sys.ibm.pc.soundcard group there have been a couple of brief mentions of the new "Windsurfer" card from IBM. It apparently incorporates a couple of DSP chips, a 14.4K modem, a soundblaster emulator, general midi, kitchen sink, etc :-).
I don't know if these DSP chips will be user programmable or not, but if so, this sounds like the one board you need to build your very own secure phone. The 14.4K modem for sending the data, the DSP chips for audio compression, and the sound board for digitizing speach and playing it back. Throw in a little private key exchange via RSA or equivalent at the start of the connection, and use triple DES or IDEA on the data (of course, the person at the other end needs the same setup).
Um... Well, you should be able to do that with an ordinary sound board/digitizer and a modem. However, 14400 bps (without compression) isn't enough to transmit sound waves at normal frequencies. Since the range of human hearing is up to about 20000 hz, you need a sampling rate of 40000hz to get at least a crude sample of all possible frequencies. (Most telecom equipment uses 64000 bps to transmit voice conversations.) But that's where compression comes in. You could probably do without the DSPs and just use the main CPU to do it. Since sound data would be coming in at 40000-60000 bytes/sec (or bits/sec or...?) and output would be going out at 1440 bytes/sec and your cpu can do several million instructions per second, you have several hundred to several thousand cycles to process the data, which should be sufficient time. (I assume you would write this in assembly.) The only real problem is to design a compression technique which can squeeze that much data into a 14400bps connection without losing too much sound quality, which would have to be a pretty good compression technique. It would probably be easier if you had one of those 28800 bps modems that are supposed to be out soon... As for the encryption part of it, If CPU load became a problem, you wouldn't really need to use Triple-DES or IDEA, you could use something simpler. Remember that breaking a cypher requires they you have some idea as to what your looking for so you know you've cracked it. Compressing the data would remove such identifing data and make breaking the code more difficult. Also, if you had the system reset itself during dead time (no sound) or whenever it encountered line noise or whatever by generating a new encryption key and doing a key exchange with RSA, then even if someone broke the code, they wouldn't get much of a prize - just a few seconds of your conversation, which would likely tell them very little.
Matt, There are a few flaws in your statements. You are correct that human hearing is up to 20 kHz, and again with the 40 kHz sampling (this is why CD is 44.1 kHz, to be able to fully obtain a 40 kHz sample with non-ideal filters). However, we are talking about Secure Phones. Phones have a dynamic range of 3.6 kHz, with a sampling of 8000 samples/sec! Also, the phone uses 8-bit mu-law data, for the 64000 bits/sec that you commonly hear. So, without compression, you need a 64 Kbps link to transmit phone-quality audio. The problem with a Secure Phone is getting the data compression to reduce the data to below 14.4 Kbps, in order to use a 14.4 Kbps modem. You need a real-time compression to do this, which is where the DSP chips come in! The encryption isn't a problem, as most encryption algorithms can easily do 64 Kbps! -derek Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Secretary, MIT Student Information Processing Board (SIPB) PGP key available from pgp-public-keys@pgp.mit.edu warlord@MIT.EDU PP-ASEL N1NWH
Well, keep in mind that the phone doesn't transmit nearly all of the spectrum of hearing. In fact it doesn't transmit anything above about 3.5KHz, so you don't have to have enough bandwidth for the human 20Khz hearing range if all you're doing is emulating today's voice phone technology. This, btw, is why it's hard to identify speakers over the phone even in a noise-free transmission -- the acoustical signal is just plain impoverished. --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex@media.mit.edu Voice: 617-258-9168, Pager: 617-945-1842 PUBLIC KEY available by request Try not to have a good time ... This is supposed to be educational.
participants (4)
-
Alan (Gesture Man) Wexelblat -
Derek Atkins -
Matthew J Ghio -
mikeingl@news.delphi.com