Re: PRZ encrypted voice software release imminent
At 1:36 PM 8/11/95, Ray Cromwell wrote:
My question is, how portable is it, and does it work over TCP/IP rather than just modem connections (I suggested this about a year ago)? My ideal implementation would function on the following architectures:
Unix: can be used through either /dev/tty?? or Socket (probably want to use UDP). Works on Solaris, IRIX, AIX, NetBSD/FreeBSD/BSDI and Linux. (audio devices are all proprietary)
Windows: uses Window's sound card device drivers, works via either comport or WinSock
Mac: uses Mac sound drivers, uses Mac modem port or MacTCP
From the "MacWeek" article, it initially runs on the Macintosh, using the sound capabilities built into (nearly) all Macs. Direct modem connections, with Internet versions to follow. (Windows to follow, too.)
Sound quality with 9600 baud modems said to be pretty good, quality with 14.4 modems said to be very good, and quality with 28.8 modems said to be better than standard phone quality. The Mac may be a strange platform to develop on, to many of you, but it has some advantages. The sound tools are relatively standardized and are even built into the OS. Developers can thus count on what users will have. But why the developers actually picked the Mac to do first is something they can talk about. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
At 1:36 PM 8/11/95, Ray Cromwell wrote:
My question is, how portable is it, and does it work over TCP/IP rather than just modem connections (I suggested this about a year ago)? My ideal implementation would function on the following architectures:
Unix: can be used through either /dev/tty?? or Socket (probably want to use UDP). Works on Solaris, IRIX, AIX, NetBSD/FreeBSD/BSDI and Linux. (audio devices are all proprietary)
Windows: uses Window's sound card device drivers, works via either comport or WinSock
Mac: uses Mac sound drivers, uses Mac modem port or MacTCP
From the "MacWeek" article, it initially runs on the Macintosh, using the sound capabilities built into (nearly) all Macs. Direct modem connections, with Internet versions to follow. (Windows to follow, too.)
I just hope they isolated the operating system dependent code into seperate modules so that "PlaySoundChunk(Chunk)" is used rather than "MacDeviceDriverCall(MacSpecificDeviceStruct, MacSpecificFormat)" The application layer should be abstracted above the transmission layer above the link-layer. At the application layer, communications should be sent through the transmisson layer, e.g. "GetNextPGPFonePacket(Protocol, Packet)". The Protocol here would be TCPIPDriver or ModemDriver. Therefore, all one would need to do to port it to different platforms is code up a TCPIPDriver (for Unix == Berkeley Sockets, for Windows = Winsock, for Mac = MacTCP), code up a modem driver (Unix = tty's + ioctl, Mac = Communications Manager, Windows = TAPI), and finally port the SoundPlay and SoundRecord functions to the platform dependent way of playing sounds and recording them. If you are forced to abstract above "modems", your algorithms will be designed to work over more general transmission schemes. I fear that coding for modems first will lead to an overall application tuned for modems, but poorly designed for asynchronous networks. The tunning should be done in the driver, not the application/algorithm level. (for example, modems don't experience much "packet churn and loss", and they usually have a dependable bandwidth. Even if they retrain randomly from 28.8 to 14.4, they can still be counted on to atleast have 9600 bps throughput more consistently deliverable than say a slip/ppp line would) Far too often on Macs and PC's I see code "welded" to specific hardware dependencies. I only hope that PGPFone is more like PGP2.0 and less like PGP1.0 (and less like HotJava, which is also a bitch to port), because for general acceptable, I don't think it will succeed until it atleast runs and interoperates on Mac, Windows, and Linux.
The Mac may be a strange platform to develop on, to many of you, but it has some advantages. The sound tools are relatively standardized and are even built into the OS. Developers can thus count on what users will have.
I don't think there is a problem with developing on the Mac. Atleast the Mac has a real O/S. If it had been done for DOS first, it might have been poking SoundBlaster registers with arcade magic constants in the program. However, the application should be isolated away from its I/O mechanisms so that all I/O is done through a module which "maps" I/O requests to the local operating system mechanism, rather than depending on them directly. Sorry about the rant. (I haven't seen PGP phone's code, but I am just remembering RealAudio/InternetPhone/VidPhone and a whole host of other internet utilities that are either available only for windows, only for Mac, or only for unix. Netscape seems to have done things right.) -Ray
If you are forced to abstract above "modems", your algorithms will be designed to work over more general transmission schemes. I fear that coding for modems first will lead to an overall application tuned for modems, but poorly designed for asynchronous networks. The tunning should be done in the driver, not the application/algorithm level. (for example, modems don't experience much "packet churn and loss", and they usually have a dependable bandwidth. Even if they retrain randomly from 28.8 to 14.4, they can still be counted on to atleast have 9600 bps throughput more consistently deliverable than say a slip/ppp line would)
asynchronous networks are a completely different beast than your basic point-to-point phone call. Over. If you expect people to use a secure voice communication device, they've got to like it. Over. I don't know anybody who prefers more latency. Over. I think that it makes great sense to optimize for a point-to-point connection. I also believe that it should be an un-error corrected channel (no V.42 or V.42bis) since many speech coders can tolerate the errors. Knowing the channel characteristics also allows you to tailor your crypto usage. If you know you've got a raw synchronous channel, and Pr(bit insert or bit delete) << Pr(bit error) than you can avoid a lot of overhead. This does matter where bandwidth is tight. Say, sticking a 13,000 bit/s coder down a 14,400 bit/s pipe. With GSM's 260 bit frame every 20ms, it leaves 28 bits per frame for all overhead. This includes any forward error correction, sync maintenance, crypto IV's etc. You can't tune this in the driver. None of this says that you shouldn't also optimize for the packetized case too. I think that you can negotiate the right behavior at start up time based on detected channel characteristics. I think that the biggest impact is in the framing overhead, or lack of it. You are always trading off bandwidth, speech quality and MIPs. Eric
[stuff about tuning algorithm to channel characteristics]
None of this says that you shouldn't also optimize for the packetized case too. I think that you can negotiate the right behavior at start up time based on detected channel characteristics. I think that the biggest impact is in the framing overhead, or lack of it.
You are always trading off bandwidth, speech quality and MIPs.
I agree with this, but it is still possible to do all this through an abstract interface layer. One can "query the line characteristics" of a transmission layer and then limit the selection of algorithms based on those characteristics. Example: we have a class TransmissionLayer, and two derived classes "syncrhonouslayer" and "asynchronouslayer" (subclass as appropriate). Note, no underlying link type is being refered to. It could be a network or a modem. Now we have a bunch of algorithms (codecs), CodecA is optimized for a synchronouslayer with atleast 16kpbs. CodecB for asynchronous packet networks. At the application layer, the user chooses a way of connecting. The application instantly picks the best codec (supported by both ends) for that transmissionlayer. it alo updates the user interface automatically, e.g. displaying a "half duplex" mode for one type of link, or "conference call' for another. Some types might not support all encryption types because of cpu limits (also detected) There's no reason this could not be programmed. It would also be highly portable, highly maintainable, and more easily adoptable. Direct-to-hardware hardwired algorithm software is good for proof of concept. But I'm thinking ahead, to a time when a multimedia protocol will be just another transport layer ontop of which cool applications are running. (like http+mime runs over TCp) -Ray
-----BEGIN PGP SIGNED MESSAGE-----
But why the developers actually picked the Mac to do first is something they can talk about.
I worked on the Mac version of Nautilus for a very short while. Nautilus was to provide a core of interoperable code for doing voice-as-modem-stream on SunOS, DOS/Win, and Mac platforms. The developer agreement that all developers had to execute specifically said "I promise not to add any crypto." That might sound odd-- but the crypto was to be added later, under the direct or indirect supervision of PRZ. I ran out of time before the code reached that point. I don't know what percentage, if any, of the Nautilus code is incorporated in PGPfone. Based on Will Price's CryptDisk work, I look forward to learning from the PGPfone source code. - -Paul - -- Paul Robichaux, KD4JZG | Do you support free speech? Even when perobich@ingr.com | you don't like what's being said? Be a cryptography user. Ask me how. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMCuUFafb4pLe9tolAQF/vAQArDUGcD7SDpV1Zo6+neIl21SYQE34cqIx Kpqs0NV67NUTg/U/EXxalFUs1lioCvGyEbwPRxTaEi3Idfbm5A8BOVDyFJIThtLx 3Nzf7OBpYqbztzht0+E8PGOZnx0dcN2+O1jeqm86GuNp5mJ6JmQZY2ey7aqTIDfr gAZgUcIFM4k= =JPdu -----END PGP SIGNATURE-----
participants (4)
-
Eric Blossom -
paul＠poboy.b17c.ingr.com -
Ray Cromwell -
tcmay＠got.net