PGPphone Source Released

drac writes "Phil Zimmerman has released the source to PGPphone , saying that there is no corporate interest and that he doesn't want to let the project die..." There appears to be only windows and mac source, but perhaps a port could be made. Good secure voice over internet software for Linux would be nice.

It's maybe ok?

[rgottsch]

He states on his website, that it is MAYBE okay to use it anyway? Hm.. I think that is something that should be further investigated...

Source code not released?

[cybaea]

Although NAI is releasing the source code, the source code is still copyrighted by NAI, and cannot be used without permission.

What's the point of source code I cannot use? This seems to be a non-event to me.

Cool....but

[Knight]

This looks pretty cool. It needs some work, but it's a good start. I'm a bit nervous about using/modifying something with such a vague copyright statement. Perhaps we could get some clarification?

If you need to point-and-click to administer a machine,

legal issues notwithstanding

[nosferatu]

Legal issues notwithstanding, at least interested parties will be able to look over the code and see how various engineering challenges were handled. OTOH if a true port is legally allowed, that would be terrific. Especially if it can interoperate with the windows clients, since for many users, it is not feasible to impose an OS choice on all the people with whom they wish to communicate. Can any true cypherpunks comment on how robust this app is, even a rough idea after quick code inspection?

Re:It's maybe ok?

[rgottsch]

Reading further into the website: the code is copyrighted by NAI, but you can still help with the project...? If someone could enlighten me: the code is copyrighted - so may I compile it and use it? May I compile it and use it in my company? Can I use the source-code somewhere in my programs? What license do they use anyway? (if any)

Hmmmm

[Gleef]

I wonder if a program like this, combined with a phone like the Qualcomm pdQ Smartphone [qualcomm.com] could make a fully portable secure wireless phone?

If the pdQ doesn't have the right hardware connections to do that, is there another phone out there that does (preferably one that can run Linux or an OS of similar power).

----

Voice over internet ?

[FauxPasIII]

I tried PGPfone way back in the olden days when it was originally released, and it isn't (or at least, back then it wasn't) voice-over-IP. The way it worked was to dial directly with your modem into the modem of the person you wish to call, and the sound would then be transmitted as encrypted data over that modem channel.

there is a secure (internet) phone for Linux

[23]

It's called Speakfreely and you have your choice of encryptions. And it actually runs on different platforms (so you can talk to Win*-users too).

More can be found at the authors site here [fourmilab.ch]

Roland

Re:Voice over internet ?

[X]

PGPfone has for QUITE some time support communications over the Internet and over phone lines. The former works better than the latter IMNSHO.

very nice

[G27 Radio]

I've been following the Jabber [jabber.org] project a little bit. Perhaps someone there might be able to incorporate some of the source into their project.

So far it seems to be just text messaging that they're working on, and no encryption. I've been waiting for them to do encrypted messaging. Encrypted voice would be great also.

All in all, this is great news.

numb

PGPphone Source Revealed

[alizard]

It's available, it has the rare feature of being interoperable between Mac and Windows environments... and if anyone can be found to write the code for the Linux port, it'll be interoperable between Mac / Windoze / Linux.

I've been telling people about PGPfone mainly for the interoperability with the security more as an interesting side effect, don't know if you've noticed this or not but most voice conferencing apps are basically single platform.

Interoperable, free of charge, and secure... what more do you want?

The answer of course... if the port got written as freeware and included in standard Linux distribution, it would REALLY piss off the Feds... possibly everybody's. With the exception of the smart minority of government people who will be using it to protect their own secrets.
y2k info - http://www.ecis.com/~alizard/y2k.html

Heres the game plan

[renegade187]

Obtain large mexican hat,
Superglue the speakers to hat,
Superglue the foldable mic to hat,
Attach cell modem,
Plug into laptop,
Duct tape the laptop to back and put on hat,
Portable communications at its finest!

And...

[Larry L]

by version 8.x it's going to be fully compatible with netmeeting and other programs like that.
(I believe the standard was H. 232?)

It uses GSM compression which compresses it to something like 10-15kbits/s.

So if youre looking for voip, this is the way to go.

This could be good

[Thanatos]

As someone else pointed out, the code itself might not be terribly usefull, but it could show how some challenges were handled.. And even if you can't use the code w/o permission, you can still use it to build a compatible product..

Either way, with some of the recent happenings (*cough* decss *cough*) It might be a good idea for developers working on (usually misunderstood) controversial software to be able to use encrypted voice communication as well as encrypted text.. I fully expect this to become more important as people get more high speed links to the home, and developers start to take advantage of VOIP, Especially on projects where the members span the globe..

Speak Freely

[krital]

... is good free secure voice that's compatible with Windows and UNIX. I've used it many times, although unfortunately it doesn't do too well with my soundcard under Linux.
You can find it at www.fourmilab.ch or www.speakfreely.org

Re:Heres the game plan

[revnight]

it's hard to get into a car wearing a large sombrero, though...perhaps someone could put earphones on a derby.

not that i really want more people driving while talking on the phone, but....

Is this really so hard under linux?

[xtal]

Is secure voice really so hard? I mean, there are command line wav file recorders, command line encryption tools, and it's easy to open socket connections to other machines.

So, can't someone hack together a little perl script to implement an extremely basic interface. From there, hacking a gui on it wouldn't be very difficult at all.

e.g.

voicein > pgp -k etc > socketconnection

Might be making things seem more simple than they are, but this really doesn't seem _that_ signifigant.

Kudos..

But....

[FascDot Killed My Pr]

I couldn't get SpeakFreely to work at all. The answer back from the mailing list was "because it doesn't work through an ip_masq (bad enough in itself). So then I tried just the sfecho from my machine, to the server and back: nothing. I messed with this (off and on) for about a week and got nothing. I wasn't very impressed.
---

License

[gotan]

A few more clarifications on the License and it's future would be nice i think, as i understand PGPfone (2.1 too?) is freeware, but the whole thing is still licensed by NAI ... and NAI could change their minds about the project when it's suddenly up and running (for whatever reasons).

It'd be nice to see a license attached to the source where contributors to the source could see how their efforts will be credited and need not fear that the whole project will be taken off their hands when someone decides they can make big money from it.

Speed?

[slashdot-terminal]

I don't know about any of you but the speed of data lines for the average person are quite liimted and really not suitatble to real time voice transfers anyway. Taking these things into encryption fields will only degrade preformance further. What I think that would be a better thing is to have a voice scrambler to attach to a phone. If I could get one of those I would be quite happy.

Make Speakfreely talk to PGPfone

[johnynek]

I have used speakfreely (some times very successfully, sometimes less so) but what would really interest me is seeing Speakfreely talk to PGPfone.

I don't see why you would really bother porting PGPfone (especially with the license in limbo) but if you could learn the protocol it uses it would be good to make speakfreely talk to Macs and other users of PGPfone.

Just an idea.

Re:It's maybe ok?

[blkwolf]

Check out bestcrypt for Linux from www.jetico.com

Re:But....

[GeorgeH]

I think it opens up a listen port on your machine. This is fine for a normal network, but if you do some investigating in the way ip_maq, you'll find that this is a pain for ip_masq.

My suggestion would be to set up port forwarding on the ip_masq box. You might also want to try testing SpeakFreely behind your network to see if it's the masq thing you don't like, or the acutal functionality. Incidently you'll probably have the same masq problem with PGP Phone.

--

^ = Score=-1, Uninformed

[Anonymous Coward]

You can get near-toll-quality codecs that run at 2400 bps. Zimmerman's package uses the same GSM codec that European mobile phones use, at a bit rate suitable for 14.4 kbps modems. Hard to find an Internet connection nowadays that doesn't have at least that much bandwidth. RTFM before posting.

Re:Heres the game plan

[Dalavon]

Funny thing is that here in Atlanta I hardley see anybody driving and NOT talking on the phone.

Re:Voice over internet ?

[spiffy_guy]

I also used PGP phone, but in later versions it did support use over TCP/IP. In fact it worked about as well as any of the other 15 or so voice over TCP/IP did at the time. The difference was that it was incredibly secure (and ate processor on my weak machine). Since processing power is not a big hurdle anymore this should work great. JOel

Moderate this up!

[Overt Coward]

The post above is very insightful -- open protocols and APIs are far more important than open sources (though the latter are still very useful). Porting PGPfone to Linux would be nice, but getting other programs to communicate with PGPfone is a more useful and general-purpose solution.

Since the source coude is still "owned" and not released under a friendly license (as of now, at least), this is an even better idea, because the source can be inspected to determine the protocols without ever having to use a single line of source code in the derived works.
--

Re:It's maybe ok?

[scjody]

Try either TCFS [unisa.it], CFS [ailis.de], or loopback encryption [kerneli.org]. I currently use loopback, but am going to check out CFS and TCFS in the near future. TCFS claims to be an extended, improved CFS.

Patches also exist to auto-mount your home directory on login if it exists on a loopback encrypted filesystem.

Re:^ = Score=-1, Uninformed

[slashdot-terminal]

Well I don't really have the equipment or the connection but judging from what kind of problems I have connecting to slashdot and other popular sites on T-3 connections I think that there is some cause for me to be skeptical. I remember one time when ftp.cdrom.com was inacessible for quite a while because of some problems with a major back bone network point.

Re:there is a secure (internet) phone for Linux

[garver]

Wow. This just floored me. I had been wanting something like this for a while; even screwing with NetMeeting (unhappily). I never dreamed I would find something as robust as this appears for Linux. Now, lets see if I can get it to work this weekend. If so, my boss may not have $350 in phone calls just to me next month. Thanks!

Re:But....

[boletus]

here are some files from the mailing list which
address your concerns.

-- boletus
================================================
First mail in thread
-----------------------------------------------
The SpeakFreely for Linux Mailing List

Hi!

I'm glad that my friend contributed his setup for two machines, one
running Linux 2.2 and connected to the internet with a regular IP address.
The other (on the local network) is being masqueraded having a private IP
address.

The trick is to _masquerade_ outgoing packets and to _forward_ incoming
packets. However, you'll need kernel 2.2 for this to work, AFAIK.

Questions should be posted to the Speakfreely for Linux mailing list
.

Regards, Walter

--
Walter Haidinger
For further information, such as address or PGP public key,
please refer to: http://members.kstp.at/wh/index.html
================================================ =
foo script
------------------------------------------------ -
#!/bin/bash

#
# Linux kernel 2.2 masquerading/forwarding rules for Speakfreely
#
# Required tools:
# * ipchains (http://www.rustcorp.com/linux/ipchains)
# * ipmasqadm (http://juanjox.linuxhq.com)
#
# Notes:
# * The man page of ipmasqadm tells which kernel options are needed
# * There is a IPCHAINS-HOWTO available at the ipchains webpage.
#

alias ipchains=echo
alias ipmasqadm=echo
set -v; set -x # uncommend to debug

# -------------------------------------------------- ------------------

#
# Ports used (speakfreely requires 2 ports for data
# and control packets, udp only)
#
# LWL uses 2076/tcp and isn't supported here.
#
SF_PORT=2074

SF_NEXT_PORT=$((SF_PORT+1)) # 2075

#
# The IP address of the local (i.e. masqueraded) host.
# Usually a private address.
#
SF_MASQ_HOSTIP=192.168.10.11

#
# The local network of which host $SF_MASQ_HOSTIP is a member of
#
SF_MASQ_NET=192.168.10.0

#
# The IP address of the _masquerading_ host. Usually _not_
# a private address.
#
SF_REAL_HOSTIP=123.012.321.210

#
# Name of the interface that connects to the internet
#
INTERFACE=eth0

# -------------------------------------------------- ------------------

#
# Accept connections to local from anywhere
#
ipchains -A input -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -j ACCEPT

#
# Masquerade packets from local to remote
#
ipchains -A forward -s $SF_MASQ_HOSTIP -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -i $INTERFACE -j MASQ

#
# Allow connections to remote sfspeaker from anywhere
#
ipchains -A output -s 0/0 -d 0/0 $SF_PORT:$SF_NEXT_PORT \
-p udp -j ACCEPT

#
# Forward ports to the masqueraded network
#
ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_PORT \
-R $SF_MASQ_NET $SF_PORT

ipmasqadm portfw -a -P udp -L $SF_REAL_HOSTIP $SF_NEXT_PORT \
-R $SF_MASQ_NET $SF_NEXT_PORT
================================================
replies to first item in thread:
first reply:
------------------------------------------------
The SpeakFreely for Linux Mailing List


F***!
Please remove or comment the following three lines in the previously
attached script:

alias ipchains=echo
alias ipmasqadm=echo
set -v; set -x # uncommend to debug

Just left over from debugging...
Sorry.

Walter

================================================ =
second reply
------------------------------------------------ -
Walter Haidinger wrote:
>
[SNIP]
>
> SF_PORT=2076
> SF_MASQ_NET=192.168.10.20
[SNIP]

This is a really reply to: Walter Haidinger, Brian Winters, Dave
McCracken, and Ivan Kocher.

Given the current situation, Speak Freely can't be used behind masq
without special setup on the masq gateway, and even with special setup
it can be only fully used by one machine behind the masq. (Walter's
solution above isn't functional for outgoing calls, as the new port
number is never received by the remote copy, which sends to 2074.) I see
three possible solutions for this, none of them perfect.

First: Making Speak Freely a connection-based UDP program like ICQ,
which sends to the port it received data from, instead of a fixed port.
This solution is the best IMHO for the long term. Multiple users could
use speak freely from behind the masq, even conversing with the same
person! The single problem with this is that it would break
communication with older versions of Speak Freely. A call couldn't be
made directly to any specific machine behind the masq without a port
forward, but that is the case with all masq applications. Incoming calls
would come to port 2074, and would be handled by either a local
sfspeaker, or be forwarded to a default host as any other service would
be. This is Ivan's Suggestion.

Second: A userspace proxy that runs on port 2074 on the gateway, reads
the packet's host, and based on that sends the packet to the appropriate
host based on the contents of /proc/net/ip_masq/udp. Such a proxy would
be trivial to write, and would allow multiple machines behind the masq
to use Speak Freely at a time, if they are conversing with different
hosts. Another disadvantage is that the incoming audio will appear as a
separate incoming connection from the gateway machine to the calling
machine, but that is an aesthetic issue only. The proxy would have to
have some caching logic to operate efficiently, as reading and parsing
/proc/net/ip_masq/udp for each packet would have quite a bit of
overhead. Incoming calls would be sent to a default host specified in
the configuration, or to a sfspeaker running on another port on the
gateway. This is my suggestion, inspired by the "sfproxy" that used TCP
and required a modification to Speak Freely itself.

Third: A proxy as mentioned above done in a kernel masq module. This
would have direct access to the raw masquerade tables, so it could cut
back the overhead mentioned above, and simplify the code a bit. The
incoming audio could also be made to look as if it was coming directly
from the host, not the gateway. The "different host" rule of above
applies, as there is no easy way to distinguish packets for different
internal computers aside from hostname. In addition, writing a
kernelspace module is more difficult than a userspace proxy because of
the rules, e.g.: no floating point math, subtle locking issues on SMP,
etc. This is Dave's Suggestion.

If you can think of any better ideas, feel free to toss them onto the
list.

--RZG

(OBSpeakFreelyBug: Sometimes when one party tries to close a connection,
he is unable to since the keepalives from the other side reopen it. It
there a close command sent down the line? Should Speak Freely for
Windows ignore keepalives from a specific host for a set time after it
closes a connection to that host? Or am I missing something?)

================================================ ==
third reply
------------------------------------------------ --
The SpeakFreely for Linux Mailing List

On Fri, 3 Sep 1999, Reuven Gevaryahu wrote:

> it can be only fully used by one machine behind the masq. (Walter's
> solution above isn't functional for outgoing calls, as the new port
> number is never received by the remote copy, which sends to 2074.) I see
> three possible solutions for this, none of them perfect.

The remote machine has know that port x is forwarded to machine y on the
local network. That is, both participants have to know exactly which port
to use. Of course, this _is_ very inconvenient but it is suitable for at
least a small set of machines until there's a transparent solution.

This may have been asked before, but does somebody care/like/desire to
write a masq module/proxy for speakfreely? ;-)

--
Walter Haidinger
For further information, such as address or PGP public key,
please refer to: http://members.kstp.at/wh/index.html

Re:Source code not released?

[Haven]

Its exactly like Al Gore's Open Source Web Site

Re:very nice

[Anonymous Coward]

encrypted text communication? You want gale.

http://www.gale.org./ [www.gale.org] It's still kind of in flux though.

Re:^ = Score=-1, Uninformed

[whocares]

The person who replied was correct, toll quality voice takes very little bandwidth. The phone system packs 24 voice calls per T1, and those each only use a small bit of the bandwidth allocated to them. That's part of why VOIP is being implemented by telcos to begin with, becase it's a much more efficient use of resources. Of greater concern is latency, which is highly noticeable in voice conversation, as it's interactive. Compare loading a web page over a high-latency link to using a telnet session to gauge importance of latency, I'm sure you'll agree. :) And most dialup connections *are* high latency.

Re:But....

[Haven]

The command for you the newer linux users is :

ipmasqadm portfw -a -P tcp -L [insert internet IP here] [insert port here] -R [insert private network ip here] [insert port here]

take out the "["'s

You can get the best encryption if you set up something called "Cipe" between 2 Linux Boxes using IP_MASQ. Its Virtual Private Networking that uses 128bit encryption. The info is here [sites.inka.de] and here is the HOW-TO [linuxdoc.org].

Not yet Open Source

[Bruce Perens]

I wrote Phil about the license. Perhaps we can work something out.

Thanks

Bruce Perens

Perhaps gphone...

[CNPOS]

Gphone is a gtk based (it *might* be a curses based as well) internet phone that uses gsm compression. The author states that it may well be possible to tunnel the connection through an ssl socket instead of its usual tcp socket. Anyone attempt this?

If you can view it you can clone it..

[MikeFM]

While maybe the source isn't GPL it isn't a total waste. This allows the protocols and even the interface (if it's anygood) to be cloned by OSS coders. That would mean a GPL'd Linux version rewritten from scratch could communicate with already existing Windows and Mac versions while the port of the GPL version to those platforms was taking place. It also means peer review of the source can be going on which of course means a lot with good security. It'd be awesome to get high quality, cross-platform, secure Internet phone software working in time to be an optional part of Mozilla. Overall this is no worse than StarOffice IMO. I'd imagine it should be far easier to clone as not as much shit is loaded into UI code.

Drop PGP out and GPL the rest

[decaym]

I find the whole thing rather dubious myself. If NAI has no intention of ever marketing the product, then they should just consign it over to the GPL and be done with it. This looks a little too much like they are looking for some free developer time before repackaging the product and distributing it with their own suite of software

If the issue is PGP/NAI wanting to protect their licensed (and money making) encryption library, then they have an easy way around that. Leave it out! Release the rest of the software under the GPL and then the developers out there can just paste in the GPG library to accomplish the same encryption.

I first looked at this software several years ago and loved the concept. My boss liked it as well. The problem at the time was the export restrictions, so it could not be used for communicating with people overseas. Considering that industrial espionage is a signicant player in some emerging markets, there is certainly a demand for such a product out there. Getting this product out of the US and into an open development community could really help many business interests.

OpenPhone / OpenH323

[gherlein]

There are more Internet Telephony options available, and encryption is an option in many of them.

The OpenPhone Project [openphone.org] aims to make it easier for this kind of software to get built. Other good links include:

OpenH323 Project [openh323.org]

Linux Telephony [linuxtelephony.org]

Voxilla - More Linux Telephony [voxilla.org]

Umm... Isn't that illegal?

[DiningPhilosopher]

Wouldn't any clone not developed in a cleanroom environment be in violation of copyright? I would think anyone wanting to make a comparable product shouldn't go anywhere near this source code.

OTOH, you're entirely correct about the code review, which is the reason why this release is important. Auditable source code for security software is incredibly valuable.

In my opinion this is the reason why the code has been released for viewing but not opened. They lose no money on sales and gain verifiability. Good move.

.as

[um... Lucas]

Phil probably signed all the code with his key, so as to make it harder for the code to be tampered with on its journey from him to you. Get PGP, which should come with Phil's key, and then verify all the packages.

At that point the .as will go away (are you sure its not .asc?) and you can be happy...

My hunch.

Re:OpenPhone / OpenH323

[resist]

It would be real nice to see encrypted audio and video in OpenH.323. Unfortunately for crossplatform people, there is no Mac H.323 client. A modern machine (P3/Athlon, PowerPC750) should be able to handle H.263 video, maybe Purevoice or G.711 audio and still encrypt the signal.

Re:this iz real bad!!!!!

[Anonymous Coward]

We at the CIA, FBI, NSA, MI6, Microsoft, Intel, AntiOnline, L0pht, Geek Compound, (insert favorite evil-agency-of-doom[tm]
here) would like to apologize in advance for the above post. We paid this poor fellow more than enough to buy his medication, but he went and spent it all on buying more copies of Microsoft Windows NT for his networks. He has been severely punished, and sent to a mental hospital in Siberia.

Encryption is bad. Big brother is good. The Psi Corps is your friend. Trust the Corps. The Corps is mother, the Corps is father.

Zog.


All trademarks are either property of their respective owners, or just do not exist.

PGPphone never caught on with the Windows crowd?

[Redundant()]

Guess that just proves that people in general are lazy and don't want to be bothered with the details of key handling and doing a little hacking on their own to get an application to run.

Since the average Linux user has a little more technical skill than those from the windows community, this application is a lot more likely to find a home.

This application could hurt the long distance carriers if too many people jumped on the bandwagon, so don't expect to see the media hyping free secure long distance with Linux anytime soon!

Re:Source code not released?

[Inigo Montoya]

Huh? Mozilla? why do I want a phone in my browser??

Re:dialup latency

[Bill Currie]

And most dialup connections *are* high latency.

True, but you can tell your friends you're on the moon and they might beleive you:)

Seriously, 500ms (250ms for each modem) base latency probably isn't too bad and people should be able to adjust to this. It can't be any worse than making an international call through satellite bounce (I've done it a couple of times, pretty cool IMHO, but then I;m wierd:).

100ms

[Mr Z]

Actually, from what I understand, the normal ettiquette of a spoken conversation starts breaking down once the one-way travel time gets above around 100ms. (eg. a Round-Trip Time of 200ms.) Something like the gamer's modem might be nice here. :-)

--Joe
--

Re:very nice

[dmv]

I've been waiting for them to do encrypted messaging.

Good encrypted messaging takes a lot more protocol work than just slapping it on a present protocol. Check out [cmu.edu]
Caliban for a protocol and program which has been working on this.

there's a neato commercial product that does this

[Firehawk]

http://www.ezfone.com/

unfortunately, though, I suspect the software is Windows only ... the idea of a card (unfortunately ISA too) that has a phone jack is a great idea though...

Re:.as

[steve_bryan]

Before I start complaining I'll try to answer some questions. The ".as extension" is a question I had and posted to some newgroups. I didn't get an answer there but in an email exchange with someone in Australia I learned it stands for AppleSingle which is used to encode binary files when they are stored on file systems that don't support resource forks. If one is sufficiently curious to examine the AppleScript file in the root directory (I wasn't because it promptly crashed and/or failed when I rashly ran it), it is fairly clearly indicated what that extension means. Oh well. The only utility I could find initially to decode the binary files is StuffIt Deluxe which I don't own. I know Eudora Pro handles it in attachments and some CVS clients will also but the user interface is wrong. (Commit the files to a CVS archive and when checked out they are converted to customary Mac files). Anyhow that is only one problem and there is a more serious problem with the Mac archive (and probably the Windows archive also). They didn't post enough of the source tree to allow for successful compilation. If you get the full source archive for all the PGP products from www.pgpi.com (available already for Windows and soon for the Mac) those missing directories are supplied. Hint number three is to use Metrowerks PR3 unless you enjoy the challenge of porting to the most recent version of universal headers and the current PowerPlant. (Throw in internet config headers and libraries for best results). Anyhow I have a DiskCopy archive of PR3, I managed to ftp a fairly current source tree from Switzerland and voila the Mac version compiles and runs.

Lot's of uninformed pontificating. No reason why I can't get in on the action. The source code for PGP products always gets posted publicly since at least version 2.6. That is nothing new. What Phil (no, I don't know him personally) seems to be indicating is that the particular status of PGPfone is likely to be changing soon. So he is informing everyone sooner rather than later when the lawyers have dotted all the i's and crossed all the t's. That way you can start working with the source code now (which is always posted in any case) in anticipation of participating in the future plans. This isn't some cheesy perl script gluing together some barely adequate command line tools. The goal here is a robust, interoperable attractive application that your mother could use if she were so inclined. The nature of the challenge seems not to be appreciated by many who so readily offer their innocent (of any real knowledge) opinions. Sheesh!

p.s. Didn't mean any nasty crack at Lucas who was just trying to be helpful.

What a pitty PGPfone does'nt work.

[Shanep]

Or does it?

I tried it in Windows 95 about 2 years ago over two USR 33.6 modems and it was just plain bad. I would get occasional audio back and forth but mostly just noise and silence. Nothing that could possibly support voice communication. I tried all the codecs and sampling rates, even switching encryption off!! No help at all.

So I put this down to the fact that the modems speed and latency where the culprits. Once I checked PGPfone between my 2 PC's with their 100Mbit NIC's, both having full duplex sound cards, etc, finding that the results were EXACTLY the same led me to give up on PGPfone.

Was it just my setup, or have people actually managed to get it to work well? Hopefully the Linux community will get it going perfectly.

Re:.as

[steve_bryan]

I get to the office, mount the drive that has the archive of the earlier release of CodeWarrior and discover it is PR4, NOT PR3. I don't think anyone has had the opportunity to try what I described but I wanted to make certain accurate information was left here.