End-to-end encrypting US GSM phones?

[Ryan Lackey]

Quoting Bill Stewart <bill.stewart at pobox.com>:
> 
> 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.

I wasn't proposing the palm's audio subsystem; direct access to the
audio feed in/out of a bluetooth wireless headset, instead.  I would
probably do the same thing with an Ipaq, even though the ipaq 3600
hardware, linux, and wince-with-compaq-drivers support full duplex.

I think the ipaq is probably a better target platform, if it can be
done as a WinCE app, and not require putting linux on the device, or
if the device is sold pre-configured with linux and the secure voice
software.

Ipaq also has the benefit of supporting 802.11, etc., so you could do
an "encrypted cordless phone" when around the office, with cell as a
way to roam.

> Second, crypto is hardly ever the CPU bottleneck - voice compression is.

Right -- 70MHz ARM7 is enough for ogg vorbis at nearly the
bitrate required, so I'm pretty confident this is possible on an ARM
platform.  

Key management would tax a palm a bit, depending on how you handle
public key crypto, primarily on the battery side.  I suppose if you do
key generation on the palm when docked, it's not as much of a concern.

> 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.)

People have done CDPD voice before, but yes, the latency is a problem.

Most of the ultra-low bitrate encoding algorithms seem designed for
2.4Kbps...GSM is...13Kbps?  And so do do full-duplex gsm-quality you'd probably
need 4-channel HSCSD.  I assume cellphones are either simplex or
effectively so.
> 
> Does GSM support handset-to-handset data connections?
> Or does you have to use modems?   How fast are they?

GSM does 9.6kbps modem/data connections (PPP).  In the civilized parts
of Europe, you can get High Speed Circuit Switched Data; basically,
channel bonding for GSM.  In the UK, 14.4Kbps HSCSD is free; 28.8kbps
is surcharged.

Since in the EU it is "caller pays", you could easily run an
on-network GSM gateway, with both sides supporting HSCSD, at 14.4kbps,
~150ms latency, operating 24x7, for about USD 110/month flatrate to
the calling side.  Nokia cardphones, Ericsson T39m and T68 all support
HSCSD.

> 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,

So palm would then be sort of feasible on a bluetooth-headset,
bluetooth-cellphone, with 28.8kbps HSCSD, at about USD 0.15/minute
cell to cell in the UK.

> or you could burn some of your 206MHz horsepower on better compression.

I suppose battery life is the concern; the ipaq can throttle back
quite a bit, so you could have a "call cost/audio quality/battery
life" multi-axis control.

-- 
Ryan Lackey [RL7618 RL5931-RIPE]	ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.	+44 7970 633 277 
the free world just milliseconds away	http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F