Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

PGP Creator's Zfone Encrypts VoIP

Posted by CmdrTaco on Tue Mar 14, 2006 09:12 PM
from the so-stupid-easy-i-can-use-it dept.
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.
+ -
story

Related Stories

[+] Ask Slashdot: How do You Protect Your Online Privacy? 129 comments
P asks: "In the light of the recent discussions about on-line privacy: What can one do to protect his/her on-line privacy, while still having a enjoyable web experience? For example, are you using PGP for all your emails and Zfone for all your VOIP traffic? Or are there better ways of protecting oneself? Share your tips and tricks."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • typo (Score:5, Funny)

    by Yahweh Doesn't Exist (906833) on Tuesday March 14 2006, @09:16PM (#14921002)
    >His first release is Mac & Linux only.

    you misspelled Windows.

    oh... that makes a refreshing change.
  • My only concern (Score:5, Interesting)

    by QuaintRealist (905302) * <quaintrealist.gmail@com> on Tuesday March 14 2006, @09:18PM (#14921010) Homepage Journal
    ...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 [wikipedia.org]) these days.

    Sad, because this kind of encryption would permit greater use of this technology in medicine under HIPPA privacy regulations.
  • Important Stuff (Score:5, Insightful)

    by WebHostingGuy (825421) * on Tuesday March 14 2006, @09:21PM (#14921017) Homepage Journal
    This is important stuff as more and more phone traffic is routing open in the internet. While most people do not believe their emails are totally private, when it comes to talking on the phone I believe there is a perception (and assumption) that no one else is listening. SIP, Asterisk and all the flavors of VOIP is changing telecom and encryption is necessary.
    • by maillemaker (924053) on Tuesday March 14 2006, @09:48PM (#14921146)
      Hopefully, this will be the straw that breaks the camel's back.

      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
  • by MDMurphy (208495) on Tuesday March 14 2006, @09:24PM (#14921030) Homepage
    For some reason I got to thinking about Phill Zimmerman and DVD John [Johansen]. Both seem to pop up now and then and give us all reasons to smile.

    Hmm... I wonder if Phil could come up with security that Jon couldn't find a way around?
    • by magefile (776388) on Tuesday March 14 2006, @09:54PM (#14921174)
      Could Phil microwave a burrito so hot even Jon couldn't eat it?
    • Re:Phil and Jon (Score:4, Insightful)

      by merreborn (853723) * on Tuesday March 14 2006, @10:09PM (#14921253) Homepage Journal
      I'm sorry, did I miss the story about DVD John breaking the public key encryption model? And blowfish? And the cypher du-jour?

      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_pr ojects [wikipedia.org]
      • Re:Phil and Jon (Score:5, Insightful)

        by Jah-Wren Ryel (80510) on Wednesday March 15 2006, @12:27AM (#14921864)
        He's released cracks for various pieces of software, but it's not like the guy's actually broken actual strong encryption algos.

        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.
  • by Matt Perry (793115) on Tuesday March 14 2006, @09:37PM (#14921094)
    This article has me wondering about something. Why aren't we encrypting things by default? Why isn't encryption being built into the protocol when it's designed? It always seems that it gets tacked on afterwards, if at all, and we're worse off in the long run for it. Take VNC for example. If you want that encrypted you're told to send it over SSH. Wouldn't it be great if VNC traffic was encryped by design right from the start? The same applies to any other traffic (VoIP, IM, whatever). What happens is that many people don't encrypt because of the difficultly or they don't know any better. Unencrypted traffic is sent putting them at risk.

    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)

      by user9918277462 (834092) on Tuesday March 14 2006, @09:45PM (#14921134) Journal
      Because encryption is very difficult to do correctly. And we should all know by now that a false sense of security is worse than no security at all.

      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.
    • by Savage-Rabbit (308260) on Tuesday March 14 2006, @09:53PM (#14921168)
      This article has me wondering about something. Why aren't we encrypting things by default? Why isn't encryption being built into the protocol when it's designed? It always seems that it gets tacked on afterwards, if at all, and we're worse off in the long run for it. Take VNC for example. If you want that encrypted you're told to send it over SSH. Wouldn't it be great if VNC traffic was encryped by design right from the start? The same applies to any other traffic (VoIP, IM, whatever). What happens is that many people don't encrypt because of the difficultly or they don't know any better. Unencrypted traffic is sent putting them at risk.

      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.
    • by Noksagt (69097) on Tuesday March 14 2006, @10:07PM (#14921246) Homepage
      • Technological
        • Encryption implementation isn't free.
        • Encryption maintenance isn't free.
        • Unencrypted traffic is easier to sniff (which may be legitimately important).
        • Encrypyed traffic has a higher CPU overhead (which isn't always made up for).
        • Some people prefer to have one really good encryption program (SSH or a VPN) to route all traffic over.

      • Legal
        • Encryption can't always be exported from every country to every other country.
        • Sometimes it may be illegal to encrypt traffic.


    • by chefmonkey (140671) on Tuesday March 14 2006, @11:09PM (#14921480)
      Why isn't encryption being built into the protocol when it's designed?

      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.
  • by Anonymous Coward on Tuesday March 14 2006, @09:47PM (#14921141)
    As there is no cryptographic signature on the package, these are my sums
    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.
  • by Noksagt (69097) on Tuesday March 14 2006, @09:49PM (#14921152) Homepage
    I can remember Phil's PGPfone [pgpi.org] which was released before VoIP was "the next big thing." It used GSM speech compression and 3-DES/CAST/Blowfish cryptography "to give you the ability to have a 'real-time' secure telephone conversation" (directly over 14.4 Kbps (or faster) modem-to-modem, through the Internet, or through AppleTalk).

    That died. It is good to see a new alternative that has adopted newer standards.

    Another "oldy but goody" was Speak Freely [speakfreely.org].
  • Related project (Score:5, Interesting)

    by Anonymous Coward on Tuesday March 14 2006, @09:51PM (#14921158)
    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.
  • by gizmonic (302697) * on Tuesday March 14 2006, @10:38PM (#14921364) Homepage
    Philip Zimmermann has apparently vanished from the face of the earth. Film at 11.

    • by rodac (580415) on Tuesday March 14 2006, @11:46PM (#14921658) Homepage
      VoIP is different from most other traffic types in that it is hard realtime and needs real low latency. This means VoIP uses UDP

      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.
      • by Cthefuture (665326) on Tuesday March 14 2006, @11:56PM (#14921708)
        OpenSSL is not just an SSL API. It's a full cryptographic API. The socket stuff is not even in the core crypto library. There is libssl and then there is libcrypto. Both are part of OpenSSL.

        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.