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