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.

10 of 150 comments (clear)

  1. typo by Yahweh+Doesn't+Exist · · Score: 5, Funny

    >His first release is Mac & Linux only.

    you misspelled Windows.

    oh... that makes a refreshing change.

  2. My only concern by QuaintRealist · · Score: 5, Interesting

    ...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
  3. Why not encrypt by default by Matt+Perry · · Score: 5, Interesting
    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?

    --
    Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
    1. Re:Why not encrypt by default by Noksagt · · Score: 5, Insightful
      • 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.


  4. Re:Releasing the source by HolyCrapSCOsux · · Score: 5, Insightful

    Wouldn't that kinda be the point?

    --
    0xB315AA8D852DCD3F3DCA578FD2E0BF88
  5. Encryption is hard by user9918277462 · · Score: 5, Informative

    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.

  6. Related project by Anonymous Coward · · Score: 5, Interesting

    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.

  7. Ob. Simpsons Ref by magefile · · Score: 5, Funny

    Could Phil microwave a burrito so hot even Jon couldn't eat it?

  8. Re:Why not use OpenSSL? by rodac · · Score: 5, Informative

    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.

  9. My security fears by webweave · · Score: 5, Interesting

    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.

    http://www.motherjones.com/news/feature/1994/05/dr eyfuss.html

    http://web.nps.navy.mil/~relooney/4141_Spring2002. pdf

    http://www.commondreams.org/headlines/070200-02.ht m

    Not using encryption is to believe GWB when he says "Trust me"