Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

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.
This discussion has been archived. No new comments can be posted.

PGP Creator's Zfone Encrypts VoIP

Comments Filter:
  • typo (Score:5, Funny)

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

    you misspelled Windows.

    oh... that makes a refreshing change.
    • 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)

    by QuaintRealist ( 905302 ) * <quaintrealist@NOSpaM.gmail.com> on Tuesday March 14, 2006 @08: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.
    • Re:My only concern (Score:2, Interesting)

      by grub ( 11606 )

      Entirely off topic, but it'd be nice if /. supported linking to wikipedia entries with a simple tag, ie.: if you could have used [[Luddite]] in your post much like how it works on wikipedia.

      If you use that idea, Taco, I want a piece of the action!
    • Re:My only concern (Score:2, Insightful)

      by Aspirator ( 862748 )
      I presume that this will be released outside the US, and allowed to migrate in.

      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.
      • But Phil Zimmerman and his organization are not based outside the US. I'm not a lawyer, but I don't think (and maybe I'm talking out of my ass) it would matter any. If there are laws, I bet he'd be breaking them wherever he released it. He can't just put it in his pocket and walk across the border and call it good, the Black Helicopter Guys won't buy that.
        • Re:Does it matter??? (Score:2, Informative)

          by Aspirator ( 862748 )
          You're right. I have now downloaded the source, from within the US.
          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)

      by TheAxeMaster ( 762000 ) on Tuesday March 14, 2006 @08:25PM (#14921036)
      It would also almost totally negate any ISP's attempt at shaping VOIP traffic to try and get people to buy their service instead. This has been somewhat of a question in recent months, but if you can encrypt your stream, then there's not much chance they can slow your packets. I'm all for the increased security as well. Now if we can only get them to cut down on the spam....
    • Re:My only concern (Score:2, Insightful)

      by lucm ( 889690 )
      Many country have much more severe regulations against encryption technologies than the USA. Just a few years ago there was an incredibly severe law in France, stating that even domestic encryption was under the government control.

      Believe it or not, you actually live in a (somehow) free country.
      • You know - I appreciate exactly what you're saying. This really isn't a bad country in a lot of ways, but it's always easier to complain about the things that are broken than to fix them. I'm trying to do better at that, but...

        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)

      by Mark_MF-WN ( 678030 ) on Tuesday March 14, 2006 @10:46PM (#14921654)
      Let's be honest -- this guy needs to go to jail NOW. Privacy is almost as treasonous as sharing or questioning your leaders.
    • So... are you suggesting we destroy our textile machines? I've got some TNT around here somewhere...
    • My security fears (Score:5, Interesting)

      by webweave ( 94683 ) on Tuesday March 14, 2006 @11:07PM (#14921766)
      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 [motherjones.com]

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

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

      Not using encryption is to believe GWB when he says "Trust me"
    • i refuse to click on your modern fangled devil-link
  • Important Stuff (Score:5, Insightful)

    by WebHostingGuy ( 825421 ) * on Tuesday March 14, 2006 @08: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 @08: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
      • Adequate horsepower has been here for a long time, at least for basic communications such as email. A grasp of the importance of privacy (and the relevance of encryption to that end) is what is lacking. Besides, if public awareness were such that the technology were in demand, you'd see motherboards with hardware encryption and drivers already in place. Perhaps, if privacy intrusions such as identity theft (and governmental abuse) continue to increase in frequency and severity, encryption-by-default will be
      • I tend to agree that with CPU's increasing in speed and power, that the cost of encyrpting goes down. But also the cost of breaking the same codes goes down. Right now it takes 2^120 rounds to break AES encrpytion while trying to brute force. So in order for the higher speeds of the CPU argument to hold to encrypt everything, encryption technology will have to go up. Right now 128 bit is acceptable, but as speeds increase, then the encrpytion will have to be changed as well. And that will require faster pro
      • Encrypting everything doesn't help security at all. It only helps if you have some idea of who the intended recipient is. For most traffic, that's an application-specific concern, and so a general encryption mechanism is useless. For example, if I want to send email to a gmail user, and I care about it being private, I have to find a private key for the user. It doesn't help to just encrypt (great, nobody at all can read it), or encrypt it for secure transit to Google (why should I trust Google more than ot
  • by MDMurphy ( 208495 ) on Tuesday March 14, 2006 @08:24PM (#14921030)
    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 @08: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 @09:09PM (#14921253) 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 Tuesday March 14, 2006 @11:27PM (#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.
  • Releasing the source (Score:2, Interesting)

    by romka1 ( 891990 )
    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?
  • by WarlockD ( 623872 ) on Tuesday March 14, 2006 @08:31PM (#14921072)
    The MIT Website [mit.edu] has taken it down, but I remember it working somewhat well between two IP address.

    Was it just too far ahead of its time?
    • Sorry its FONE [pgpi.org] Bleh. Still wonder why no one ever maintained it
      • PGPFone was a wonderful idea. The protocol it used was messy as all hell. I talked with Phil about it in 1997; he said that it wasn't being maintained because it didn't lend itself to being extended to actually use participants' PGP keys (instead of just "I hear this voice" authentication), and that at that point all rights to it were owned by the company that had just purchased PGP Corporation.
        • As I remember, when it came out, there were patent issues with RSA in the PGP encryption. RSA owned the patents on RSA encryption used by PGP, but refused to release them for other uses, even if you phoned them up and tried to pay them for its use in another open source project. (I know: I tried.) RSA seemed more concerned aobut its inclusion in exported software than in actually making the software available. There were real USA export regulations about it, classifying encryption as a war material. Those r
  • No PKI? (Score:3, Interesting)

    by fossa ( 212602 ) <pat7@g[ ]net ['mx.' in gap]> on Tuesday March 14, 2006 @08:31PM (#14921074) Journal

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

  • by Matt Perry ( 793115 ) <[moc.oohay] [ta] [45ttam.yrrep]> on Tuesday March 14, 2006 @08: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 @08: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.
      • No, encryption isn't hard. OK, it is hard, but that's what libraries, encapsulation, etc, are for.

        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
        • by Bogtha ( 906264 )

          Wanna encrypt VNC?

          ssh -L 5900:localhost:5900 somehost.org
          vnc to localhost:5900

          Was that hard? No.

          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

          • by kwerle ( 39371 )
            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 w
            • I'm going to be heretical here and suggest that encrypting Internet communication mitigates a very small risk of compromise -- as far interception. Authentication is a different story as far as trusted certificates, etc, but that was not in the scope of the parent post (e.g., who cares about the key fingerprint). Not that I would want my ETrade sessions to go in the clear, but, if they were to go in the clear, what would happen... traffic leaves my computer, goes straight into the backbone of my major ISP
              • ... Not that I would want my ETrade sessions to go in the clear, but, if they were to go in the clear, what would happen... traffic leaves my computer, goes straight into the backbone of my major ISP (where interception and analysis would require quite a lot of behind-the-scenes treachery), bounces around amongst other backbone routers (similar situation), and then plonks off into the ETrade server where, hopefully, they're fastidious about security.

                This was the telnet attitude for decades. And then people
      • Remember the idea of opportunistic encryption? If 2 hosts both had the ability to encrypt traffic, the would no matter what the traffic was. This was actually implimented in http://www.freeswan.org/ [freeswan.org]
    • by Savage-Rabbit ( 308260 ) on Tuesday March 14, 2006 @08: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 @09: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 Anonymous Coward
      If you want that encrypted you're told to send it over SSH.

      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.
      • 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.
        So we should manually establish an SSH connection from our mail server to every MTA that we are communicating with? We should also establish a manual SSH connection for IM connections to every IM server that we connect with? SSH isn't a panacea.
    • Encryption is unfortunately directly opposed to that other very important networking tool compression.

      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
    • by chefmonkey ( 140671 ) on Tuesday March 14, 2006 @10: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.
    • Because it isn't always needed.

      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)

    by Anonymous Coward on Tuesday March 14, 2006 @08:40PM (#14921109)
    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.
    • 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. Because the original version of Zfone *was* a softphone. And I believe he's still working on one. --Naomi
  • by Anonymous Coward on Tuesday March 14, 2006 @08: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.
    • $sha1sum zfone-linux.tar.gz; md5sum zfone-linux.tar.gz

      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)

    by Gerald ( 9696 )
    What's the difference between this and SRTP [ietf.org]?
  • by Noksagt ( 69097 ) on Tuesday March 14, 2006 @08: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].
    • I can remember Phil's PGPfone which was released before VoIP was "the next big thing."

      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
      • 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...Did you have any luck with PGPfone?

        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

        • Indeed. And that hardware SIP devices start adopting it (some should be able to adopt it via firmware, not that the hardware manufacturers will actually DO that).

          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)

    by Anonymous Coward on Tuesday March 14, 2006 @08: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.
    • From your description they just re-invented the Modem using Digital instead of Analog and with encryption. This isn't new, the STU-XX secure phones used by the Government for Classified voice calls work very much the same way. Might be some IP infringement issues with thier work as well.
  • by Shanesan ( 955683 ) on Tuesday March 14, 2006 @08:54PM (#14921173) Homepage
    Igpay atinlay isway ethay estbay ayway otay encryptway ouryay onversationcay!
  • Any Ekiga [ekiga.org] (formerly GnomeMeeting) devs care to comment on whether they'll support this?
  • Well... (Score:3, Interesting)

    by Anonymous Coward on Tuesday March 14, 2006 @09:10PM (#14921255)
    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'm thinking MSN Messenger and Google Talk should add this to their VoIP features. Right now talking with VoIP unencrypted over the 'net makes me a bit uneasy.

    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.


    •   I was thinking the same thing. I am hesitant in adopting VOIP because of that.
    • Given that Google Talk, MSN, iChat, and others all use SIP as a voip transport, and zfone sits in front of any arbitrary SIP connection, you might have luck using these things with zfone, no client-integration directly needed.

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

      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

  • by gizmonic ( 302697 ) * on Tuesday March 14, 2006 @09:38PM (#14921364) Homepage
    Philip Zimmermann has apparently vanished from the face of the earth. Film at 11.

  • by Cthefuture ( 665326 ) on Tuesday March 14, 2006 @09:58PM (#14921448)
    I know the API isn't the greatest and the documentation completely sucks but someone with OpenSSL knowledge could put together a SIP-friendly API in a couple hours.

    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.
    • by rodac ( 580415 ) on Tuesday March 14, 2006 @10: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 @10: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.
    • cat /dev/dsp | openssl -magic -command -line -stuff | nc remotemachine 2500 to send.
      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.
  • I've not been able to get this thing to build on FC3, FC4 or Debian-Stable. In zfone-linux/srtp-ctr some of the test utilities won't build... no big deal because make install still works. The makefile for zfone-linux/libzfone/bnlib references /bin/install instead of /usr/bin/install. No biggie. Fixed. Installed. Lastly (I stopped here), make of zfone-linux/libzfone totally blew chunks in what at first glance looks non-trivial.

    Methinks Phil needs a Linux box!
    hehehe j/k.

    Has _anyone_ got this thing

  • by Guspaz ( 556486 ) on Wednesday March 15, 2006 @01:11AM (#14922224)
    Why do some people jump all over protocol-specific encryption as helping terrorists, or other such nonsense?

    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)

    by Nonillion ( 266505 ) on Wednesday March 15, 2006 @01:32AM (#14922278)
    Hmmmmm, could one use this method to get around some of these pesky Quality Of Service restrictions? Because we all know the carriers like to enforce these things to keep you from getting quality from your VoIP service.
  • by Lord Kano ( 13027 ) on Wednesday March 15, 2006 @03:12AM (#14922561) Homepage Journal
    I have a 22 year old sister that I'd like to introduce him to.

    I NEED a guy like this in the family.

    LK
  • So is this one Free Software?

    (and can you redistribute it once you've provided your email address to Phil for the download link?)

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Working...