Slashdot Mirror

Also Off The Record messaging which has a pidgin plugin.

A properly designed secure messaging app would make this impossible. The protocols to implement this are not difficult.

If that is true, why does not one exist? Or, if one or more do, can you provide a link?

They do exist. OTR is an example, but it is a plug-in for desktop computer based messaging systems. I'm not as familiar with what is available in the mobile world. It should, in theory, not be difficult to implement.

Technically speaking, if you use a decent end-to-end encryption,
e.g.: using Pidgin/Adium, using OTR encryption plugin, and using one of the libpurple plugins (you need a plugin using Facebook's JSON API, as they've shut down their XMPP Gateway)

then there isn't that much that Facebook can spy.

They can see that you *are* chatting. They can see *whom* you're chatting, and that's about it.
Given that you use OTR, they might deduce you're probably more on the nerd/geek side of things,
but it's near(*) impossible for them to guess *WHAT* your chat messages contain.

Same applies to Skype (using the SkypeWeb plugin that uses the same XML/JSON api as the new beta Linux application and as the web.skype.com website).
Same applies to Google Talk (using the buil-in XMPP plug-in, but you're limited to what's supported on Google's XMPP gateway, so no full Google Hangout feature-set, and no server-to-server XMPP/Jabber).

And if there's a useful Twitter libpurple plugin that allows private messages, you would get similar privacy too.

The main advantage is that OTR is pretty simple and mostly works out-of-the-box (as far as I know it's even pre-installed with Adium, and if both end points have OTR, it automatically kicks in).

The main disadvantage is that nowadays, most people tend to prefer web-apps instead of stand alone clients, and there getting encryption requires special plugins to work (Mailveloppe is such a plugin, to do GPG on webmail's TEXTAREA boxes).

So instead most people send clear text message over web apps, and that's something that's trivial for company to read (and therefore mine for advertising profits).

---

(*): the thing is that the length of the encrypted result is partially influenced by the clear-text input.
So Facebook might guess if you're giving a short reply (e.g.: "Yes/No") or writing a long story.

Did they not forget about OTR?

Open source, been around for a very long time, available for most OSs (even via apt-get under debian based Linux), supports strong encryption, authentication, perfect forward secrecy, contains no advertisements and depends on no closed servers.

He might mean banning apps where the service provider isn't involved in the crypto and thus can't decrypt messages on demand. Like Skype for example - it's basically secure crypto-wise, but since everything goes through Microsoft servers they can (and do) eavesdrop on any conversation they like.

A weak implementation of crypto is just as bad as week crypto, though. In the case of Skype, for instance, Microsoft can force clients to (silently) downgrade from p2p crypto to server-mediated crypto for eavesdropping. Even if you consider the Russian and Chinese governments (who have access to this capability) to be good guys this MITM capability is always at risk of being used by others.

Also there's little they can do about plugins like OTR: they don't need to access a server so they can't be blocked, it's difficult to force OSS projects to silently weaken their crypto and there's bugger all the IM provider can do to decrypt them or limit their usage.

Why not develop and use technology that protects political engagement and democratic paricipation?

You mean, like modern-day cryptography ?

Specially things like OTR ?
That have perfect foward secrecy, thanks to DHE ? (i.e.: there's no key that could be disclosed to enable decryption of past intercepted communication) ?
That use authentication through Socialist Millionaire (which is keyless, meaning that there's no way to proof that past intercepted communication is authentic) ?
Which simply functions as an overlay, meaning that you can use it as up today above any chat system that you currently already have (Google Talk for example, huh no sorry "Google+ Hangouts" is the name now) so you don't need to sign-up a new chat and ask all your contacts to move to a new service?
Which already available out-of-the-box in a big number of software (like jitsi, adium) or as a plugin in others (like pidgin) ?

And there are numerous other technologies for also protecting e-mail (GPG is an often mentioned example), for protecting voice/video communication (the above mentioned jitsi implements them too), etc.

The tools are there. Some have very easy forms. You just need to get the users used to them.

but the fact that the court can order you to disclose your password, and put you in jail if claim you don't remember it, kind of makes me think they'll just say "fuck it" and you'll be sitting in prison indefinitely.

Then use modern day crypto like OTR.

OTR use ephemeral keys (in this case it's DHE), so there's no permanent key to begin with that could be disclosed (also no retro-active decryption possible. There doesn't exist any piece of information following whose disclosure, law enforcement could suddenly retro-actively decrypt all the intercepted communication that they have logged during the past years).
OTR use a key-less authentication system (Socialist millionaire), so there's not even an authetication key, and also no retro-active possible authentication proof (They can't prove that the intercepted communication from the past years is yours. It could be forged, and that's provable by design).

So the court can't order you to disclose a password.
It's not a matter of "Oh my gosh I happen to have forgotten the password that you want".
It's a matter of "There doesn't exist any password. That provable by the design of the thing itself".

DHE and ECDHE (at least, as long as you use a secure curve for the latter) don't have passwords and by design can't retro-actively be decrypted.

Add this as reason #2'175 on the long list of why one should definitely use end-to-end encryption.

If you use a well designed end-to-end encryption, that has been validated by cryptologist (think OTR for chat, ZRTP for voice), I doesn't matter what the quality of the underlying link is or if telcos are helping breaking the link.

Best part? These technology can work over your already existing systems (though ZRTP can't work over Skype's voice and video. It only works over SIP or XMPP/Jingle - i.e.: the standards that the whole rest of the internet is using).
So you can OTR encrypt your chats over your Google Talk's XMPP session.

And there are clients supporting them either out-of-the-box (jitsi, adium) or with a plugin (pidgin), over your existing accounts (XMPP like Google Talk, or any random SIP provider).

Facebook chat can be accessed via XMPP. So use a good IM client like Pidgin with the OTR plugin and you have nice, encrypted chats via FB. I use it daily, and it works great.

Yet Another Information Security Professional, working in a sensitive information startup.

Of course, a lot of these have been in use long before the NSA revelations...

A few of my personal tools and our corporate-used tools:

All OSX shop configured with strict firewall, fileVault, and openVPN,

Browser plugins to block ads (adBlock Plus), scripts/flash (NoScript), popups (Adblock Plus Pop-up Addon), trackers (Ghostery), and enforce HTTPS (HTTPS-Everywhere).

GPG Tools for encrypting individual files / emails - https://gpgtools.org/

OTR for secure messaging (use Adium which has OTR support off the shelf) https://otr.cypherpunks.ca/

Silent Circle for encrypted voice and text - https://silentcircle.com/

Personal VPN for traffic encryption for browsing outside of corporate purposes, e.g. one of these:
https://www.bestvpn.com/blog/4809/best-vpn-service-top-10/
note that several offer payment methods that are anonymous, e.g. gift cards purchased with cash, i.e. http://www.paygarden.com/

Obligitory Schneier:
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

For most of my personal communication I use the pidgin instant messaging client with the Off-The Record plugin for easy encrypted messaging on (nearly) any OS. The tough part is talking friends into using it as well. Of course, the NSA could still break into this stuff, but it would certainly waste their time and resources.

When it comes to crypto tools, I go by a simple rule: WWJD?

The J in this case is Jacob, more specifically Jacob Appelbaum. Until he endorses it, I'm on the fence. For IM, I already have OTR.

Many clients already support OTR: http://en.wikipedia.org/wiki/Off-the-Record_Messaging#Native
Many clients have plugins for OTR: http://www.cypherpunks.ca/otr/

What their protocol have that XMPP doesn't, or couldn't be extended to support?

It has TLS, which is a bad idea for chat. Unless you're taking a deposition, or something, where you want provable identity, most chat is expected to be ephemeral and reputable. Picture two people sitting quietly chatting in a secure room. That's the goal for most online chat.

You want to use OTR for most chat, not TLS. It offers repudiation as well as authentication, security, and perfect forward secrecy. It's even obnoxious about repudiation on the wire.

TLS is great for other stuff. It's just the wrong choice for online chat.

disclaimer: trusting the summary.

Yes, but neither email nor telephone integrates encryption as standard (and even most mobiles will not prevent you using unencrypted phone networks, or indeed even notify you). It is true that BBM will be decrypted by BB when a govt requests it, but that still narrows the field of interception a whole lot.

It would be great to have something like GTalk/BBM/WhatsApp/etc but where the central organisation (if there is one) can't decrypt it, but that isn't out there right now and I suspect if it did appear and got large then it would get governmentally stomped for not enabling intercepts.

This could be achieved at endpoints alone by producing a system like WhatsApp that actually runs over existing XMPP networks and has encrypted content, which would address the issue of proprietary design. Indeed, OTR (also see the cypherpunks site provides that. Main issue is key exchange in that context, as usual.

Pidgin has a plugin for encryption, but when I tested it a few years ago it caused problems with long messages and pastes and such and so I stopped using it.

GAIM-encryption wasn't good, indeed. Including regarding security (problems with deniability).
It's not maintained anymore.

The killer features in Jitsi is the desktop sharing, encryption, and file transfer.
{...} And encryption I addressed above.

The current standard in chat encryption is Off-The-Record OTR. This one is the encryption standard that is available out-of-the-box for chat messages in Jitzi. But also in Adium and other modern clients.
OTR sits as a layer above the chat messages (it's agnostic to the protocol used to exchange message. As long as the messages are exchanged and both ends use OTR, the transmission will be encrypted).

As of Pidgin: There is a plugin for supporting OTR. (In fact, it's technically the same as Adium, except Pidgin doesn't include it by default). Its either in your distro's repository (if you're running Linux) or there an installer for it (if you're running Windows).
It works very nicely (it's widely deployed and used. Thus it's better tested and debugged)

What Pidgin (and Ekiga too, another pet peeves of mine, although its a bit out of scope) lacks on the encryption front is call (Video and Audio) encryption. Pidgin only does pure RTP, Jitzi does ZRTP encryption over the RTP channel.
(ZRTP functions the same way as OTR: it sits above a FTP channel. No matter which protocol opened the RTP channel, once the channel is open, ZRTP can encrypt it, as long as both ends have it).

Regarding Desktop:

Desktop streaming:
- in Pidgin, it's just a matter of selecting the correct video source. Just tell GStreamer to use the desktop as the source, instead of the webcam or whatever complicated Gstreamer-powered plumbing you use to bring a video source to Pidgin.
The problem here is more user-friendliness. Pidgin doesn't have its own settings to choose video source. You have to select the default GStreamer source using 3rd party software.

Desktop sharing:
- I don't know. There are a couple of Pidgin/VNC plugins around... But I don't have any idea what Jitsi is actually using and if its implementation is standardised or not.

In addition to the Google Talk client, there are many other clients out there that provide a great communications experience. We believe users should have choice in which clients they use to connect to the Google Talk service and we want to encourage the developer community to create new and innovative applications that leverage our service. To enable this, Google Talk uses the standard XMPP protocol for authentication, presence, and messaging.

What does this mean for those who care about security? For one, you can choose software that includes Off-the-Record end-to-end encryption (OTR) such as Pidgin with the OTR plugin on GNU+Linux or Windows, or Adium (which has OTR built-in and enabled by default) on Mac OS X. On Android you can use Beem or Gibberbot, although I personally recommend Beem (and if you are using iOS you obviously don't give a shit about security anyway). By using OTR, Google has no idea what you are typing, even as you use their servers to send & receive XMPP data. As a bonus, you can proxy any of these applications over Tor, so Google has no idea where you are even connecting from, anonymising your IP address.

Because of the benefits of an open protocol, the fact that Google is in the US is far less of a problem than Microsoft being in the US because Skype by design restricts your ability to know how it communicates with Microsoft's supernodes and other Skype clients. This is the very nature of proprietary software: to subjugate you, keep you ignorant, and wield power over you. Google may not be perfect, but at least they are committed to using open standards as the base level of their communication networks, and explicitely encourage people to use what software they want, allow proxied and/or Torified connections to their services, & allow you to use end-to-end encryption with crypto keys that YOU control.

TL,DR:

I am very happy to find out a friend has a Google account, so that as soon as they use it with OTR encryption, I can communicate with them safely & securely from my own XMPP server with end-to-end encryption using an standard, open protocol. Incomparably better than Skype.

You just described Pidgin with OTR.

There appears* to be a Pidgin plugin for Facebook. So, Pidgin+OTR, plus convincing whomever you're chatting with to install and enable the same thing, is the solution. Of course, as with most technological problems, the third part of that sequence---the human part---is going to be the hardest problem to solve. The tech exists, if only people would use it.

* I can't test any of this to see if it works because I don't have a Facebook account and never will.

Messaging is a privacy nightmare.

No. Messaging ON FACEBOOK is a privacy nightmare. But if you're dumb enough to use a service whose entire purpose is to look at the contents of your messages, well, you deserve what you get.

Otherwise, just install something like Off the Record and enjoy end to end encrypted messaging. Don't save local logs, or save them to an encrypted filesystem, and you're off to the races.

I'm sure some mouth-breather is about to post the xkcd about hitting you with a wrench, but face it, that isn't the threat most of us have to worry about. Unless you're in Syria and subverting the regime or something, ppls in US or Sweden or Japan or something don't have to worry about that, we have to worry about data-miners and advertisers, who don't come after hundreds of millions of people iwth wrenches.

In order for this not to happen again do the following:

Stop using Windows and MacOSX.
Download and install Fedora F16.
When installing, encrypt the harddrive with a really hard to break password.
Install pidgin and off the record like this: 'yum install pidgin pidgin-otr'
Generate keys and verify them before communicating.
Be _very_ careful if who you usually talks to changes their key, they might have been arrested.
Never ever communicate in the clear.

Using this strategy you will not be immune, rubber-hose-cryptanalysis with still defeat this. Also you can be tracked so your oppresive government can see that you communicate, they will just not be able to read what you are saying. And not using major OSes will keep you away from the most common exploits and trojans.

Also, try to use TOR, HTTPS-everywhere and other good tools.

References:
https://fedoraproject.org/
http://fr2.rpmfind.net//linux/RPM/fedora/16/x86_64/pidgin-otr-3.2.0-4.fc15.x86_64.html
http://www.cypherpunks.ca/otr/

Good luck.

Unless Google has changed the meaning of its "Off The Record" button since I last used it, that just means they won't save the conversation for later viewing in the gmail interface (or in the gmail interface of the person you're talking to).

They don't provide http://www.cypherpunks.ca/otr/ as far as I can tell.

I rewrote the pidgin-otr plugin to use plain libpurple a few months ago. It will work on anything that libpurple works on, including finch. You can read about it here

http://lists.cypherpunks.ca/pipermail/otr-dev/2011-December/001226.html

and grab the code here

https://gitorious.org/purple-otr#more

There's already a package for it in Arch Linux.
http://aur.archlinux.org/packages.php?ID=55511

PGP is good if you want accountability, but I think OTR may be a better way to go here, at least for casual conversation.

The truly funny part is Web 2.0 is back to classic Client/Server programming, utilizing an HTML engine as the client. I believe that existed since the 60s with dumb terminals, but certainly no later than the early 80s with the current modern thick client/server model (think X11 and the like)

Regarding the open sourcing of the encryption code, generally self-written encryption routines are inadequate at best. If you're not leveraging one of the well vetted encryption libraries, odds are that your solution is weak and will only stand up to cursory inspection. Otherwise, you're using PGP, RSA, Blowfish, etc, and your code is merely a light wrapper around those libraries. (No, I did not review the code)

As for chat clients and the like connecting to each other with encryption, this has been around and open sourced a long time, one implementation is Off-the-Record. And of course there's the PGP solution that has been around since the early 90s.

You're incorrectly assuming that the key must have been leaked. HDCP is so weak that it is possible to derive any arbitrary private key, including the master key, from a fairly small number of device public keys that are freely given out by the devices. I don't know the details behind how to derive the master key rather than merely deriving an arbitrary device key, but I've heard many people claim that it is mathematically possible to do so.

Thus, it is entirely possible, even likely, that this key was released by someone with no ties to the industry at all, having merely obtained the public keys from a number of devices. You'd need little more than an FPGA to perform an HDCP handshake with a TV or Blu-Ray player (and the handshake need not succeed to obtain the public key...). Honestly, I'm surprised this didn't happen several years ago. The trivial ease with which HDCP can be broken has been known for some time.

They could try replacing all the keys for all devices as a stopgap, but that's pretty problematic and could well just lead to the same leak happening again.

It wouldn't help much in any case, since HDCP is fundamentally flawed. Extracting 40 particular public-private keypairs (perhaps by electron microscopy or what have you) is sufficient to make a synthetic master key.

That's why I described it as a stopgap. It's not clear how this leak happened. There are three main means through which someone who isn't part of DCP, LLC can get their hands on device keypairs. 1) Work for a device manufacturer and be in a position where you're trusted to see them. 2) use a logic probe or similar to extract them from the chips (as you suggest above). 3) an electronic probing birthday-paradox style attack (see paper Four Simple Cryptographic Attacks on HDCP for details).

It's not clear which of these has been used, but if they were to change all the keys, if it were 1, we could possibly see a new master key the next day. If it were 2, we could see one within a couple of days. And if it were 3, it would take about six weeks. So I suspect that they're smart enough to not bother.

As a side note, the Crosby paper has several flaws. Its methodology for finding a solution actually loses some bits in the process due to having to divide by two (which is unavoidable, but which they don't acknowledge will happen in the paper). They got so caught up in the methodology of the matrix that they forgot about what would happen with the keys when their solution is actually applied to get the real key. Fortunately, this isn't a serious issue. Their results also disagreed with mine on the question of how many vectors you would need to have an invertible matrix. They came up with overwhelming odds once you have 45 or so. I came up with 50/50 odds by the time you get to about the mid-fifties and not overwhelming odds until you get up into the seventies. So that's a pretty strong disagreement. One of us definitely made a mistake. My suspicion is that it's them because I know what methodology I used and can't see any mistakes in it. But I really need to check more thoroughly.

But for the time being I recommend my paper, Four Simple Cryptographic Attacks on HDCP, (which was released before theirs) instead. Although I am biased in my opinion of the two.

Keith

They could try replacing all the keys for all devices as a stopgap, but that's pretty problematic and could well just lead to the same leak happening again.

It wouldn't help much in any case, since HDCP is fundamentally flawed. Extracting 40 particular public-private keypairs (perhaps by electron microscopy or what have you) is sufficient to make a synthetic master key.

The instant messaging system has some APIs to extend it, so that a 3rd party program could call a function to send a message through the system, and someone's ported OTR to Java/J2ME already.

Someone just needs to combine the two, and get a lot of pissed off Saudis and Indian government agents at them...

http://www.whispersys.com/
http://www.cypherpunks.ca/otr/
http://www.gpg4win.org/

Encrypt your text. Authenticate your text via digital signature. Avoid all contact with minors or strange individuals who cannot or will not encrypt or authenticate their communications.

I'm interested in seeing how the key exchange is handled. After all, you can have a great encryption algorithm but if your implementation sucks, it won't do you any good.

For texting the implementation is Off-the-Record, which is already used in several other softwares (the libpurple-based Pidgin and Adium, for instance). The details of this are here.

Granted, the hurdle there would be things like losing the phone, getting new hardware, etc, but it's still interesting to think about.

Read OtR's website and their arguments about "Deniability" and "Perfect forward secrecy". Some of the problems are addressed in the way OtR works (as opposed to older encryption system such as pidgin-encryption).

I'm interested in seeing how the key exchange is handled. After all, you can have a great encryption algorithm but if your implementation sucks, it won't do you any good.

For texting the implementation is Off-the-Record, which is already used in several other softwares (the libpurple-based Pidgin and Adium, for instance). The details of this are here.

Granted, the hurdle there would be things like losing the phone, getting new hardware, etc, but it's still interesting to think about.

Read OtR's website and their arguments about "Deniability" and "Perfect forward secrecy". Some of the problems are addressed in the way OtR works (as opposed to older encryption system such as pidgin-encryption).

In fact, the texting part uses Off-the-record, which is available on lots of software, including libpurple-based like Pidgin (as a plugin) and Adium (out of the box).

So if you configured an account able to receive SMS (like a SIMPLE or Skype account) on these software, it already works.

And as the webOS chat module is libpurple-based it might not by that much difficult to bolt OtR on Palm Pre (some hobyist have successfully ported other libpurple plugins onto the Pre).

It was mine to begin with.
I just happened to hit "Reply" in the wrong thread and wanted to move where appropriate. I fucked up the copy-paste. And of course it does look the same in the preview pane, which didn't help.

Here are the missing links :
- Adium : http://adium.im/
- Pidgin : http://pidgin.im/
- OTR: http://www.cypherpunks.ca/otr/
- plugins downloads : http://www.cypherpunks.ca/otr/index.php#downloads middle column. It offers a Windows installer. For Linux there's source code (I use it), but it should be much simpler to use the package provided by your distribution's repository (it's in OpenSUSE, Ubuntu, Debian and Gentoo. Don't know about the others)

(Checking in preview pane : Yup this time I didn't fuck up the URLs ;-) )

It was mine to begin with.
I just happened to hit "Reply" in the wrong thread and wanted to move where appropriate. I fucked up the copy-paste. And of course it does look the same in the preview pane, which didn't help.

Here are the missing links :
- Adium : http://adium.im/
- Pidgin : http://pidgin.im/
- OTR: http://www.cypherpunks.ca/otr/
- plugins downloads : http://www.cypherpunks.ca/otr/index.php#downloads middle column. It offers a Windows installer. For Linux there's source code (I use it), but it should be much simpler to use the package provided by your distribution's repository (it's in OpenSUSE, Ubuntu, Debian and Gentoo. Don't know about the others)

(Checking in preview pane : Yup this time I didn't fuck up the URLs ;-) )

The only slightly dubious thing is that they do seem to want to restrict distribution of clients that could connect to their servers, even if they could also be used in other ways.

This part was "slightly dubious?"

You acknowledge and agree that we may require you to stop using or distributing a Third-Party Viewer for accessing Second Life if we determine that there is a violation.

This is exactly an attempt to erase the freedoms granted under the GPL.

I think the problem and the reason nobody seems to get the problem is that the story submitter, GigsVT, wanted to include more excerpts than just the worst one, and the worst one was the one that deserved the most scathing criticism, and the most scathing criticism is what got the headline. Imagine that.

So what do we have here? Let's see:

• A bunch of policy changes that might irk some people (see below for serious issues with one of those.)
• One egregious attempt to retroactively take back rights expressly provided to you by the distribution terms of the Second Life viewer.

It's confusing when there's more than one thing, and all of those things are not the exact same thing, isn't it?

Mod parent down.

Also...

You must not mask IP or MAC addresses (reported to the server)

This is like DRM: It only negatively affects those who want to conform to the rules, and does nothing to stifle those it calls attention to. The worst part is that "mask" is a completely informal term.

Changing your MAC address is routine networking for many people whose network admins tie their access credentials to their MAC addresses.

Someone might want to protect their privacy while cybersexing (snicker) or someone may even want to leak important information to the public using Second Life (I do have a fantasy to modify the open source Quake 3 engine to trickle out a stream of data out in the least significant bits of player movement. Can you imagine the Chinese trying to figure that one out?)

These aren't just obscure corner cases or open source zealotry, these are things I personally expect to have from open source software. I switched from AOL instant messenger to an open source IM client because I wanted an IM client I could retrofit with my own crude privacy software. Years later I am using sophisticated OTR, and I have TOR at my disposal if I feel the need to "mask" my IP. I realize this isn't a GPL violation, but distributing the client under the GPL and then telling me I can't protect my privacy (while not violating any other terms of service, mind you; remember this anti-"masking" restriction is only something that affects people who want to obey the rules, not those who wish to cheat them) is a bit like giving me an "open source cellular handset" and then telling me exactly what audio codec I'm allowed to use for voice conversations so spy software can analyze my calls for content, you know, unless I build my own cellular network.

Specially since Skype are rather open about the fact they are ready to collaborate with governments if legally asked to.

Once again : the only *true* privacy/security is complete end-to-end (deniable) encryption where the encryption is under the control of the sender and the decryption under that of the receiver, and everything in between only transits in encrypted form.

Only opensource phones with publicly available and auditable source-code and that use ZRTP do qualify (like currently Twinkle. Probably Ekiga too at some point in future).
Being closed source and thus not auditable, Skype doesn't qualify as *under control of sender/receiver*, unless the data it self is already encrypted at the time it is fed into Skype.

(NOTE:
Off the Record plugin + Skype4pidgin plugin does exactly that on Pidgin/Adium with text messages : if both ends of a conversation have OtR running, the message will be encrypted before it is transmitted to Skype API - even if there's a backdoor inside Skype the only thing it sees would be already encrypted text. OtR works with other networks, given the proper plugin. But currently can't work with sound/video, because Skype only accept raw media that have to be compressed)

Explain then, how OTR http://www.cypherpunks.ca/otr/ makes a man in the middle attack possible, assuming I've authenticated the person at the other end.
Besides, all the other IM protocols (AIM, ICQ, MSN, YAHOO) have been using ssl/tls for years, right?

E-mail is unencrypted anyway. Using a third-party e-mail service does decrease your privacy a bit, but (unencrypted) e-mails were never private. I use encrypted IM (with keys verified in person) when I want actual privacy.

It has no support for OTR, which is the most widely supported multi-protocol encryption standard. They're working on supporting it now, but it isn't there yet, and I think the major distributions should've waited to make it the default IM client until OTR support was there.

Along with having to stop posting/having a profile on slashdot. :P

OTR IM is the only way to go?

correct link:

http://www.cypherpunks.ca/otr

Sorry...typo.

As far as I understand, the built-in (TLS?) encryption is not end to end. In particular, the server can read everything. The functionality I want is provided by otr. It is really sad that this is not a part of every communication standard.

> Use the encryption capabilities in Pidgin. Well, technically Pidgin does not have built-in encryption capabilities (unfortunately!!). You need a plugin like OTR: http://www.cypherpunks.ca/otr

> I'd love it if Pidgin, for example, came with the Off The Record plugin by default.
> Then my IMs could be encrypted with all Pidgin users, and not just the ones
> who bothered to install OTR.

I agree. Unfortunately the Pidgin developers do not:

http://blog.caseyho.com/2009/01/encryption-and-otr-in-pidgin.html

Not sure, what exact "usability issues" they have in mind that precludes them from including it (I never had a problem with OTR). Perhaps a more code-willing and -minded person can help Ian Goldberg in improving OTR, if needed: http://www.cypherpunks.ca/otr

You might want to check their homepage and the Wikipedia article.

OTR works very well for me. I recommend Pidgin as a client and Jabber as a protocol.

You could try recommending Pidgin with the Off The Record plugin. I can't say I've personally gone through the code and verified all of its claims, but the plugin looks promising, and it's easy to install.

http://www.pidgin.im/

http://en.wikipedia.org/wiki/Pidgin

http://www.cypherpunks.ca/otr/

So how about Pidgin with the OTR plugin? afaik you can't get more secure than OTR with IM, and it's available for a few different clients.

A good start would be AIM/Jabber/* video conferencing protocols using encryption and open source.

Already exists.
It's a plugins called Off the record which is supported in Pidgin (plugin), Adium (out of the box) and several other softwares (including as a stand alone proxy - although slightly less secure : it's still vulnerable to a binary client backdoor).

It doesn't break or change the protocol.
Instead, it works one layer above, encrypting messages before sending them and decrypting them after receiving them.
Indeed it works even with non open protocols, as long as Pidgin/Adium are able to communicate (could be used over MSN or FaceBook).

In those protocols, the server helps you figure out the IP of the person you want to talk to, but otherwise doesn't see the messages (except in AIM for text messages when the user is offline).

With encryption-as-an-additional layer, it doesn't matter if the server sees the messages or not.
What the server will see is a message containing only garbage (base64 or line-noise like). Only after going through the plugin to these message mean something.

Plus, OTR keep track of signatures and alerts if hashes sudenly don't match (if someone is trying a man in the middle attack).

Except, even IF you could comb through the code, it doesn't mean that at some higher level your security isn't compromised.
I run a VOIP server and it's ridiculously easy to monitor everything going through it despite a TLS initiated client-server session.

No, sorry no.
End-to-end has nothing to do with those application that provide some toy-protection by securing communication with the server (like IMAPS or SSL protection in stock MSN).

End-to-end means that the whole traffic is encrypted between both *end points*. A direct channel going from my software on my computer, all the way to your software on your computer. Every one else along the chain only sees crypted garbage.

You can't spy an End-to-end encrypted traffic (I mean you can record packets, but you can't understand them). If any one attempts a man-in-the-middle attack (at the server, for example), both end points will see the wrong encryption certificates. (Each end of the communication will see the middle-man's certificate, not the original one).

You could compromise the system :
- at the key exchange step the first time 2 previously unknown people get in touch (if you manage to trick each one into thinking that the key they recieved from *your* the first time they did exchange the key were their keys).
- at the end point of the communication. If something is compromised at the exit of the secure channel, no matter how the channel itself is secure.
The system could be root-kited, or the software could be not trustworthy.

How you find and trust VOIP peers is where that ideas falls apart

Building a chain of trust which tops at meeting the first key persons in real life in order to exchange keys (that as that portion of communication is secured, you can obtain further security tokens from other persons).
Or at least using a separate better trusted channel to confirm the keys' hashes.

Another idea is to encrypt/decrypt the data on the client.

Been done since ages on opensource implementations of IM clients. "Off the Record" is currently a very popular application, running on Pidgin (plugin), Adium (out-of-the-box) and several others, and functioning as a layer above the message protocol.

(If both end points are running OTR, when you type a message in your client, the plugin converts it into a cyphered text. Then that message is sent using the classical route of whatever protocol you use underneath (MSN, Jabber, Whatever), the client at the other end receive it too, and its plugin decrypts the message back before displaying it, check also if the encryption key matches.
Regadless of what is the network used, the message that transist is only something looking like line noise. Microsoft's MSN server could log it, its still meaningless.)

Encrypting the audio portion of the UDP packets would be very problematic

Been done for ages too. You should google around for ZRTP (by nothing less than the author of PGP). Supported in several project, including the open source Twinkle, support comming in Ekiga next major release too. Nothing problematic.

Running your own communications server is good too.

...as long as you use end-to-end encryption between the people.
or at least as long as everyone exclusively use secure communications from/to the server.
(but then, *they* shouldn't trust it as they don't control what's happening on the server)