FAQ
How do I use the same key on multiple machines?
In the .pidgin directory under your home directory (or under the hidden "Application Data" directory in "C:\Documents and Settings\username" on Windows), there are three key files. Your private keys are stored in id.priv. Your public keys are in id. The public keys that you have "accepted" are in known_keys. Each key is on its own line, and starts with the account name. Cut and paste the keys you want to copy (in both id.priv and id). Or, copy those entire files (but make sure to get the permissions right on them! Pidgin-Encryption won't use key files that are world-writable, or private key files that are world-readable).
How do I make encryption enabled by default for my one buddy who uses Pidgin-Encryption?
Right-click on a buddy's name (in your buddy list), and select Turn Auto-Encrypt On. Now, whenever a new conversation window for that buddy is opened, encryption will start out as enabled.
The conversation window isn't wide enough for the Tx/Rx encryption buttons. Can you patch Pidgin to make the window bigger? / Can you make the buttons smaller?
No, but Pidgin does save the size of your conversation windows. So, once you make your conversation window big enough for the buttons, it should stay bigger automatically. Another hint: you can adjust Pidgin to only show the icon picture, not the text (see Preferences:Conversations), and that will save a lot of space.
How do I check to see that I've got the right key for my buddy, that there is no "man-in-the-middle"?
You can compare key fingerprints: Check in Preferences:Plugins:Pidgin-Encryption: all of the keys that are currently cached (i.e. that you have seen this session) are in that window, with their key fingerprints. If you've been chatting with your buddy, his key will be in there (and of course yours will be as well). Alternatively, you can exchange the appropriate lines from your id files, and compare them against the lines in your known_keys files.
Pidgin crashes when I load the plugin, with a line like "pidgin-encryption: Could not generate key. NSS Error: -8128"
Make sure that Pidgin was compiled with support for the NSS libraries. See the config.log file in your Pidgin source directory to see if NSS was found.
./configure fails: it doesn't find my nss or nspr libraries?
Beware! If you're seeing this issue, you should make sure that your Pidgin install found the nss/nspr libraries. If it didn't, then Pidgin-Encryption is most likely not going to work. Once you've got Pidgin happy with NSS/NSPR, then use the same ./configure flags (--with-nspr-includes, etc...) with Pidgin-Encryption that you do with Pidgin.
I see something about a garbled message, and my buddy sees a message saying that his last message to me was not received?
A new security feature in 2.xx is that the receiver must (along with the receivers key) send a nonceto the sender. The sender then includes this nonce in the message, verifying that it was not recorded previously. If the sender believes that she already has an appropriate nonce (she has a conversation window still open), and the receiver has changed what nonce he expects (closing the conversation window or restarting Pidgin), then the message will have an inappropriate nonce, and you will see these messages. The plugin saves all outgoing messages briefly, in case this happens, and will then re-send the message with a correct nonce. When this happens, you'll see a message saying that it was resent (if you are the sender), or that the initial message was garbled (if you are the receiver). Note: On AOL, if you are logged in in multiple places, then your two Pidgin-Encryption plugins are going to be fighting over what nonce to use, and you'll see this alot (and have lots of problems). Pidgin-Encryption is meant to be one end-point to another, and having multiple listeners on one end is bad news. Log the other session out.
Will Pidgin-Encryption run on Solaris/BSD/... ?
This plugin should run on any system that has the NSS cryptographic libary installed.
I'm trying to use the CVS version, but autoconf and automake are giving me errors?
There have been changes recently in autoconf that have broken many install scripts, and there have been issues building both Pidgin and Pidgin-Encryption with some releases of those tools. Check your system for alternate versions of the build tools (like "autoconf-2.13" instead of just "autoconf"). See the INSTALL file for some more details. If all else fails, you should be able to use the non-CVS release without using automake.
Why not PGP/GPG/....? Is this really secure?
The one sentence answer is that this plugin can be every bit as secure (and every bit as insecure) as PGP. The longer answer involves a few principles that guided the design of this plugin, which I'll go into below. One principle is that frequently there must be a balance between better security and the added difficulties imposed on the user by extra security. Security that is difficult to use will be bypassed, and the end result is worse than a "less" secure system. However, whenever possible, the choice between security and ease of use should be left up to the user, not imposed on the user by software. Hopefully, the easy parts are built in, and the hard parts are do-able, if the user wishes. The user can then decide how much security they want, given a flexible software solution. This plugin's approach to providing this ease of use / security is very similar to that of SSH. By default, when you first talk to a user (host) that you haven't talked with before, the keys are automatically exchanged (but, like SSH, you can change this). Then, in the future, if the software sees a different key than the one you got that first time, it informs you that something may be wrong. If you want better security, you can verify that the public key that you received is the correct public key, via a channel that you feel is more secure than the original transmission of the key. This isn't too hard to do, as the public keys are stored in a human readable file (.ssh/known_hosts, and .pidgin/known_keys). You can call up your friend and ask her to read the number on her screen to you, or ask your buddy to email you his key and sign it with his GPG key, or... Another reason for not using GPG is that, fundamentally, I think that many people want (and expect) a different level of security for IMs as compared to email. If a stranger IM's you and you "accept" his public key, does that mean that you want to trust email that this same person sends to you in the future? Keeping the keys in seperate pools means that you can lean towards convenience in your IM encryption but be stricter about security for your email. New:With the 2.xx series, the Pidgin-Encryption plugin sends a "nonce" with each message. The appropriate nonce changes over time, and nonces cannot be reused. Thus, if an attacker intercepts an IM, and then re-sends it later (perhaps several times), the receiver will know not to accept the message. This security feature is not present in GPG/PGP, where it is assumed that the recipent of an email will realize that it is a duplicate (as the headers are the same). This is not true for IM, where messages are shorter and not timestamped by the sender.
But GPG/PGP lets me use a keyserver, and does that automatically for me!
The PGP approach of using a keyserver does make the verification of a bunch of keys easier, as it automates the process. But, if the user doesn't verify the keys of keyservers, then the process really is no more secure. As explained in the Gnu Privacy Handbook, you need to be careful in building up your web of trust if you are going to really trust it. Notice that the handbook talks more about key signing parties than it does keyservers. Also, while using a central keyserver does help with building the web of trust, it also adds an extra single point of failure, which can be more of an issue for "instant" messages than for email, where a short delay due to a server hiccup is less of a problem. The central server simplifies the security model in some ways, but complicates it in others, and I went with what I perceive to be the simpler solution.
But I want GPG compatibility, dammit!
Oh! Well, why didn't you say so earlier? Go check out the Gaim-E project.