Slashdot Mirror
PGP Creator's Zfone Encrypts VoIP
Philip Zimmermann, creator of PGP wrote in to tell me about
Zfone, his new system for encrypting any SIP VoIP voice stream. His first release is Mac & Linux only. I tested it with him using Gizmo as our client and it was pretty trivial to use. While it should work on most any SIP compatible VoIP client, he hopes that clients like OpenWengo and Gizmo will incorporate Zfone directly into the UI.
Zfone has no centralization, and has been submitted to the IETF.
He hasn't yet determined a license, but he believes strongly in releasing source code for all encryption products. A windows client is forthcoming.
...is that the US (yes, I live there) will use security fears relating to terrorism to ban or severely restrict this technology. Some elements of our government seem almost Luddite (http://en.wikipedia.org/wiki/Luddite) these days.
Sad, because this kind of encryption would permit greater use of this technology in medicine under HIPPA privacy regulations.
Using plain ol' text since 1968
If he releases the sources won't companies like Vonage that are being subjected to voip packet throttling from copetitive ISPs just take it and use this technology for free?
Visit my site @ http://www.madtorrent.com
Would it be useful to have the option, for those of us who have friends' PGP keys, to do the Zfone key handshake via PGP encryption that rather than verifying something by voice? It's fantastic from a "getting people to use it" perspective that it does not rely on PKI, but those who have already taken the plunge shouldn't be punished :)
We know the network is hostile and retrofitting encryption onto something after the fact doesn't always work either because too many people using the unencrypted protocol, it's too hard to configure (as opposed to being mostly automatic like ssh connections), or just general security ignorance. What's really holding us back?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
great idea, this is very much needed. I don't know how secure this actually is, the writer (phillip zimmermann) said he builds the encryption into tcpstack of whatever operating system the user is running and the key exchange is done automatically between hosts.. he also makes the statement that this technology/standard (zfone) would be integrated into the end-user software, in the near future. I'm not sure why he's so confident, it's nice but who's to guarantee any sip softphone end-points or better yet, hard telephones, will actually have this built in.
hmm.. i wonder if I have linux nat router running this (and it being my default gateway, if it will automatically encrypt any sip sessions if the end system is running the zphone gui. I mean this apparently works at the network layer (like tcpdump, promiscuously), I wonder if it has to be running on the same system the sip session is originating from. oh dear, i really need to replace my dlink router these days.
What's the difference between this and SRTP?
There was a presentation from another group (wasn't Phil, although he was there) at DefCon 13 relating to reverse-engineering the GSM voice compression so that data could be fed through a GSM voice link accoustically with almost no overhead (in other words, at close to the GSM native digital bandwidth). The intent being to provide a means to attach accoustic peripherals (handsfree headset for example) that could perform encryption and send the encrypted, digitized voice over the GSM link accoustically (to be recieved and decoded by a similar device on the other end), thus allowing encrypted voice communication over an untrusted and unmodified cell phone without the need to install any software.
SIP is just a protocol that sets up connectivity and media control; the stream itself is not covered by the SIP protocol. For that, you need something that supports Secure RTP (SRTP), which encrypts the payloads of all RTP streams. If you've managed to encrypt SIP, all you're doing is encrypting call setup and feature requests. Your conversation is not encrypted.
I don't live in the US but I live very close and almost all of my IP traffic travels through the US at some point and my worry is that any business information collected by the US/CIA/FBI or other US agency would be made available to US companies. There have been court cases in the past of US sponsored spying benefiting US companies. They say they are after terrorist but who knows? With the knowledge of past activities of US spies and the current computing power of the US agencies all foreign businesses would be well advised to encrypt all sensitive information.
r eyfuss.html
. pdf
t m
http://www.motherjones.com/news/feature/1994/05/d
http://web.nps.navy.mil/~relooney/4141_Spring2002
http://www.commondreams.org/headlines/070200-02.h
Not using encryption is to believe GWB when he says "Trust me"
That's because you skipped the hardest step - the out-of-band communication necessary to establish key authenticity. The first time you connect to a host via ssh, it displays a fingerprint and asks you if it should be trusted. Most people don't value encryption enough to even bother installing the relevant software, what makes you think that they value encryption enough to figure out a way of validating the fingerprint securely?
At the risk of summoning the ire of cryptographers everywhere:
So what.
Skip the whole fingerprint validity thing - I do all the time. I never call the sysadmins of machines I'm using to make sure their self-signed certs are really them (mail, https, ssh, whatever). It has bit me 0 times. As far as I'm concerned, that answer is just an excuse to dismiss a trivially simple 90% solution. As a matter of fact, my system uses secure SMTP (what's the right acronym?) in it's MTA. Nobody validates SMTP's keys for sending - they just trust the message is going to the right machine and sends it encrypted. Folley! But it works fine.
But partial security is worse than no security!
BS. There is no total security. Someone can always root that machine and get your password.
In the meantime we have VNC in the clear, because "encryption is hard to do".
Total security is virtually impossible. Encryption is pretty easy, and we'd all be better off using more of it.
You're proposing using a system with known design vulnerabilities. See my comment above re: false security vs no security at all.
As soon as you add key management into the mix (which is absolutely crucial and, due to the strength of modern ciphers, becomes the keystone of security) things get very complicated very quickly (as you allude to wrt SSH).
That is not to say that it is an insurmountable problem: an example is web browser SSL. The mechanics of key authentication and distribution are actually quite complex, however this is hidden almost entirely from the user. This is done through a large and relatively robust crypto infrastructure which was created because commerce makes SSL necessary. The public's right to privacy does have the same corporate backing.