From: Matthew J Ghio <mg5n+@andrew.cmu.edu>
To: cypherpunks@toad.com
Message Hash: 02d9afcee0f1e04da4924fc0d1d295155177c3093e4906b331c115f4a30333bc
Message ID: <0gp7NE600awUQ5lkYP@andrew.cmu.edu>
Reply To: <9310312142.AA28209@news.delphi.com>
UTC Datetime: 1993-11-01 02:39:39 UTC
Raw Date: Sun, 31 Oct 93 18:39:39 PST
From: Matthew J Ghio <mg5n+@andrew.cmu.edu>
Date: Sun, 31 Oct 93 18:39:39 PST
To: cypherpunks@toad.com
Subject: Re: Secure Phone Progress (fwd)
In-Reply-To: <9310312142.AA28209@news.delphi.com>
Message-ID: <0gp7NE600awUQ5lkYP@andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain
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.
Return to November 1993
Return to “mikeingl@news.delphi.com (MIKEINGLE@DELPHI.COM)”