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