Photo by rtitoun.
In my quest for more knowledge of cryptography, I’ve started reading actual
books (instead of just reading API reference documents.) If you’re like me,
and you’ve decided that going deeper than just making the code work is a good
thing, read on. (more…)
Terrible mashup of OpenPGP.js logo and source code by the author (because
nothing says “Where’s the source?” like a bad logo.)
Last time I wrote, I showed you how to use Braintree.js to encrypt form values. I even built a contact form to do it. It occurred to me that there might be a better technology for encrypting contact form data. (There is.) Of course, I’m not the first person to have this idea.
Some months ago, I wrote about using PGP and S/MIME to keep e-mail private. As much as I love the idea of keeping my e-mail private, I rarely use PGP or S/MIME. This is because the people with whom I communicate don’t use PGP or S/MIME. To improve this situation, I’ve been looking at ways I can help my friends and family try securing their e-mail.
Before I dive into what I’ve found, let me mention that these solutions do not provide the same level of security as installing GnuPG (or other similar tools) on your own computer. (more…)
I can’t think of anyone who would argue that keeping e‐mail private is of little import or an easy task. I use e‐mail as storage for personal information, for authentication, and for communicating when I want the communications to be private. Such private information should be well‐protected. Unfortunately, this is rarely the case.
My current e‐mail service provider uses machine learning techniques to read my messages and display frighteningly‐relevant advertisements to me. (This is part of the bargain of free e‐mail service.) It also does a good job providing reasonable security against most parties who would like to read my e‐mail.
So, how would I go about keeping my messages private to those whose names are on the To and From lines of the message? There are some solutions to this challenge. Two common solutions are PGP and S/MIME. Each of these solutions uses public-key encryption.
Public‐key encryption is a type of encryption that requires separate, related keys for encryption and decryption. I control a keypair—a public key and a private key. My friend John also controls a keypair. When I send John a message, I use his public key (which is publically-available) to encrypt the message. He can then use his private key to decrypt and read the message. When he sends me a response, he uses my public key to encrypt the message and I use my private key to decrypt the message.
PGP (Pretty Good Privacy) provides a means of encrypting messages and files (but not the recipients or the Subject of a message.) It is easy to use as encryption goes and relatively secure when used properly. Identities in PGP are built on the notion of a web of trust. The web of trust is a very important part of PGP. What good is encryption if you don’t encrypt the message for only the correct recipient?
The web of trust system works on the idea that you are willing to trust your friends. If you and I meet and exchange keys, you know that when you encrypt a message with my public key, I am the one who can receive that message. If I introduce you to my friend Alan, you might be willing to accept that a public key he provides you is in his control. However, with PGP, I can send you a file that proves to you that I believe that a certain public key is controlled by Alan. You can then trust that Alan is in control of that public key because you trust that I have verified Alan’s public key.
Where can you get PGP? You can buy it from Symantec or get a free work‐alike called GnuPG.
S/MIME (Secure/Multipurpose Internet Mail Extensions) also provides a means of means of securing the body of a message. It is built on the notion that central authorities should verify your identity. This makes it popular in larger companies that need to secure e‐mail. (It can also be used as the basis for single sign‐on implementations.)
The public key infrastructure system uses central authorities like companies or governments to verify identities. You (or, more accurately, your software) may trust one of these authorities to verify that Troy at Art & Logic is really Troy at Art & Logic. This is useful for companies that want their employees to communicate privately. Each company can verify the identities of the employees to the other company. This works less well when you want to communicate privately with your friends from college.
There are some drawbacks to encrypting your e‐mail.
If you want your messages to be scanned for malware, you must do that after decrypting the message. Alternatively, you or your IT team may keep a copy of your private key and use that to decrypt the message and scan it for malware. This makes your messages less private, but may save you some pain. Alternately, you may decide that you don’t need to worry about it if you trust the sender and PGP and S/MIME allow you to verify the identity of the sender.
Searching encrypted messages is not easily done if your software is not built for it. You can search Subjects, but the Subject of each message is not encrypted, so you need to find the balance of what you are willing to leave unencrypted.
In all, e‐mail encryption provides usable privacy for your messages. It does not secure the Subject line or the sender or recipients of a message. It provides some challenges for defending against malware and searching your messages in the future. If you must have privacy for your communications, I suggest you evaluate one of these options.