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.

Re:Does it matter???

[Aspirator]

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?

Encryption is hard

[user9918277462]

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.

PGPfone, Speak Freely

[Noksagt]

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].

Re:Why not encrypt by default

[Savage-Rabbit]

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.

Re:It would also..

[Anonymous Coward]

It would also almost totally negate any ISP's attempt at shaping VOIP traffic to try and get people to buy their service instead.

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 content of VoIP calls. Voice recognition on that scale is probably cost prohibitive for telcos at this point.

Re:PGPfone: Full duplex mode did suck

[Noksagt]

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 to suck significantly more than any other VoIP at the time. I do think that the Macintosh version was slightly more reliable (it was originally released on the Mac & eventually ported to win32). (And, again, it didn't suck THAT much more than any other Mac Class app.)

I think I tried it with the V1 series however.

v1+win32 might have been part of the problem. I don't recall the differences between v1 and v2, but NAI seems to have killed much of the goodness in any of the apps they acquired, so I wouldn't exactly hold my breath.

I hope a Zfone proxy is made so that hardware ATA's can be secured?

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

Re:Why not encrypt by default

[chefmonkey]

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.

Re:Why not use OpenSSL?

[rodac]

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.

Re:Why not use OpenSSL?

[Cthefuture]

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.

Re:What ever happened to PGP Phone?

[Winged]

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.

Re:I agree, it is hugely important

[stephentyrone]

yes, but the nice thing is that for most encryption methods, the work to do the encryption grows linearly (at worst polynomially), whereas the work to break the encryption grows exponentially in key size. the larger the key gets, the bigger the gap between work to encode and work to decode.

Re:I agree, it is hugely important

[Myria]

Almost all commercial multiplayer games use encryption as security-through-obscurity, usually by using custom algorithms. In online games, you're trying to keep cheaters from manipulating packets, not keep eavesdroppers from watching.

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

Re:What ever happened to PGP Phone?

[Antique Geekmeister]

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 regulations were found unconstitutional, and transferred from Customs to Commerce instead of thrown out, and we're still seeing them in the courts occasionally. It's why US users had such trouble using SSL keys as long as 128 bits on so many web browsers for such a long time.

So PGPphone had a serious legal battle to reach wide use, and it never caught on as well as not having a great user interface. I hope Phil's newer tool catches on.