Take Control of Apple Mail (1.0) (2014)

Sign and Encrypt Messages

Back in Signatures, I explained how to add a signature to the end of each message with your contact information, a quote, or other content. But a message can also have a digital signature, a (normally invisible) string of characters that confirms to the recipient that the message truly comes from the address it appears to come from, and that the message contents haven’t been altered in transit.

In addition, Mail can encrypt messages, scrambling their contents so that only someone with the necessary key (presumably, the recipient) can view their contents, thereby ensuring private communications.

In this chapter I discuss if and when you should use digital signatures and encryption, how they work behind the scenes, and how to go about signing and encrypting messages in Mail.

Learn When and Why to Sign or Encrypt Messages

Let me start with the essential question of whether, or under what circumstances, you should even think about signing or encrypting messages. It’s not something everyone needs to do, and if you never need to do it, you need not bother reading the rest of this chapter. But the need could arise at some point—and even if you don’t need to sign or encrypt, you may find that there are some benefits to doing so.

Most of us are accustomed to thinking of email as being private. One person sends a message and someone else receives it; as long as no one is looking over either person’s shoulder or snooping on their computers when they’re not around, we presume that whatever was in that message is known only to the sender and recipient.

Indeed, that’s how things work most of the time, just as with paper letters: Most of the time no one except the intended recipient opens a letter to see what’s inside. But mail theft, tampering, accidents, and honest mistakes do occur. It sometimes happens that a person who shouldn’t see what’s inside an envelope, does. And when the contents of that envelope are highly confidential, sensitive, or valuable, someone else reading your mail can become a serious problem indeed.

Email is no different. It should be private, but it isn’t always. Each message exists not only on the computer of the sender and recipient, but also (at least temporarily) on each party’s mail server. In addition, a message may pass through any number of intermediate servers and routers, and may be backed up along the way in the data centers of one or more ISPs. In any of these places, a message could be read by an employee of the ISP, and it could be intercepted in transit by a hacker—or a government agency—during its journey from sender to recipient.

(“Doesn’t SSL encrypt my messages?” you may ask. SSL secures a message only between Mail and your incoming or outgoing mail server, but doesn’t prevent someone from reading that message while it’s on a mail server, or during other legs of the delivery process.)

Because so many millions of email messages are exchanged every day, the probability that any particular message you send or receive will be read by someone who shouldn’t see it is incredibly small—but not zero. So, consider what would happen in one of these situations if the wrong person read email you sent:

· You need to email your accountant detailed information about your income, expenses, and taxes.

· You need to provide someone with your credit card number, social security number, or other sensitive information by email.

· You’re an executive at a major computer company and you want to discuss top-secret plans for a new product with your advertising agency—but not risk leaking the information to the press.

· You need to discuss a sensitive medical condition with your doctor by email, but you worry that you could lose your job if your employer finds out about it.

· You’re a journalist traveling in a politically sensitive region, and you need to file a story that the local government might find objectionable.

· You’re in a country with significant human rights abuses, and you want to tell your story to the outside world without the authorities finding out.

Get the idea? A lot could be at stake: money, a job, or even a life. In all these cases and countless others, you might need a guarantee—not just a presumption—of privacy, and encrypting email is the only way both parties can be reasonably certain that no one else will read their messages.

Tip: To learn much more about online privacy, including not only email but also Web browsing, file sharing, social networking and other areas, read my book Take Control of Your Online Privacy.

Of course, in addition to legitimate uses, encrypted email could be used to plan crimes, conceal information from law enforcement agencies, and so on. But the point I want to get across is that ordinary people, in ordinary situations, may from time to time feel that the level of security they get from ordinary, unencrypted email isn’t adequate.

That should give you an idea of why encryption may be important, but what about digital signatures? Signing a message (which can be done with or without encryption) enables the recipient to confirm that the message originated from the person whose email address is on it, and that the message wasn’t altered during transit. Given the huge volume of spam we all receive and the increasing incidence of fraudulent email, it’s common to get messages with a forged From address. Using digital signatures can solve this problem. It lets recipients know that the person who appeared to send the message really did send it, and that no hacker has surreptitiously inserted ads or malware, or changed the meaning of a legitimate message.

In an ideal world, every email message would be signed and encrypted. Doing so would eliminate a great deal of fraud, spam, identity theft, and other societal ills. Unfortunately, the world is not ideal. It’s not practical to sign and encrypt everything, because some email clients (and most webmail systems, including Gmail) don’t support encryption, and even clients that do often require either special software or complicated setup steps for both sender and recipient. However, if and when the need arises, you’ll be happy to know that Mail has signing and encryption capabilities, and you can use them with only a modest amount of configuration.

It Takes Two

I want to emphasize that if you plan to use Mail’s encryption capabilities (and even, in some cases, digital signatures), you must first make sure the other party has the necessary software and knowledge to work with the messages you send. You can’t just send someone an encrypted message out of the blue, because it may be impossible (if you lack that person’s public key), and even if it’s possible, it may not be workable (for example, if the other person uses an email client that doesn’t support encryption).

I recommend the following:

· Before sending someone a signed message, explain (in a regular, unsigned message) what you’re about to do.

· If you send a signed email message and the recipient sees an attachment named smime.p7s (or a bunch of gibberish), you’ll know they’re using a client that doesn’t support digital signatures. If so, and if you truly need to encrypt the message(s) in question, you should see if your correspondent can use a different client. On the Mac, examples of clients that support signatures and encryption are Mail, Outlook, and Thunderbird; on Windows, Thunderbird and Outlook are good choices.

· After confirming that signatures work, try sending an encrypted message, and verify that it came through correctly. (It’s best to find out whether there are any problems before sending anything critical or time-sensitive.)

· When either party replies to an encrypted message, they should make sure their reply is also encrypted, especially if it quotes the original message.

Mail’s built-in encryption method, which is free to use but cumbersome to set up, is called S/MIME; I discuss that next. You’re also free to use a third-party encryption tool in Mail, such as the commercial PGP (Pretty Good Privacy) or the free, open-source GnuPG (Gnu Privacy Guard), which is compatible with PGP. I talk about the latter in Use GnuPG for Mail.

Use S/MIME Encryption

Mail’s interface never uses this term, but the underlying mechanism it employs for signing and encrypting mail is called S/MIME (Secure/Multipurpose Internet Mail Extensions). It’s an industry standard that most other desktop email clients understand, regardless of which operating system they use. (I’m happy to say that Apple also includes S/MIME support in iOS 7—see Sign and Encrypt Messages in iOS 7. Unfortunately, many other mobile email clients don’t speak S/MIME.)

Note: The information that follows is slightly technical. You don’t necessarily need to understand how S/MIME works in order to use it, but if you’re curious about what goes on behind the scenes, read on. Otherwise, skip ahead to Get a Personal Certificate.

S/MIME uses a form of public-key cryptography. That means each user has a pair of keys: a public one, normally used to encrypt messages, and a private one, normally used to decrypt messages. So, I can share my public key freely, and anyone can use it to encrypt messages they send to me. However, those messages can be decrypted only using my private key, which I don’t share with anyone. Similarly, as long as I have someone’s public key, I can encrypt a message to that person, but I can’t decrypt that message, or any other message someone has encrypted using that public key.

A key (public or private) is nothing more than a long string of random-looking characters. Keys are normally wrapped in containers that are called certificates, which also include identifying information about the key’s owner and a digital signature from thecertificate authority (the person or company who issued the certificate); the signature lets users verify that the certificate hasn’t been tampered with.

So, to get a pair of encryption keys, you must obtain a certificate, which will contain both your public key and your private key (I explain how in a moment). Mail uses OS X’s system-wide keychain to store certificates—both yours (including both the public and the private key) and those of your correspondents (containing only their public keys). Because Mail communicates with your keychain in the background, just as it does with your account passwords, you normally don’t see or interact with certificates directly.

When you sign a message using S/MIME, Mail does several things:

· It calculates a hash—that is, it performs a mathematical operation on the contents of the message to come up with a unique value. If even a single character in the message were different, the message would have a different hash.

· It encrypts the hash using your private key so that it can’t be tampered with. The encrypted hash is called a digest.

· It includes the digest, along with a certificate containing your public key, inside the message (although this extra content isn’t visible to you, the sender).

The combination of the digest and your certificate enables the recipient’s email program to verify that the message contents haven’t changed during transit, and that your address as the sender hasn’t been forged.

Also notice something interesting about this process. By signing a message I send to you, I also send you my public key—which you can then use to encrypt messages you send to me. So, if two people want to encrypt messages to each other, the easiest way to do so is to first exchange signed—but not encrypted—messages to exchange public keys. (Don’t worry—I explain every step of this process just ahead.)

Encrypting a message is a similar process, except that Mail can encrypt a message only if you already have the recipient’s public key in your keychain. Assuming you do, Mail uses that key to encrypt your outgoing message and sends it (without the original cleartextversion, of course) along with your public key certificate.

Get a Personal Certificate

If you want to sign outgoing messages, or if you want other people to be able to send you encrypted messages, the first thing you must do is obtain an S/MIME certificate. These come in a variety of forms from a variety of sources. If you work for a large organization, your IT department may be able to issue you a certificate. Most individuals, however, go directly to any of several companies called certificate authorities to obtain a certificate.

If you don’t mind paying a good bit of money and going to some bother, you can work through an involved process of proving your identity to a certificate authority and receiving a certificate that includes your name and other identifying information. However, there’s a quicker and easier way to go, with only a modest trade-off: a personal certificate. A personal certificate can be used to encrypt messages just as effectively as any other certificate, but the catch is that the certificate authority certifies only that the email address on the certificate is the same address that was used to request it; the certificate doesn’t include your name or any other personal information. If that’s good enough for you (and it probably is), you can bypass a lot of the hassle and expense usually associated with obtaining a certificate.

Several companies offer personal certificates at reasonable prices, but I know of one—InstantSSL (a reseller for Comodo, the world’s second-largest certificate authority) that gives them away for free, so what I describe here is how to get and install an InstantSSL certificate.

Follow these steps:

1. In your favorite Web browser, visit InstantSSL.

2. Locate and click the Get Now button.

3. In the form that appears, fill in your name, email address, and country of residence. The Key Size (bits) pop-up menu should say 2048 (High Grade), the default setting. Select any remaining checkboxes as desired, choose and enter a revocation password (a password you create that allows you to revoke the certificate, if necessary, in the future), and click Next.

4. Watch your Inbox for a message saying that your certificate is ready to be picked up—normally this takes minutes (or less). (If the message doesn’t arrive within a half hour or so, make sure it’s not in your Junk mailbox.) In this message, click the Click & Install Comodo Email Certificate button.

Your default browser should open and download the certificate. Depending on your settings, it may import the certificate automatically; if not, double-click the certificate file in your Downloads folder. Keychain Access opens; if you’re asked which keychain to put the certificate in, choose Login.

5. You must now tell your Mac to consider your certificate “trusted” (which isn’t automatic, since you did not go through a lengthy and expensive verification process to get it). To do this, open Keychain Access if it isn’t already open, select Login in the Keychains list, select My Certificates in the Category list, and double-click the newly added certificate with your email address to open it in a new window. Click the triangle next to Trust and then choose Always Trust from the When Using This Certificate pop-up menu.

Close the window, enter your password when prompted, and click Update Settings.

6. Quit Keychain Access and close your browser window.

7. Quit and reopen Mail.

You’re now ready to sign messages.

Sign or Encrypt a Message

The buttons you use to sign and encrypt messages are located in the header area of New Message windows (Figure 18). The starburst-shaped one on the right is used for signing messages, and the padlock-shaped one on the left is used for encrypting them.

Figure 18: Use these buttons to encrypt and sign messages.

If you don’t see the buttons in the window, first make sure the From pop-up menu is set to an address for which you have a certificate. Click the icon in the lower-left corner of the header area and choose Customize from the pop-up menu. Then check the box next to those buttons and click OK.

Sign a Message

To sign a message, follow these steps:

1. Compose and address a new message as you normally would, making sure to choose the email address that goes with your certificate from the From pop-up menu.

2. Select the digital signature button; the X on the button label is replaced with a checkmark .

3. Click Send.

If this is the first time you’ve used your certificate to sign or encrypt an email message, you may be prompted to confirm that Mail may use the certificate in your keychain. If so, click Allow or (my recommendation) click Always Allow to grant Mail access to the certificate.

That’s it! Mail appends your digital signature and sends the message.

How your signature appears on the recipient’s end varies from one email client to another, but I explain how Mail handles signed messages shortly, in Read Signed or Encrypted Mail.

Resigned to Sign Again

Once you select the digital signature button, it remains selected for subsequent messages you send, too. This is easy to miss, and more than once I’ve sent out a series of signed messages without intending to. Because some email recipients can’t handle signed messages (in particular, they cause problems on mailing lists), you should keep the signature turned off except when it’s needed.

If you think you might forget to turn it off when you compose your next message, choose File > New Message, turn off the digital signature, and then close the window (click Don’t Save when prompted to save a draft). Mail remembers this setting the next time you compose a message.

Encrypt a Message

Before you can encrypt a message, you must have the recipient’s public key—which means having the person’s certificate in your keychain. You can check on this by launching Keychain Access (you can find it in /Applications/Utilities), selecting Login in the Keychains list, and selecting Certificates (not My Certificates) in the Category list. If the person’s name or email address appears in the list, you should be good to go. If not, ask the person to send you a signed (but not encrypted) message. When you receive it, Mail adds the person’s certificate to your keychain.

That done, follow these steps:

1. Compose and address a new message as you normally would.

2. Select the encryption button; when it’s selected, the padlock icon changes to a closed state .

The encryption button is usable only when an address field (To, Cc, or Bcc) contains an email address for which there’s a matching certificate in your keychain. If you know you have a person’s certificate but the button isn’t enabled, open Keychain Access, double-click the person’s name in the Certificate list to see that you’re using the same email address that the certificate was issued under (since a person can have more than one email address), and that the certificate hasn’t expired. If either of these problems exists, ask the person to send you a new, signed message from the proper email address, or send the message to the listed address.

3. Optional, but highly recommended: also sign the message by clicking the digital signature button, changing it to the selected state.

4. Click Send.

If this is the first time you’ve used your certificate to sign or encrypt a message, you’re prompted to confirm that Mail may use the certificate in your keychain. Click Allow or (my recommendation) Always Allow to grant Mail access to the certificate.

Mail sends the encrypted (and optionally signed) message—that’s all there is to it. (Read on to find out what happens on the other end.)

A few words of caution, however: Although encrypting a message guarantees that it’s scrambled all the way from your computer to the recipient’s, once it has been downloaded and decrypted on the other end, your message could potentially be read by anyone with access to that computer. So, the safe use of encryption requires both parties to take appropriate measures to protect the decrypted text.

Read Signed or Encrypted Mail

Each email client has its own way of handling incoming signed or encrypted messages—and a few can’t handle them at all. Although I can’t explain what the experience is like for every client, I want to describe how Mail works with such messages.

When you open a signed or encrypted message, Mail displays an extra Security header (beneath the To header). Figure 19 shows this header as it appears for a message that’s both signed and encrypted.

Figure 19: When a message has been signed or encrypted, a Security header appears below the To header.

When you receive a signed message, Mail automatically adds the sender’s certificate to your keychain. If you want to view the certificate info from within Mail, click the checkmark icon in the header; a dialog appears with the relevant information (Figure 20).

Figure 20: Click the checkmark icon in the message header to show the certificate, just like this.

In general, that’s all you need to know—you need not jump through any additional hoops to decrypt messages or verify senders. If a message arrives that Mail is unable to decrypt (for example, because your private key doesn’t match the public key the sender used), a yellow banner appears at the top of the message that says “Unable to decrypt message.” Click the Show Details button to see (often sketchy and unhelpful) information about why Mail couldn’t decrypt it.

Searching Encrypted Messages

By default, Spotlight doesn’t index the contents of encrypted email messages, because doing so could permit another person using your account to see these messages during a search using the system-wide Spotlight menu. To turn on Spotlight indexing of encrypted messages, open Mail’s General preference pane and check Encrypted Messages at the bottom, under When Searching All Mailboxes.

Use GnuPG for Mail

Symantec’s PGP (Pretty Good Privacy) software can also encrypt and sign messages using public-key cryptography. Unlike the S/MIME system built into Mail, PGP uses centralized computers called keyservers to hold public keys. The result is that you need not bother with the process of sending your correspondent a signed message to deliver your public key before she can send you an encrypted message; her software can find your public key on the keyserver automatically and transparently.

It’s a great system, but for two tiny catches. First, you have to pay for the software (prices vary according to the license type and duration you choose, but the least-expensive price for a single license is $175). And second, both sender and recipient must have the necessary software to support PGP—it’s not interoperable with S/MIME.

A free, open-source alternative to PGP called GnuPG (GNU Privacy Guard, also abbreviated GPG) gets around the cost issue. It uses public keyservers, just like PGP does—and because it uses OpenPGP, the same underlying standard as PGP, GnuPG users can exchange encrypted messages with PGP users. A Mail plug-in called GPGMail adds the necessary hooks to Mail; it’s part of a larger package of tools called GPG Suite, which also includes GPG Keychain for creating and managing your public and private keys and MacGPG, the engine that powers all the GnuPG components.

GPGMail is far easier to set up than S/MIME, and you need not go to an external certificate authority to get your public and private keys. The software is largely self-explanatory, but you can find detailed instructions on the GPGTools Support site.

With GPGMail installed, you can use the controls it adds to Mail’s windows to send messages using either OpenPGP or, if you also have it configured on your Mac, S/MIME. In fact, when replying to a message, GPGMail is smart enough to use whichever encryption method the sender used. If you’re corresponding with recipients who can use either system, the default is to use OpenPGP, but if you change a hidden setting, GPGMail uses S/MIME unless you tell it otherwise.

Sign and Encrypt Messages in iOS 7

iOS 7 Mail supports S/MIME in much the same way Mavericks Mail does. Unfortunately, even in the best cases, S/MIME is rather complicated for the average user—and iOS 7 has the most confusing, opaque implementation of S/MIME I’ve ever seen. Apple’s iPhone User Guide, whose iOS 6 version contained only three sentences about S/MIME, omits the topic entirely in the iOS 7 version, perhaps because the design is so poorly thought out that documenting it would only make Apple look bad.

Relatively few people need to use S/MIME on an iOS device, and those who do won’t find it anywhere near as convenient as on a Mac. So, fair warning: If you’re not sure this is something you’ll need to do, you’ll be happier skipping all these steps!

Set Up S/MIME in iOS 7

First, you’ll need to turn on S/MIME for each account you want to use it with and get your own certificate onto your iOS device so you can sign outgoing messages. (Unfortunately, I haven’t been able to retrieve new certificates directly from providers like InstantSSL on my iOS devices, so part of this process assumes you already have a certificate on your Mac, as described in Get a Personal Certificate.)

You must turn S/MIME support on, for any given account, to be able to see whether an incoming message received by that account was signed; to add a sender’s certificate to your iOS keychain; or to sign or encrypt outgoing messages. Turning S/MIME on, without changing any other settings, causes no harm and may be helpful, so I suggest that you go ahead and do so for each account. Here’s how to do it:

1. Go to Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced (or, for iCloud accounts, Settings > Mail, Contacts, Calendars > iCloud Account Name > Account > Mail > Advanced; for Exchange accounts, Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced Settings).

2. At the bottom of this view, tap the switch next to S/MIME to turn on or off S/MIME support for that account; when on, you see the Sign and Encrypt options covered below. When exiting the account settings, be sure to tap Done, rather than Cancel, in order to save any changes you’ve made.

3. On your Mac, where you’ve already installed a personal certificate (see Get a Personal Certificate), open Keychain Access (which is located in /Applications/Utilities). Select Login in the Keychains list, select My Certificates in the Category list, and select the certificate with your email address on the right.

4. Choose File > Export Items, leave the name set to its default (Certificates.p12) and the File Format set to its default (Personal Information Exchange (.p12)), choose a location (such as your Desktop), and click Save.

You’ll be prompted to enter and confirm a password. Do so—seriously, do not leave the passwords blank!—and click OK. Then enter your login password (the one for your user account on your Mac) and click Allow (or Always Allow, if you prefer).

5. Locate the certificate file you saved in the last step and email it to yourself as an attachment.

6. On your iOS device, open the email message from the last step.

7. If necessary, tap the attachment to download it. Then tap it again to open it.

8. In the Install Profile screen that appears, tap Install followed by Install Now. If your iOS device uses a passcode, you’ll be prompted to enter it. Then enter the certificate’s password (which you created in Step 2) and tap Next.

9. Tap Done. (If the certificate says “Not Trusted,” don’t worry. As long as you followed the procedure earlier to trust the certificate on your Mac, your iOS device will consider it trusted too.)

To add certificates for other accounts, repeat Steps 1–9 as necessary.

So far, you’ve enabled S/MIME for one or more accounts and added your own certificate(s). So if all you want to do is sign outgoing messages, you’re all set—move on to Work with S/MIME, next. However, if you also want to encrypt messages sent to someone else, you’ll need that person’s public key; we’ll get to that shortly, in Turn On Encryption.

Work with S/MIME in iOS 7

Now that your iOS device is set up to use S/MIME, you might imagine that you can simply turn digital signatures and encryption on or off for each message, as you can in Mavericks. But no! For reasons I truly can’t comprehend, you have to turn signing or encryption on or off for an entire account, in the Settings app; that setting then persists for all messages you send until you go back and turn it off. Furthermore, Mail gives you no visual indication of whether signing is turned on, so you could easily end up sending signed messages when you don’t want to, and vice-versa. It’s silly, it’s wrong, but that’s the way it is.

Turn On Signing

To turn on signing for an account, go to Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced (or, for iCloud, Settings > Mail, Contacts, Calendars > iCloud Account Name > Account > Mail > Advanced; for Exchange accounts, Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced Settings). Tap Sign, turn it on, and tap the certificate you want to use.

In theory, every message you send from that account will be signed, but if you have multiple accounts or addresses, it’s easy to confuse Mail—so do yourself a favor and check two more things:

· When composing a message, make sure the From address is the same as the address on the certificate. If not, tap the Cc/Bcc, From line; tap the From address; and then tap the correct address in the list.

· Make sure the default From address for the account also matches the certificate’s address. (I know, that doesn’t seem like it should be necessary, but in my tests, signing failed if it wasn’t the case.) To do this, go to Settings > Mail, Contacts, Calendars > Account Name > Email (or, for iCloud, Settings > Mail, Contacts, Calendars > iCloud Account Name > Account > Mail > Email) and select the address matching the certificate.

And now your outgoing messages from that account should be signed! Be sure to go back and turn signing off when you want messages to stop being signed.

Turn On Encryption

What’s true of signing is also true of encryption: You have to turn it on or off in Settings. Just as you did for signing, go to Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced (or, for iCloud, Settings > Mail, Contacts, Calendars > iCloud Account Name > Account > Mail > Advanced; for Exchange accounts, Settings > Mail, Contacts, Calendars > Account Name > Account > Advanced Settings). Tap Encrypt, turn it on, and tap the certificate you want to use.

Note: The certificate you choose here is actually used for signing encrypted messages, not for encrypting them—that comes next.

However, there’s another element, which is that to encrypt a message to someone, you need that person’s public key. So, whether Encrypt is turned on or not, Mail won’t encrypt outgoing messages unless the recipient’s public key has been added to your iOS device’s keychain. The easiest way to get it is to ask the other person to send you a signed (but not encrypted) message. Unlike Mail in Mavericks, Mail in iOS 7 doesn’t grab certificates automatically from signed messages you receive. To do this manually, tap the sender’s name (marked with a small seal icon ), tap View Certificate, tap Install, and then tap Done. Repeat with any future signed messages you receive from other correspondents.

When you address an outgoing message—with Encrypt turned on and the right From address selected—Mail tells you whether it can encrypt the message. If the sender’s name is in blue with a closed lock icon next to it and the text Encrypted at the top, you’re good to go. If Mail can’t encrypt the message—usually because you haven’t installed the recipient’s public key—the address is in red with an open lock icon, and the text Not Encrypted appears at the top.

To stop encrypting outgoing messages to people whose certificates are on your iOS device, go back to the Settings app and turn Encrypt off.

Read Signed and Encrypted Messages

As long as S/MIME is turned on for the account where you receive an incoming message, you don’t have to do anything special—you’ll know a message is signed if there’s a badge next to the sender’s name, and you’ll know it’s encrypted if there’s a lock next to the sender’s name. (Messages that are both signed and encrypted have both icons.) You can tap the badge or lock and then tap View Certificate to read its details if you’re interested, but no other steps are required.

PGP/GnuPG on iOS 7

If all of the above sounds like a huge hassle and you’d rather use PGP or GnuPG on your iOS device, I don’t blame you. GPGMail (discussed earlier) is for Macs only, but if you need to send and receive OpenPGP messages on an iOS device, the oPenGP app should do the trick.