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.

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.

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