End-to-end encrypting US GSM phones?

[Bill Stewart]

At 05:07 PM 12/31/2001 +0000, Ryan Lackey wrote:
>...
> > A 206 MHz Ipaq would, I think have sufficient HP to do the crypto.
>
>I didn't mean the imply the Ipaq CPU (200MHz StrongARM) would be
>insufficient, merely that from usability standpoint.
>
>The "holy grail" would be working on 16-33MHz *dragonball* (== 68000)
>processors.  *That* would be impressive.  Doing this on a strongarm is easy.

First of all, the sound system on a Palm Pilot can't handle the job -
there's no microphone, and the speaker system mainly knows how to beep
(you can play different tones, but it's not made for voice.)
Somebody said here that the iPaQ audio is half-duplex - too bad,
because push-to-talk is annoying.

Second, crypto is hardly ever the CPU bottleneck - voice compression is.
Public-key operations take some time, but only at startup;
RC4 at 9600 bps won't keep your CPU warm, and even AES at 32kbps isn't much.
But voice compression, if you want anything fancier than ADPCM,
does take a lot of horsepower, either from a CPU or a DSP or ASIC.
(ADPCM's dirt-simple, and works fine for 32kbps, but is pretty ratty at
16kbps or below.  Almost anything else starts burning lots of CPU
if you want to go 16kbps or tighter (some of the delta-modulation stuff
isn't very CPU-intensive, but it's also not good for low bit rates.)
I'd be surprised if anybody could get a dragonball to do the voice
compression tightly enough even if there were audio hardware support.

In the current cell-phone world, you typically need 9600 or below,
and 4800 would be better.  Cell phones do have voice compression built in;
unfortunately, the software isn't designed to let you get at the compressed
data stream and do other things with it, and if you're using modems,
you need one or two more sets of similar hardware to transmit it after that.
(The easy data channel in the US, CDPD, doesn't work for voice -
it fits the data into gaps between voice packets, so the latency
is generally way too long and way too variable to handle voice.)

Does GSM support handset-to-handset data connections?
Or does you have to use modems?   How fast are they?
Almost all of the newer cellphone data formats are fast enough,
usually 64kbps or more, if anybody bothers deploying them.
(I'm not counting the Japanese i-mode stuff.)
32kbps (plus async overhead, if any),
lets you use dirt-simple compression algorithms,
or you could burn some of your 206MHz horsepower on better compression.