PGP Creator's Zfone Encrypts VoIP 150
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.
typo (Score:5, Funny)
you misspelled Windows.
oh... that makes a refreshing change.
Re:typo (Score:2)
The article actually says all three: "The current Zfone software runs in the Internet Protocol stack on any Windows XP, Mac OS X, or Linux PC". But yes, very refreshing.
My only concern (Score:5, Interesting)
Sad, because this kind of encryption would permit greater use of this technology in medicine under HIPPA privacy regulations.
Re:My only concern (Score:2, Interesting)
Entirely off topic, but it'd be nice if
If you use that idea, Taco, I want a piece of the action!
Re:My only concern (Score:4, Insightful)
Re:My only concern (Score:1)
Re:My only concern (Score:2, Insightful)
Even then I'm sure that there will be attempts by the US Government to
prevent its use.
This is a significant advance in the search for privacy.
Does it matter??? (Score:2)
Re:Does it matter??? (Score:2, Informative)
There are prohibitions on export in the (many) terms to which you have to agree.
How long before it's all over the world?
It would also.. (Score:4, Insightful)
Re:It would also.. (Score:1, Informative)
No it wouldn't. This system doesn't use steganography to hide its protocol, so it's obvious to any application layer sniffer. It also does nothing to hide traffic data, i.e. source and destination addresses. That requires something like Tor [eff.org]. Telcos can selectively degrade service based on protocol and traffic analysis.
The only thing this would prevent is shaping based on the c
traffic shaping reality check (Score:1)
Tangentially, let's not forget that sometimes one *wants* to be able to shape traffic. If you can't tell a voip call from an evercrack connection, they both get equal priority, and that's bad news for your mom and 911.
--Naomi
Re:traffic shaping reality check (Score:4, Insightful)
Re:It would also.. (Score:1)
Re:It would also.. (Score:5, Funny)
Is that shorthand for steganography?
Re:It would also.. (Score:1)
Thanks,
Re:It would also.. (Score:3, Funny)
Not really, - no coconut = 0, with coconut = 1.
(I suppose the VoIP equivalent would be TCP/IP over parrot?)
Good thinking. I wonder how many parrots each pigeon could carry.
Re:My only concern (Score:2, Insightful)
Believe it or not, you actually live in a (somehow) free country.
Well said (Score:2)
You remind me of the Churchill quote. You know, the one about democracy being the worst system of government except for all the others.
Encryption (Score:4, Funny)
Re:Encryption (Score:4, Funny)
no, sorry, you can keep Bush... do not share him...
Re:Encryption (Score:2)
Re:Encryption (Score:2)
Re:My only concern (Score:1, Funny)
My security fears (Score:5, Interesting)
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"
Re:My security fears (Score:2)
Re:My only concern (Score:2)
oops (Score:2)
You'd be amazed what a practice like ours spends on long distance. So we'd love to use VOIP, but our HIPAA officer freaks out about stuff that's not specifically covered in the regs.
Important Stuff (Score:5, Insightful)
I agree, it is hugely important (Score:5, Insightful)
Ultimately, ALL traffic should be encrypted, whether it is VOIP, email, web browsing, whatever.
The guy is right when on his home page he talks about how it is so difficult to implement this sort of stuff as an add-on for emails, managing keys and the like. It's why no one does it. Of course, there has always been a computing overhead, also, which is why only pages that "need" to be secured currently are. But as horsepower goes up, those limitations should go away.
Ultimately, it should be a matter of course before all traffic that goes in our out of your computer is encrypted by default.
Hopefully this is the start of something huge!
Steve
Re:I agree, it is hugely important (Score:2)
Re:I agree, it is hugely important (Score:3, Insightful)
Re:I agree, it is hugely important (Score:4, Informative)
Re:I agree, it is hugely important (Score:3, Insightful)
Re:I agree, it is hugely important (Score:4, Informative)
For https and such, setting up the connection is the majority of the work. Public-key key exchange (public-key certificates, Diffie-Hellman, etc.) is an expensive operation because it requires a modular exponentiation on the part of the server. However, once the connection is set up, the cost of encrypting each packet is extremely small.
Melissa
Wwwaaaaaaahhhhh! (Score:2)
Thanks to Moore's Law, encryption is cheap -- but it's still not free. That's OK for things like E-mail, where the two end-systems handle only a handful of messages at a time. But if the Web suddenly switched from HTTP to HTTPS overnight, Web servers would collapse left and right from having to juggle thousands of simultaneous encrypted connections. Plus, the overhead for setting up an encrypted lin
Phil and Jon (Score:5, Funny)
Hmm... I wonder if Phil could come up with security that Jon couldn't find a way around?
Ob. Simpsons Ref (Score:5, Funny)
Re:Phil and Jon (Score:4, Insightful)
He's released cracks for various pieces of software, but it's not like the guy's actually broken actual strong encryption algos.
http://en.wikipedia.org/wiki/Jon_Johansen#Other_p
Re:Phil and Jon (Score:5, Insightful)
And such 'cracks' are the best way to attack otherwise strong crypto-systems - don't try to crack an algorithm -- crack the implementation. Look for the vulnerabilities in the systems that use strong cryptography and find the back-doors, or break in a hole in the wall, but trying to go mano-a-mano with the entire crypto community isn't a smart thing and you are exactly right -- that isn't what DVD-Jon has ever done.
Not that I would imply that CSS is a strong algorithm, it ain't. But the new stuff for BLU-HD-RAY uses AES and the stuff that the Zim-man is using to security VOIP also uses tried and true crypto algorithms. That doesn't mean there won't be flaws in the implementations that can be exploited and Jon-Jon He's Our Man, If He Can't Exploit It, No One Can!!! Yeah Jon. Or something like that.
Releasing the source (Score:2, Interesting)
Re:Releasing the source (Score:5, Insightful)
What ever happened to PGP Phone? (Score:3, Insightful)
Was it just too far ahead of its time?
Re:What ever happened to PGP Phone? (Score:1)
Re:What ever happened to PGP Phone? (Score:3, Informative)
Re:What ever happened to PGP Phone? (Score:3, Informative)
No PKI? (Score:3, Interesting)
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 :)
Why not encrypt by default (Score:5, Interesting)
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?
Encryption is hard (Score:5, Informative)
There's also the not insignificant fact that encryption is complex to use and administer. Adding in robust encryption is not free from a user-friendliness perspective. Much thought has to be put into reducing the user-visible complexity as much as possible so that the user base will actually use the encryption, and use it in such a way that security is preserved. Not trivial.
Re:Encryption is hard (Score:2)
Wanna encrypt VNC?
ssh -L 5900:localhost:5900 somehost.org
vnc to localhost:5900
Was that hard? No.
Why isn't that built into VNC? Because it's hard? No. Most of the reasons are probably legacy export concerns. But I don't think all of it is.
Note that openssh.org is hosted in the netherlands. I don't think that's entirely coincidental.
Securing a socket in cocoa seems to be a single method call on NSStream.
So
Re:Encryption is hard (Score:3, Insightful)
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 v
Re:Encryption is hard (Score:3, Interesting)
At the risk of summoning the ire of cryptographers everywhere:
So what.
Skip the w
Re:Encryption is hard (Score:2)
Re:Encryption is hard (Score:2)
This was the telnet attitude for decades. And then people
Re:Encryption is hard (Score:2)
Exactly the response I was looking for. This is not testing, and I never said it was. I was basically saying that even though I know what fingerprints are, I ignore them. The way I use ssh is clearly "not total security", and it would be easy to prove that. But you can never really prove security, can you - you can only say that you believe something is secure, and that it hasn't been stolen, yet. In the case of binary data, you can't really even say that, can you - because
Re:Encryption is hard (Score:2)
It's not just the endpoints that you should be worried about. Even if the system you're trying to reach is uncompromised, one of the untrusted systems in the communications pa
Re:Encryption is hard (Score:2)
Yup. Got it.
The point of a lock is just as much authentication as it is protection. Encryption without authentication is like a strong lock that accepts any key: you don't have to break the lock to get inside. Similarly, encryption is useless for secure communication in the absence of correspondingly strong authentication.
And here is where I totally disagree. Having a good lock is no better than your key
Re:Encryption is hard (Score:2)
Re:Encryption is hard (Score:2)
Re:Encryption is hard (Score:2)
Re:User friendly encryption.. (Score:2, Interesting)
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
Re:Why not encrypt by default (Score:5, Informative)
There are lots of reasons why encryption isn't being widely used. For one thing there is the normal tinfoil hat reason, ie. that the people in charge don't want it becausy they wouldn't be able to stick their nose where it don't belong so they try to prevent such technology from being widely used. Alot has also to do with cost and computing overhead. Encrypting can be an expensive thing to do in terms of computing power and especially so if everything form all the network communications protocols to storage media content is bening encrypted. Doning encryption with special hardware is one solution but that adds cost and also the problem of the hardware algorithms becoming obsolete like WEP for example. Just try to get ahold of, say a 100mb photoshop file. Now copy it into the user home directory of a regular user on an OS.X machine, then do the same for antoher user using 'File Vault'. You will quickly discover that the latter operation takes alot longer since those 100mb's of Photoshop file are being encrypted. You should notice similar problems when comparing normal unencrypted file transfers over a network with transfers over a high strength encrypted link. VPN for example works noticably slower using port forwarding over an SSH tunnel.
Re:Why not encrypt by default (Score:5, Insightful)
Re:Why not encrypt by default (Score:1, Insightful)
I think you've answered your own question. Unix mantra: do one thing and do it well. SSH is the encrypted transport layer. No other communication layer needs encryption.
This is exactly why tar doesn't compress, and gzip doesn't make archives. If you want that tar archive compressed you're told to gzip it.
Re:Why not encrypt by default (Score:3, Insightful)
Re:Why not encrypt by default (Score:1)
By definition compression usually uses patterns in order to reduce the amount of data being send and also by definition encryption deliberately removes patterns as much as possible.
This fact is made even worse when the size of the data being encrypted is small as in (IM etc.) as it is necessary to pack the data with extra 'rubbish' data in order that it does not become trivial to decrypt, because it will no
Re:Why not encrypt by default (Score:5, Informative)
For any IETF protocol developed in the past 10 years or so, it is. For example, RFC 3261 (which defines SIP) makes TLS encryption *mandatory* to implement. It does allow the users/administrators/whatever to turn it on and off, but you can't say your implementation is RFC 3261 compliant unless it contains TLS encryption.
For most other important protocols defined before the IESG required strong security in all protocols, there have been significant efforts to revise them as necessary to provide encryption. For example, RFC 3711 defines a mechanism for encrypting RTP (the voice packets in a VoIP call).
Anyone who bothers to actually implement to spec already has released products that do encryption, many by default. For example if I use the Snom 360 SIP phone on my desk to call anyone else using a client that has actually implemented all of RFC 3261 (instead of whatever small portion of it amused them) and implemented RFC 3711, both the signaling and the media will be strongly encrypted BY DEFAULT. And that's the way it was configured when I took it out of the box.
The fact that some current implementations don't bother following spec impugns their designers and implementors, not the protocols they're using. Using the standardized VoIP protocols available today, everyone *should* be able to make encrypted calls.
I've got an easy answer... (Score:3, Insightful)
VNC? What if I'm only using it over a Cat-5 cable on a private network? Who am I encrypting it from?
You've always got FreeNet [sourceforge.net]. But you aren't using it are you?
great (Score:3, Interesting)
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.
Re:great (Score:1)
Checksums, distro needs sigged. (Score:4, Insightful)
as received. Please compare and post if yours are different.
SHA1 (zfone-linux.tar.gz) = aa9ac66a5dce43cff2639787f30e939078b47ebe
MD5 (zfone-linux.tar.gz) = c6a47feca0fd5cb5bf72a8f6a1e8f207
PRZ, please sign your packages! Thanks, World.
Re:Checksums, distro needs sigged. (Score:2)
aa9ac66a5dce43cff2639787f30e939078b47ebe zfone-linux.tar.gz
c6a47feca0fd5cb5bf72a8f6a1e8f207 zfone-linux.tar.gz
I too am rather disturbed by a lack of a signature on this package...and I suspect by the difficulty I'm having building it that it is a CVS snapshot.
SRTP? (Score:2, Interesting)
Doesn't deal with key management (Score:1)
PGPfone, Speak Freely (Score:5, Informative)
That died. It is good to see a new alternative that has adopted newer standards.
Another "oldy but goody" was Speak Freely [speakfreely.org].
Re:PGPfone, Speak Freely (Score:2)
Me too. However try as I might, with a friend at the other end of a 28.8 connection and also locally in my home between two PC's with 100Mbit/s connections, I could not get anything better than short bursts of audio to either end. It seemed like a duty cycle of about 1 block of sound out of 5 or 10 blocks of silence. A conversation could not be made.
Did you have any luck with PGPfone? I tracked it down and tried it again y
Re:PGPfone: Full duplex mode did suck (Score:3, Informative)
I seem to recall that full duplex sucked in this way on 56.6. I think I half duplex (push-to-talk) was passable. But it was also so inconvenient, so I opted to not secure voice traffic. I thought I tried it on broadband with a bit more luck. It didn't seem
Re:PGPfone: Full duplex mode did suck (Score:2)
I hope my ATA has the grunt to do both the codec work and the crypto and they adopt this if it is ratified. I've seen some tables which outline the approximate CPU requirements of various codecs against various CPU architectures often used in embedded (like MIPS). Those tables are apparently intended for choosing CPU's for VoIP devices. I hope my A
Related project (Score:5, Interesting)
Re:Related project (Score:3, Interesting)
Who needs encryption? (Score:3, Funny)
Ekiga? (Score:2)
Well... (Score:3, Interesting)
VoIP and IM (Score:1)
However, though encrypting your VoIP communications might make them more secure, they're also much more likely to be flagged by systems like ECHELON, which automatically tag traffic that is encrypted as suspicious.
Re:VoIP and IM (Score:1)
I was thinking the same thing. I am hesitant in adopting VOIP because of that.
Re:VoIP and IM (Score:2)
Re:VoIP and IM (Score:1)
--Naomi
Re:VoIP and IM (Score:2)
Perhaps, but bear in mind that if you can get your conversation with your mother about the cat's appendix operation flagged up by ECHELON as 'Possible terrorist, for further investigation' then you waste enormous amounts of their time and money, and render the system a little less useful. By dra
In other news... (Score:4, Funny)
Why not use OpenSSL? (Score:3, Insightful)
At least then you're using a public, well hammered on API and would have a multitude of algorithms to choose from. I mean OpenSSL is used in tons of stuff and gets lots of field testing.
I have never understood the point of PGP with its proprietary crap formats when there are open, standardized formats for the stuff it is typically used for (S/MIME, X509, PKCS#12, etc.) and that are supported in standard applications rather than require some goofy PGP add-on.
Re:Why not use OpenSSL? (Score:5, Informative)
OpenSSL builds encrypted sessions over TCP. TCP is not designed to work well for the requirement space needed by VoIP.
If fact, it just would not work well at all.
Re:Why not use OpenSSL? (Score:5, Informative)
OpenSSL is a misnomer.
I didn't mean "use SSL", I meant use OpenSSL the cryptographic library that supports all that standard stream ciphers. You can use whatever networking stuff you want outside of OpenSSL.
Re:Why not use OpenSSL? (Score:2)
Something similar to reverse. I did it via piping it through gpg. Trouble is, it was unbuffered. You'd need to make sure that the soundcard bitrate was set to something slow enough for the network. I'm sure sox can do it.
Getting this thing to build under Linux (Score:2)
Methinks Phil needs a Linux box!
hehehe j/k.
Has _anyone_ got this thing
What is the big deal? (Score:3, Insightful)
There is a great deal of concern over Skype being encrypted. People say it can be used by terrorists for encrypted communication. The thing is, throw up a VoIP server of some kind (Even the free ones like Ventrilo or TeamSpeak), and connect to it using something like Hamachi. Bam! All your UDP voice traffic is encrypted.
Heck, you can even do it with TCP. SSH tunnels encrypting two-way Shoutcast streams. Huzzah! Encrypted two-way voice communication! Heck, pump the shoutcast stream over HTTPS and that'd be encrypted too.
So, this is why I don't get it. Why complain about Skype when there will always be ways to encrypt voice traffic over the internet? Programs like Hamachi (Encrypted P2P VPN solution with an IM-like interface) make it insanely easy to set up more secure solutions than Skype, and there is always SSH tunnels as a fallback.
So how does this relate to the current situation? Well, people are sure to complain that this new program somehow helps terrorists. So I'm just saying that that is BS.
QoS (Score:3, Funny)
Is Phil marrried? (Score:3, Funny)
I NEED a guy like this in the family.
LK
ZFone (Score:2)
(and can you redistribute it once you've provided your email address to Phil for the download link?)
Re:ATTENTION /. MODS: DO NOT MOD THIS DOWN!!! (Score:1, Funny)
Re:A-Splode (Score:1)
-Peter