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.

Source code not released?

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.

Hmmmm

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

----

there is a secure (internet) phone for Linux

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

And...

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.

Re:But....

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

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

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

Thanks

Bruce Perens

OpenPhone / OpenH323

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]