What is this?
I was frustrated with the lack of good online documentation explaining why encrypting electronic communication (such as email and instant messaging) was important and giving idiot-proof instructions for enabling encryption in popular clients. This is my attempt to solve this problem.
Why should I care?
If you value your privacy or personal freedom, you should care. Encryption allows private communications to remain private by scambling messages before they are sent and unscrambling them before they are viewed. Only the intended recipient is able to unscramble the message. This prevents data thieves, evil corporations, governments, and others from viewing or even changing the message. With cryptography, it is also possible to digitally sign a message so the recipient knows without a doubt that the message is authentic.
This comes in contrast with popular email and instant messaging services offered today. Both email and instant messaging are often sent unsigned in plain text across the internet. Internet service providers (ISPs) may log this information. If these logs are somehow breached (either by mandatory government surveillance or intrusion by hackers) your previously-thought private communications will no longer be private.
In addition to encryption, digital signing also gives the freedom to deny any communication that has been tampered with. Email is notorious for being easy to spoof. With unsigned plain text email, someone can easily use your good name to send unlawful messages. Cryptography gives you both the peace of mind that your communication is private and the deniability that others' messages originated from you.
How does it work?
These tutorials covers how to digitally sign and encrypt email messages with S/MIME (Secure/Multipurpose Internet Mail Extensions) and encrypt instant messaging with OTR (Off-the-Record) encryption.
S/MIME, like PGP (Pretty Good Privacy, another standard for email encryption), is based on the concept of public and private keys. The two keys are mathematically related, but it is impossible to derive the private key from the public one. The public key is given out to individuals you wish to communicate with, while the private key must be protected in such a way that only you have access to it. Both keys have a two-fold purpose.
When digitally signing messages, the private key is used to add a signature to the message as an attachment based on the content of the message and the private key. If the recipient has the public key installed it can be proven that the message was signed with the corresponding private key. If the message is somehow tampered with before it is delivered the email client will be able to notify the recipient that the message has either been tampered with or forged.
When encrypting messages, the public key is used to scramble the message in such a way that only someone holding the private key is able to unscramble the message. When the recipient receives the encrypted message, the email client will often automatically decrypt the message on the fly if the private key is installed.
The private key itself is often stored in an encrypted form so the user must type a passphrase (a long password for extra security) before messages can be decrypted or signed. However, even if the private key requires a passphrase, it is important that only the correct person has access to the private key. If this private key is compromised, it may be possible for a third party to brute-force the passphrase. This would give them access to intercept and decrypt encrypted messages as well as forging signed messages.
S/MIME public and private keys are certificates which must be issued by a mutually-trusted third party. As with SSL (which is used to encrypt and verify secure websites over the https protocol), a CA (Certificate Authority) issues the certificates. Using self-signed certificates to eliminate the trusted third party is possible, but this practice is generally frowned upon when using SSL or S/MIME. If you like the idea of self-signed certificates it would probably be better to use PGP rather than S/MIME. The public/private key mechanism is largely the same, but trust is based on a "web of trust" model rather than a CA.
Off-the-Record (OTR) encryption has many of the same benefits as S/MIME encrypted and signed emails but is different in some important ways. The most important difference is how trust is verified. Instead of digitally signing the message before encryption, OTR uses what is called the "Socialist Millionaire Protocol" (SMP). Both users create a question and answer they are sure only the intended party knows the answer to. The questions are sent, and the users must each reply back with the correct answer. If the answer matches, trust is assured. However, if the incorrect answer is given the communication should remain as untrusted.
Since messages encrypted with OTR are not signed, it is impossible to conclude that any message was sent by any particular person. If one user's computer is compromised (e.g. government intrusion or malware) and logs are found, there is no way to prove who the other user was.
What's SSL, TLS, etc. actual purpose?
Many email and instant messaging services provide an encrypted connection between their servers and your computer (such as connecting using SSL or TLS to a POP3, IMAP, or SMTP server for email). While this does protect you from snooping eyes between you and their server, once your messages reach the server they can still be logged and transferred across the internet in plain text. As both email and XMPP (a popular instant messaging protocol and the one used by GChat) are federated, they must allow cross-server communication. Just as a chain is only as strong as its weakest link, encryption is only as strong as the weakest point of communication. If at any point a message is transferred unencrypted, security can not be assumed.
Rather than providing transport level encryption, both S/MIME and OTR offer complete, end-to-end encryption by scrambling the message itself. This makes it useless (if not impossible) for anyone else besides the intended recipient to save or read the message. It is still important to use SSL or TLS when authenticating to a server to protect against password-sniffing, but these methods do not in any way provide the security of digital signing or encryption of the message itself.