Quoting Trei, Peter <ptrei@rsasecurity.com>:
Ryan suggested earlier that the Ipaq with Fireball isn't up to the task. I don't think this is correct. I point you to
http://www.stanford.edu/class/cs344/staff/group10/final_report.pdf
in which some Stanford students produce a wireless ipaq2ipaq VoIP system. Biggest problem is that it's simplex, not because of cpu limitations but rather that the Compaq HW can listen or make noise, but not both simultaneously. Using a headset which interfaces through the expansion port might enable you to avoid this problem (and the BT headset could also offload the codec). 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. I'm not sure what the audio output from the ericsson bluetooth headset is, when it connects to a PDA. I've asked Monty (the ogg guy) and some others, and they think a 50MHz ARM7 is more than sufficient for the compression; getting it down a 33MHz 68000 (like in the recent high-end palm devices) would be cool.
I've toyed with the idea of porting SpeakFreely to Ipaq, but have not actually done anything at this point.
I've x-posted to coderpunks, since that group is more germane. Serious further discussion should be over there, IMHO.
Peter Trei
============================================================================ ================ This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. ============================================================================ ================
-- Ryan Lackey [RL7618 RL5931-RIPE] ryan@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
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.
Quoting Bill Stewart <bill.stewart@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@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
Ryan wrote:
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.
Being rather familiar with cryptographic implementations for the Palm platform, I would strongly recommend against attempting to use Palm as a voice encryption device. The platform simply lacks the horsepower to do so. This won't change until Palm starts rolling out their next generation ARM based devices late this year. Of course since the current underpowered Palm platform is continuing to lose the adoption rate fight against PocketPC, basing any new product on the future availability of next-generation Palm devices places the software developer's business model at risk. --Lucky Green
participants (3)
-
Bill Stewart -
Lucky Green -
Ryan Lackey