voice privacy for the masses

[Phil Karn <karn@unix.ka9q.ampr.org>]

I think Hal Finney's analysis is not far from the mark. Saner elements
in the government probably do realize the utter impossibility of a
complete ban on uncrackable crypto given the existence of talented,
knowledgeable and highly motivated (especially now!) "cypherpunks".

But the government has also found that with very little effort, they
can still have an enormous practical effect on the non-cypherpunk
masses.  Heck, look at what the NSA did to the digital cellular
standards by standing in the shadows and quietly threatening to
withhold export approval to phones with meaningful technology.

The NSA barely had to whisper its objections, because the industry
simply doesn't care very much about customer privacy. Certainly not
enough to risk not only their non-US markets, but also the ability to
have phones manufactured overseas for the US market. And then NSA rubs
salt in the wound by brazenly claiming that they're only concerned
about encryption getting into the hands of unfriendly foreign
governments. As far as they're concerned, they say with a perfectly
straight face, Americans are free to use any encryption scheme they
want.

I wonder how people like that can sleep at night.

Well, the implications are obvious. If the public is ever to benefit
on a large scale from strong encryption technology, it cannot depend
on a normal market to sell it to them in turnkey packages. As soon as
you go into business overtly selling such packages, the government
pressure will begin. They will make sure that you do not become too
successful, either by banning exports or by flooding the market with
inferior technology that they can break (like Clipper).

So we need to create a rather nonconventional "market". More
specifically, we need to find a way to bring the efforts of the
cypherpunks to the public with minimal cost and in a way that the
government cannot control.

By far the best way to do this is to write and distribute free crypto
software that requires only readily available general purpose hardware
to run. As we know, duplicating and distributing software is so
trivial that controlling it is virtually impossible. And while it's
theoretically somewhat easier for the government to ban or regulate,
say, modems faster than 2400 bps or CPUs faster than 10 MHz 286s,
general purpose computer hardware like this has so many other
"legitimate" uses that in practice a ban would again be impossible.

I've contributed a little to this effort myself with my public domain
DES code, but it's the PGP effort that has really made this a reality.
PGP is now unstoppable, and it's well on the way toward providing
large scale privacy for email and other textual information.

But voice is still a problem. What we really need now is "PGVP"
("Pretty Good Voice Privacy"), i.e., a package of public domain
software that, when again combined with readily available general
purpose computer hardware, produces a highly secure telephone.

We already have two of the three hardware components of a digital
secure telephone well in hand: CPUs capable of encrypting digital
voice in real time, and reasonably fast telephone modems. The one
remaining piece to the puzzle is the vocoder, as conventional waveform
sampling of speech produces a data rate too high for telephone modems.
(Faster modems might alleviate the need for a low bit rate vocoder,
but current generation modems are already running very close to
theoretical limits, and there won't be too many more improvements.)

Ready-made vocoders are available. In fact, my company (Qualcomm) just
announced one (the Q4400) as a spinoff of our CDMA digital cellular
system.  It's a mask-programmed AT&T DSP-16A DSP chip. Unfortunately,
like many leading-edge products, it's not cheap: $69/ea in quantity
1000, and reportedly nearly $200 in small quantities.

A second alternative is to run your own vocoder software. But vocoders
are notoriously compute-intensive, and they're traditionally run on
DSPs.  And DSPs do not yet qualify as "widely available general
purpose computer hardware".

That leaves a third possibility: tuning vocoder software to run in
real time on a fast general purpose processor like a 486. John Gilmore
has already obtained and distributed public domain code that
implements the Federal standard CELP vocoder algorithm (used in
government secure telephones, a nice twist) but my understanding is
that it's too slow to run in real time on popular computers. Van
Jacobson at LBL has reportedly tuned it to run in better than real
time on a Sparc 1+, but he hasn't released it yet and he's a
notoriously hard guy to get ahold of.

So the request of the day is this: who's willing to take that CELP
code, bum enough instructions out of it so it will run in real time on
a 486, and place his or her work back out into the public domain?

Phil