GPGMail finally works under Mac OS X 10.5

St�phane Corth�sy's plugin that lets Apple's Mail use the open source GPG …

When you think about it, it's ridiculous: almost all of those billions of e-mails that find their way around the globe every day are sent in the clear with no encryption of any kind applied to the message. There are two ways to encrypt e-mail: with S/MIME, built into Apple's Mail application—but this requires getting (read: buying) a certificate—and GPG.

GPG is a command line utility and GPGMail is a plugin that lets Mail.app use GPG to create and check digital signatures and to encrypt and decrypt messages. Unfortunately, as the GPGMail team has put it, "GPGMail is a complete hack, relying on Mail's private internal API. Use it at your own risks!" One of these risks is that Apple brings out OS X 10.4 or 10.5 and it takes many months or even more than a year for an update to come out that supports the new OS. (But complaining is easy; GPGMail is open source, so don't complain too much. Help with coding instead.) Anyway, fairly recently, GPGMail 1.2.0 was released. Leopard users can finally read and write encrypted mail again. Yippee!

For those of you who have no idea what I'm talking about but are still reading:

These days, simply encrypting something is pretty easy. There are several strong algorithms around and computers are plenty fast to run them. The problem is: how do you make sure the intended recipient and nobody else is able to decode the message? This is where public key cryptography comes in. There are several algorithms that have two different keys: a public one for encryption or checking signatures, and a private one for decryption and creating signatures. Simply generate a pair of keys, keep the private one and publish the public one, and you're in business.

Well, not entirely. The problem that remains is how to be sure that a public key belongs to a certain person. For HTTPS/SSL, this issue is handled by "trusted third parties" (I'm sorry, I can't say those words with a straight face) such as Verisign or DigiCert, who provide a certain level of assurance that a public key (in the form of a certificate) belongs to the party the certificate says it belongs to. However, that's not free—not as in beer (certificates cost money) and also not as in speech, because only organizations that can bribe Apple, Microsoft, the Mozilla Foundation, et cetera get to be "trusted" third parties.

This is where GNU Privacy Guard (GPG) comes in. GPG is an open source tool that encrypts, decrypts, signs, and checks signatures. It also manages a "key chain" of public keys and a web of trust. The idea is that, rather than having a list of trusted third parties and trusting them when they say that someone is who they say they are, everyone manages their own trust relationships and exports these for use by others. So, if I trust Jacqui and Jacqui trusts Clint, just attaching her signature to his public key wouldn't ensure me that this public key is indeed Clint's. But if David and Eric also sign Clint's key, that's good enough for me and I'll trust Clint's key, too. (Note that "trust" just means "knows that this is indeed that person's key." It's perfectly reasonable to sign a stranger's key after checking his or her ID.)

GPG is a command line tool, but after installing it and generating a public/private key pair and uploading it to a key server, it's generally not necessary to use the command line—GPGMail adds a bunch of menu items to Mail that make it possible to use GPG from within Mail.

What about PGP here? I own and use PGP Desktop- and it handles encryption just fine, and not just for Apple Mail- but any client using the IMAP or POP protocols. The encryption is also available to AIM IM protocol, though I've never used it myself. GPG is the free alternative to PGP and uses the same keys- PGP is better integrated but costs money.

If I remember correctly, the big problem with a mail encryption program is that it really needs wide adoption to be effective. A couple of people encouraging me to adopt GPG many years ago, but the vast majority of email addressees I send mail have no idea what it does, and are really afraid that installing it will screw up their mail. Some pointed out that because used so rarely, it could possibly bring unwanted attention to innocent mailers by ignorant authorities(just why do you feel you need encryption, sir?).I would be excited if someone told me Gmail, or yahoo mail, etc. is enabling GPG by default. A really wide user base to get the ball rolling.

The writer, Iljitsch van Beijnum, did give the link to Stéphane Corthésy's page at Sen:te. If you go there and look at the GPGMail FAQ you'll see this item:

quote:

Q: Can I install both GPGMail and PGP8/9?A: No. Both plug-ins try to do the same job in the same way (PGPmail is based on GPGMail - have a look at PGP8/9 credits to verify this) and this will create conflicts; sometimes Mail will crash ...

So how can PGP be "better integrated" if it's based on Stéphane's code?

They both work in the same way - by installing a "bundle". That's something that, as I understand, NeXT put into OS X's predecessor as an extension mechanism but which has never been officially supported by Apple. I haven't seen a PGP install, but apparently, it puts its bundle in at the local:

/Library/Mail/Bundles

Whereas Stéphane had used the user level:

~/Library/Mail/Bundles

Basically, they're doing the same thing. You could only get better "integration", if Apple would support PGP/GPG directly in the client - as, for example, KMail and Ximian Evolution do. But, for whatever reason, Apple won't do that either.

The only solution is to use GPG with Thunderbird, which hasn't got native support but has got an official extension mechanism, and get the Enigmail extension. Otherwise, you just have to go with the bundle. PGP uses a bundle, too - it just puts it in a different place. And it seems it's using Stéphane's code anyway.

So you're going to mock Verisign or DigiCert because you don't trust them, but you'll trust any idiot who generates a GPG key?

As Kalkin says: "authentication and encryption are two different goals'.

So it rather depends on whether the key is being used for signing or for encryption.

If Office A needs to exchange documents with Office B - say private financial information - then all that is necessary is that Office A have Office B's public PGP/GPG key. If Office A encrypts the information with B's public key, then the only individuals who can decrypt the information are those who hold B's private key (and who know the passphrase that goes with it).

If you don't need just to exchange information but to prove that it was you that sent the message, then signing comes in. Here the message need not necessarily be encrypted (although it could be). So you could send a message that said, for example:

quote:

Thanks for your email. However, you've been misinformed. I definitely don't authorize you to do that

And you could sign that with PGP/GPG to prove the message was from you.

Likewise, Apple - unaccountably, in view of the fact that its own mail client does not natively support PGP/GPG - can and does use its PGP key to authenticate that security messages are from it. Here's an example:

They only problem with signing is how do you know that the person who obtained and used the key is who he says he is?

I can take out an account at Gmail in the name of "John Smith" - or "Iljitsch van Beijnum" for the matter of that. That doesn't prove I am John Smith. And a PGP/GPG key by itself gets me no further forward. Unless you add another factor in you've really got no guarantee that an email message that's signed with PGP/GPG is from who it says it is than you have with an unsigned message.

With PGP/GPG you're no supposed to sign someone's key unless you know them by sight or they have good quality photo-ID to show that they are who they say they are. Iljitsch talks of signing Jackie's key. But unless he knows Jackie by sight, how does he know that the woman who says she's Jackie and asks to have a PGP/GPG key in Jackie's name signed by him actually [I}is{/I] Jackie?

Linux User Groups and the like sometimes hold Key Signing parties where keys and identities can be checked and proved and keys signed. So you're not "trust[ing] any idiot", you're trusting the "web" of trust, which is a reasonable thing to do.

The real question to ask here would be "How much verification of identity does Verisign or DigiCert do before handing out an S/MIME certificate?" Do they meet you in person? Do they ask for photo-ID?

Originally posted by Kalkin:Well, authentication and encryption are two different goals.

Both would be nice for email, actually, but encryption without great authentication would still make email quite a bit safer to use than it is currently.

Agreed, no authentication means that a man-in-the-middle attack can be plenty effective, but it would remain that the MITM would in fact be necessary. An attacker couldn't just sniff messages in clear text, or as easily go sifting through caches after the fact, and volume matters. If the required resources for large scale sifting are raised by an order of magnitude it would still be a win for general security.

The big problem with encryption and authentication is that no one seems interested in offering the leval of verification and authenticity that would be useful for most people most of the time.

Sure, checking IDs and authority is important when you sign the certificate for a company or an institution but for most people it's going way overboard. The vast majority of us would benefit from a system that provides the same level of authentication that having another friend of ours go, "Yah, that's Jim in the blue shirt" would provide.

I mean the notion that gpg has of the web of trust is the right notion but it's simply not implemented very well. It provides too many choices that are unclear and obscure and not enough automation.

I don't want to blame the gpg guys, they implemented what they wanted to implement and I'm grateful I'm just saying that the missing piece would provide the sorta easy casual authentication we rely on all the time in our offline life.

Iljitsch van Beijnum / Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain.