I forwarded an old posting about CELP speech compression:

In case you'd like to experiment with CELP, you can obtain a software
implementation of the 4800 bps Fed Std CELP coder for free:

The U.S. DoD's Federal-Standard-1016 based 4800 bps code excited linear
prediction voice coder version 3.2 (CELP 3.2) Fortran and C simulation source
codes are now available for worldwide distribution at no charge (on DOS
diskettes, but configured to compile on Sun SPARC stations) from:

I've since been told that the source of this is on cygnus.com
in /pub/celp.speech.tar.Z

I'm not in a position to; any Sun tcp/ip gurus out there who think they
can marry this with netfone by the end of the week? ;-) Seriously. I
think someone with real net access and two sparcs could have this running
by the end of the week. Then we ask the pgp guys to add a bytestream
crypto filter. Two weeks at the most. [Damn, I wish I had my sparc
back... I'm stuck on a 25mhz 386sx]


Share and Enjoy!

G
PS You'll have to use archie to find netfone - I have a copy but no note
of where it's from; author in the docs is kelvin@autodesk.com and he
appears to be located in France

From: hal@cco.caltech.edu (Hal Finney)
Newsgroups: sci.crypt
Subject: Re: Let's build software cryptophones for over the internet...
Date: 25 Apr 1993 17:12:32 GMT
NNTP-Posting-Host: alumni.caltech.edu

gtoal@gtoal.com (Graham Toal) writes:

>I forwarded an old posting about CELP speech compression:
>[...]
>I've since been told that the source of this is on cygnus.com
>in /pub/celp.speech.tar.Z

>I'm not in a position to; any Sun tcp/ip gurus out there who think they
>can marry this with netfone by the end of the week? ;-) Seriously. I
>think someone with real net access and two sparcs could have this running
>by the end of the week. Then we ask the pgp guys to add a bytestream
>crypto filter. Two weeks at the most. [Damn, I wish I had my sparc
>back... I'm stuck on a 25mhz 386sx]

I tried this code yesterday. On my Sparcstation ELC it takes over
300 seconds to compress 22 seconds' worth of speech. This means that it
needs to be "optimized" by over a factor of 10 before it will be usable
in even a half-duplex mode.

I question whether CELP is the best approach for this application. It produces
great compression but at the expense of tremendous CPU loads. We want
something that can be run on ordinary workstations or even high-end PC's
without DSP cards. My guess is that some other algorithm is going to be
a better starting point.

Hal Finney

Newsgroups: sci.crypt
From: Graham Toal <gtoal@gtoal.com>
Subject: Re: Let's build software cryptophones for over the internet...
Reply-To: Graham Toal <gtoal@gtoal.com>
Date: Sun, 25 Apr 1993 20:01:12 GMT

In article <1regq0INNn7u@gap.caltech.edu> hal@cco.caltech.edu (Hal Finney) writes:
:I tried this code yesterday. On my Sparcstation ELC it takes over
:300 seconds to compress 22 seconds' worth of speech. This means that it
:needs to be "optimized" by over a factor of 10 before it will be usable
:in even a half-duplex mode.

Ouch! Thanks for trying it.

:I question whether CELP is the best approach for this application. It produces
:great compression but at the expense of tremendous CPU loads. We want
:something that can be run on ordinary workstations or even high-end PC's
:without DSP cards. My guess is that some other algorithm is going to be
:a better starting point.

Yes. I'm not sure if my xposting to comp.speech made it to here too, but
I've found that a low sample rate (3300 samples/sec at 8 bits per sample)
plus the pd 'shorten' lossless sound compression code actually does get
speech into 14.4K with a simdgen left over. This is *definitely* worth
working on, folks. And shorten works in well under real-time.

G

From: mjr@tis.com (Marcus J Ranum)
Newsgroups: sci.crypt
Subject: Re: Let's build software cryptophones for over the internet...
Date: 25 Apr 1993 21:34:20 GMT
NNTP-Posting-Host: sol.tis.com

Graham Toal <gtoal@gtoal.com> writes:
>Yes. I'm not sure if my xposting to comp.speech made it to here too, but
>I've found that a low sample rate (3300 samples/sec at 8 bits per sample)
>plus the pd 'shorten' lossless sound compression code actually does get
>speech into 14.4K with a simdgen left over. This is *definitely* worth
>working on, folks. And shorten works in well under real-time.

I don't think that this should be worked on just in the context
of cryptography. That's sure to pose all sorts of problems for all sorts
of people.

What's needed is for someone to develop a portable telephone
quality speech<->RS232 converter. Imagine, if you will, a little box that
takes data on its serial port and puts out sound, and takes sound and codes
it to signals on its serial port. Full duplex. Now, this device is not a
cryptographic device. It's a portable poor man's sound blaster or whatever
you want to call it. It's got loads of perfectly legitimate applications
for:
a) speech synthesis (with a few nifty libraries and some samples)
b) speech recording for electronic messaging
c) building voicemail systems
d) internet talk radio
e) internet relay chat

Of course, some of the electronic messaging in item b might be
encrypted, possibly realtime, but that's the user's decision. One would
need 2 of these talky boxes and a pair of modems and some kind of cutout
to switch over, and some code on, say, a 486 laptop.

I'd really like to see such a thing developed so that interactive
internet talk radio could be done. Ideally, though, it should be a general
purpose device. It should be a general purpose enough device that nobody
should be able to balk at its widespread use. Obviously, to make it easy
for homebrewers, it should use pretty common hardware.

It's interesting to note that I'd already talked with a couple
of folks about building such a thing, before this whole clipper thing
started. I even went so far as to track down a couple of folks who are
able to make sample units, given incentive and some time. I'd envisioned
finding a couple of folks interested in such a project and helping fund
development of a public domain board layout and parts set, that could
be published in the form of CAD drawings for a couple of major CAD
packages, and in PostScript.

Anyone interested? I'll start a provisional mailing list. Let
me know if you want on.

mjr.

From: Greg.Onufer@Eng.Sun.COM (Greg Onufer)
Newsgroups: sci.crypt
Subject: Re: Let's build software cryptophones for over the internet...
Date: 25 Apr 1993 23:26:14 GMT
Distribution: usa
NNTP-Posting-Host: cheers

In <C622A1.7t6@demon.co.uk> Graham Toal <gtoal@gtoal.com> writes:
>In article <1regq0INNn7u@gap.caltech.edu> hal@cco.caltech.edu (Hal Finney) writes:
>:I tried this code yesterday. On my Sparcstation ELC it takes over
>:300 seconds to compress 22 seconds' worth of speech. This means that it
>:needs to be "optimized" by over a factor of 10 before it will be usable
>:in even a half-duplex mode.

>Ouch! Thanks for trying it.

The following program is a very quick hack I created a few months
ago to determine whether a Sun Sparcstation IPC could perform
real-time, full-duplex encrypted audio with resulting data rates
sustainable by today's modems.

This test program reads linearly-encoded audio from the audio device,
compresses it with GSM 06.10 (compresses frames of 160 13-bit samples
recorded at 8kHz into 260 bits resulting in a 50 Hz frame rate), encrypts
it with DES, then reverses the process and sends the reconstructed audio
back to the audio device. The compressed, encrypted audio stream
is 13 kbits/s (!).

My Sparcstation IPC (not exactly a very fast machine these days,
certainly slower than an ELC) would just barely sustain this activity
(audio underruns would occcur but the speech was very intelligible). I
ran it as a real-time process to get the best results. Remember,
though, that this program is a quick hack and the performance can
certainly be improved.

The audio compression routines can be ftp'd from tub.cs.tu-berlin.de,
I believe (look for gsm or toast). I used Eric Young's DES
implementation but I no longer know where I got it from.

Cheers!greg

<--------------------------- CUT HERE ----------------------------->
/*
* Test program to see how much CPU it takes for secure digital audio.
* Written by G. Onufer (greg@cheers.Bungi.COM).
*
* Written on a Sun IPC running Solaris 2.2 with a Sun ISDN S-Bus card
* and a SpeakerBox.
*/
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/audioio.h>
#include <stropts.h>

#include <gsm.h>
#include <des.h>

boolean_t
svs_audio_init(int fd, audio_info_t *prev_info)
{
audio_info_t info;

if (prev_info != NULL) {
if (ioctl(fd, AUDIO_GETINFO, prev_info) < 0) {
perror("AUDIO_GETINFO");
return (B_FALSE);
}
}

AUDIO_INITINFO(&info);

info.record.pause = B_TRUE;
info.play.pause = B_TRUE;

info.play.sample_rate = 8000;
info.play.encoding = AUDIO_ENCODING_LINEAR;
info.play.channels = 1;
info.play.precision = 16;
info.record.sample_rate = 8000;
info.record.encoding = AUDIO_ENCODING_LINEAR;
info.record.channels = 1;
info.record.precision = 16;

info.record.buffer_size = 320 * 4;

if (ioctl(fd, AUDIO_SETINFO, &info) < 0) {
perror("AUDIO_SETINFO");
return (B_FALSE);
}

if (ioctl(fd, I_FLUSH, FLUSHRW) < 0) {
perror("I_FLUSH");
return (B_FALSE);
}


AUDIO_INITINFO(&info);

info.record.pause = B_FALSE;
info.play.pause = B_FALSE;

if (ioctl(fd, AUDIO_SETINFO, &info) < 0) {
perror("AUDIO_SETINFO");
return (B_FALSE);
}

return (B_TRUE);
}


boolean_t
svs_in(int ifd, gsm handle, gsm_byte *buf)
{
gsm_signal sample[160];

if (read(ifd, sample, sizeof (sample)) != sizeof (sample)) {
fprintf(stderr, "svs_in: short read\n");
return (B_FALSE);
}

gsm_encode(handle, sample, buf);

return (B_TRUE);
}


boolean_t
svs_out(int ofd, gsm handle, gsm_byte *buf)
{
gsm_signal sample[160];

if (gsm_decode(handle, buf, sample) < 0) {
fprintf(stderr, "svs_out: gsm_decode failed\n");
return (B_FALSE);
}

if (write(ofd, sample, sizeof (sample)) != sizeof (sample)) {
fprintf(stderr, "svs_out: short write\n");
return (B_FALSE);
}

return (B_TRUE);
}


main()
{
gsm handle;
gsm_frame frame;
int audiofd;
int option;
des_cblock key, ivec_in, ivec_out;
des_key_schedule ks_in, ks_out;
des_cblock cbuf_in[4], cbuf_out[4], cbuf_buf[4];

audiofd = open("/dev/audio", O_RDWR);
if (audiofd < 0) {
perror("open");
exit(4);
}

/*
* Initialize GSM compression code
*/
if ((handle = gsm_create()) == NULL) {
fprintf(stderr, "svs: gsm_create failed\n");
exit(4);
}

option = B_TRUE;
if (gsm_option(handle, GSM_OPT_FAST, &option) < 0) {
fprintf(stderr, "svs: gsm_option (FAST) failed\n");
exit(4);
}

/*
* Initialize DES code
*/
des_random_key(&key);

if (des_set_key(&key, ks_in) < 0) {
fprintf(stderr, "svs: des_set_key failed\n");
exit(4);
}
if (des_set_key(&key, ks_out) < 0) {
fprintf(stderr, "svs: des_set_key failed\n");
exit(4);
}
memset(ivec_in, 0, sizeof (ivec_in));
memset(ivec_out, 0, sizeof (ivec_out));

/*
* Open audio device and configure it
*/
if (!svs_audio_init(audiofd, NULL))
exit(3);

for (;;) {
/*
* Get 160 samples (16-bit linear 8000Hz) and
* convert to a 33 byte frame
*/
if (!svs_in(audiofd, handle, frame))
exit(1);

/*
* Encrypt/Decrypt block
*/
des_cbc_encrypt(frame, cbuf_out, (long)32, ks_in, ivec_in,
DES_ENCRYPT);
des_cbc_encrypt(cbuf_out, cbuf_buf, (long)32, ks_out, ivec_out,
DES_DECRYPT);

memmove(frame, cbuf_buf, 32);

#if 0
if (memcmp(cbuf_in, cbuf_buf, 32) != 0) {
fprintf(stderr, "svs: memcmp failed\n");
exit(4);
}
#endif

/*
* Take 33 byte frame and convert to 160 samples
* and play
*/
if (!svs_out(audiofd, handle, frame))
exit(2);
}

gsm_destroy(handle);
}
<--------------------------- CUT HERE ----------------------------->

Newsgroups: sci.crypt
From: Graham Toal <gtoal@gtoal.com>
Subject: Re: Let's build software cryptophones for over the internet...
Reply-To: Graham Toal <gtoal@gtoal.com>
Date: Sun, 25 Apr 1993 23:58:02 GMT

In article <1rf04s$jqu@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
: I'd really like to see such a thing developed so that interactive
:internet talk radio could be done. Ideally, though, it should be a general
:purpose device. It should be a general purpose enough device that nobody
:should be able to balk at its widespread use. Obviously, to make it easy
:for homebrewers, it should use pretty common hardware.

I suggest we start with the ubiquitous Sun, to get a lot of momentum
going. Custom hardware isn't going to go anywhere until there's a
user base.

: Anyone interested? I'll start a provisional mailing list. Let
:me know if you want on.

Count me in. I need someone at the US end to experiment on the
protocols with, and I like the way you code. Give me 3 weeks to
move house and settle in then we'll go for it seriously...

G

Newsgroups: sci.crypt
From: holland@CS.ColoState.EDU (douglas craig holland)
Subject: Re: Let's build software cryptophones for over the internet...
Date: Mon, 26 Apr 1993 03:31:06 GMT

In article <C62D8r.C7p@demon.co.uk> Graham Toal <gtoal@gtoal.com> writes:
>In article <1rf04s$jqu@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
>: I'd really like to see such a thing developed so that interactive
>:internet talk radio could be done. Ideally, though, it should be a general
>:purpose device. It should be a general purpose enough device that nobody
>:should be able to balk at its widespread use. Obviously, to make it easy
>:for homebrewers, it should use pretty common hardware.
>
>I suggest we start with the ubiquitous Sun, to get a lot of momentum
>going. Custom hardware isn't going to go anywhere until there's a
>user base.

Why don't we move down even further toward the masses by setting this
up on an IBM PC clone(probably needs to be a 386 or a 486) with a
sound blaster and a V.32bis modem. Those components are very widely
available. I don't know if the PC has enough horsepower to encrypt the data
at realtime, but the sound blaster has 4 to 1 hardware compression and will
work at any sampling rate from 4KHz to 23 KHz.

Doug Holland

--
| Doug Holland | Anyone who tries to take away my freedom |
| holland@cs.colostate.edu | of speech will have to pry it from my |
| PGP key available by E-mail | cold, dead lips!! |

Newsgroups: sci.crypt
From: baxter@ed0118.ped.pto.ford.com (Gene Baxter)
Subject: Re: Let's build software cryptophones for over the internet...
X-Newsreader: TIN [version 1.1 PL7]
Date: Mon, 26 Apr 1993 21:18:14 GMT

douglas craig holland (holland@CS.ColoState.EDU) wrote:
: In article <C62D8r.C7p@demon.co.uk> Graham Toal <gtoal@gtoal.com> writes:
: >In article <1rf04s$jqu@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
: >: I'd really like to see such a thing developed so that interactive
: >:internet talk radio could be done. Ideally, though, it should be a general
: >:purpose device. It should be a general purpose enough device that nobody
: >:should be able to balk at its widespread use. Obviously, to make it easy
: >:for homebrewers, it should use pretty common hardware.
:
: Why don't we move down even further toward the masses by setting this
: up on an IBM PC clone(probably needs to be a 386 or a 486) with a
: sound blaster and a V.32bis modem. Those components are very widely

I concur for a PC to PC version. BUT for a interactive thing like
internet talk radio?!?! It makes me cringe at the amount of hogging such
a thing would do to the bandwidth of the internet. I mean 15 meg files getting
floated around for internet talk radio is bad enough. I have a solution; use
the phone system; take your electronics and use them on point to point
conversations through the phone and thats it. If you need to tell someone
something secret and very important wouldn't it make more sense to write it
out concisely? And if it's just a quick "YO" then use a code word and spend
your twenty cents.
Those good ol analog systems like Shortwave, Telephones, and TV's have
a use don't gunk up a nice digital packet network trying to emulate them!

Baxter
Baxter.

Newsgroups: sci.crypt
From: eah1@gauguin.wustl.edu (Edward Anthony Hutchins)
Subject: Re: Let's build software cryptophones for over the internet...
Date: Tue, 27 Apr 1993 07:50:11 GMT

Hmmm.... CELP takes up about 12.6 MIPS for full duplex, and has been
implemented on about a million DSP chips... the 56001 card in my PC only cost
about $700, and I'm sure once demand goes up the prices would drop. The Analog
Devices 21020 board that we're looking at now cost about $500 (academic price).
I don't think hardware is something to worry about... if you get it working,
people will snap up internet phone cards like there was no tomorrow.
What we need here is a good implementation of CELP (the government code is
absolute crap, I got a 30% speedup after looking at it for a couple of hours),
and modifications to pgp to allow it to compress/decompress 144 bit frames
every 30msec... I think the AD21020 should have enough juice for this (50MIPS).
As part of the project I'm working on now, we're trying to get CELP up and
running in realtime full duplex mode... I gotta find the source to pgp and
see how tough it would be to integrate the en/decryption parts into the code.
I'll play with it. Anyone else out there got an AD21020 setup?
- Ed
_____________________________________________________________________________
:-) ('') (-: (,,) :-) ('') (-: (,,) :-) | see lidflip instructions on
Edward Hutchins, eah1@cec1.wustl.edu | other side of card

Newsgroups: sci.crypt
From: dave@tygra.Michigan.COM (David Conrad)
Subject: Re: Let's build software cryptophones for over the internet...
Date: Wed, 28 Apr 1993 09:00:20 GMT

In article <1993Apr27.075011.12624@wuecl.wustl.edu>
eah1@gauguin.wustl.edu (Edward Anthony Hutchins) writes:
>[modify] pgp to allow it to compress/decompress 144 bit frames
>every 30msec...
>As part of the project I'm working on now, we're trying to get CELP up and
>running in realtime full duplex mode... I gotta find the source to pgp and
>see how tough it would be to integrate the en/decryption parts into the code.

I presume you are just going to use IDEA for the session encryption and
transmit the session key with RSA?

David R. Conrad "No his mind is not for rent/To any god or government"
--
= CAT-TALK Conferencing Network, Computer Conferencing and File Archive =
- 1-313-882-2209, 300bps-14400bps, V.32/V.32bis/TurboPEP New users use 'new' -
= as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") =
E-MAIL Address: dave@Michigan.COM

Newsgroups: sci.crypt
From: trh42502@uxa.cso.uiuc.edu (Dream Weaver)
Subject: Re: Let's build software cryptophones for over the internet...
Date: Fri, 30 Apr 1993 03:38:24 GMT

>I presume you are just going to use IDEA for the session encryption and
>transmit the session key with RSA?
>
>David R. Conrad "No his mind is not for rent/To any god or government"
>--

A question from a rank amateur:
I thought that the problems with encrypting voice were the result of
the massive amounts of redundancy in voice even after most forms of
compression. And that this redundancy and the large amounts of signal, gave
the ability of a plain text attack and periodicity?
Am I wrong or is the threat minimal?

Tom

--
______________________________________________________________________________
Tom Hilquist Internet:t-hilquist@uiuc.edu
Disclamer: I didn't write this! Email for PGP Public Key
PGP 2.2 Key fingerprint = 20 FF CA 46 1D B8 CD 55 F7 9D 71 B0 BD B7 B3 B5

Newsgroups: sci.crypt
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Let's build software cryptophones for over the internet...
Date: Sun, 2 May 1993 01:44:31 GMT

I came up with the opposite notion the other day:

If you have an ISDN phone and a CD player with some level of
software control and bits out, you can scramble your voice
comm via your favorite CD. This is, of course, private-key
encryption using the infamous one-time pad with
not-very-random numbers. But key distribution is done for
you by the music industry. All you have to do is agree
which CD beforehand or at the beginning of the call.

Silicon Graphics CD-ROM drives have full digital sound I/O;
SUN I think will have the same (Sony) drives soon. Actually,
you just need to input and monitor the track and second counters.
Standard consumer $100 CD players should work with a few simple
mods.

--

Lance Norskog
thinman@netcom.com
Data is not information is not knowledge is not wisdom.