| From: Simon P. Ditner <[EMAIL PROTECTED]> | Date: Tue, 31 Jan 2006 00:39:56 -0500
You can tell that I'm getting behind in my reading. Thanks for your posting -- very interesting. | "Make it Talk", Kevin Lenzo from Cepstral [7] spoke about their | commercial variant of the popular Festival Text-To-Speech program. He | also gave out free developer licenses to all attendees. Too bad it isn't open source. | "Rural Voices: Indiana Farm Net". Brian Capouch, a professor in | Indiana has deployed a wireless network that covers thousands of | square kilometres of rural Indiana on a budget, providing high speed | internet access and dial tone in some of the most under serviced | communities in the U.S., truely uplifting a community that had been | left behind in the digital divide. His network is based on Linux | OpenWGT[8], Asterisk, and the NetGear WGT634u (an amazing device which | blows away the Linksys WRT54g). I've had my eye on this device for a while. OpenWGT seems to support it (I learned this from your posting). OpenWRT lists the hardware support as a "work in progress" which daunted me. Is he hosting Asterisk on the WGT634u? I guess anything is possible with a swap disk hooked up via the USB. | "Security on VoIP". Phillip Zimmerman, the author of PGP (software for | encrypting and signing documents and emails) spoke on his | soon-to-be-released VoIP encryption software. It works independently | of SIP by encrypting RTP streams end to end. The part I found | particularly clever was his technique for verify that there is no man | in the middle snooping your call (I'm not a crypto expert, so the | details are a bit fuzzy). Essentially, the way it works is that once a | call is set up, you speak your public key to the other person, and | verify that that is what they received on their end. I've used a scrambler for a regular phone line which used a different but not unrelated technique to the initial one you outlined. The scramblers used Diffie Hellman key exchange to create the common session key and displayed the same section of the key, in hex, on each box. Each side's human would read out half of the digits to be sure that the keys were the same on each side (== no man in the middle). | Now the really | clever part is that for each subsequent call to the same party, your | previous key and previous remote party's key are used to generate a | key for this call, creating a trust relationship in the same manner | that Verisign signs an SSL certificate for Thawte, and then Thawte can | sign your certificate, and so on. That's not really the same at all. The trust realtionship with x.509 certificates involves "hard wired" trust for the root certificates (Thawte and Verisign each have one) and then a signed chain of certificates to you, each step of which can be verified at any time. What you describe seems much closer to SSH's authorized_keys file. But it seems to mix up session and authorization keys. This might create problems when a backup is restored. You want to authenticate each side (accomplished (rather weakly) by voice recognition in this case) and prove liveness (i.e. that this is not a replay of previously captured packets) (accomplished by the fact that part of the newly minted session key is what is being spoken, and that the session key was generated with input from each side so that it could not be controlled by either alone). The x.509 certificate approach gives potentially dangerous control to the root (demonstration: they get to charge for prime numbers!). PGP and Phill's new system avoid this centralized control. A nice characteristic. The FreeS/WAN project took another approach to securing IP. We failed, but not because the approach was technically unsound. I'd like to know more about whether IPsec is reasonable for RTP. Not the keying part -- I think I understand that. The data transport part: latency, bandwidth, and processing costs. FreeS/WAN's successor is Openswan. If the approach is technically reasonable, Openswan could do the job. (At least one Openswan developer is active on this list.) As far as I can tell, SRTP might be reasonable for data transport but has no reasonable support for key exchange. I admit that I have not looked far into this. It would be unfortunate if IPsec, meant to secure all IP, were not practical for RTP.
