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.

Comments

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.

Re:Source code not released?

[Haven]

Its exactly like Al Gore's Open Source Web Site

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,

Hmmmm

[Gleef]

I wonder if a program like this, combined with a phone like the Qualcomm pdQ Smartphone 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).

----

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

Roland

very nice

[G27 Radio]

I've been following the Jabber 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

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!

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

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.

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

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

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: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 and here is the HOW-TO.

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: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:^ = 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.

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?

OpenPhone / OpenH323

[gherlein]

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

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

OpenH323 Project

Linux Telephony

Voxilla - More Linux Telephony

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: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:).