Facebook just announced support for PGP, an encrypted email standard, for email from them to you. It’s an interesting move on many levels, albeit one that raises some interesting questions. The answers, and Facebook’s possible follow-on moves, are even more interesting.

The first question, of course, is why Facebook has done this. It will only appeal to a very small minority of users. Using encrypted email is not easy. Very few people have ever created a PGP key pair; many who have done so have never used it, or simply used it once or twice and forgotten about it. I suspect that a significant number of people (a) will try to upload their private keys instead of their public keys; (b) will upload it, only to discover that they no longer remember the strong password they used to protect their private keys; (c) will realize that they created their key pair three computers ago and no longer have PGP installed; or (d) more than one of the above.

The nasty cynical part of me thinks it’s an anti-Google measure; if email to users is encrypted, gmail won’t be able to read it. It’s a delightfully Machiavellian scheme, but it makes no sense; far too few people are likely to use it. Unless, of course, they plan to make encrypted email easier to use? That brings up the second question: what will Facebook do to make encryption easier to use?

Facebook is, of course, one of the tech titans. They have some really sharp people, and of course they have the money to throw at the problem. Can they find a way to make PGP easy to use? That encompasses a wide range of activities: composing encrypted and/or signed email, receiving it and immediately realizing its status, being able to search encrypted messages—and doing all this without undue mental effort. Even for sophisticated users, it’s really easy to make operational mistakes with encrypted email, mistakes that gut the security. To give just one example, their announcement says that if “encrypted notifications are enabled, Facebook will sign outbound messages using our own key to provide greater assurance that the contents of inbound emails are genuine.” This could protect against phishing attacks against Facebook, but if and only if people notice when they’ve received unsigned email purporting to be from them. Can this work? I’m dubious—no one has ever solved that problem for Web browsers—but maybe they can pull it off.

The third big question is mobile device support. As Facebook itself says, “public key management is not yet supported on mobile devices; we are investigating ways to enable this.” Their target demographic lives on mobile devices, but there is not yet good support for PGP on iOS or Android. There are outboard packages available for both platforms, but that’s not likely to be very usable for most people. Google has announced plans for GPG support for gmail on Chrome; it would be nice if they added such support to the built-in Android mailer as well. (Oh yes—how do you get the same key pair on your mobile device as on your laptop or desktop?)

The last and most interesting question is why they opted for PGP instead of S/MIME. While there are lots of differences in message formats and the like, the most important is how the certificates are signed and hence what the trust model is. It’s a subtle question but utterly vital—and if Facebook does the right things here, it will be a very big boost to efforts to deploy encrypted email far more widely.

One of the very hardest technical things about cryptography (other than the user interface, of course) is how to get the proper keys. That is, if you want to send me encrypted email, how do you get my public key, rather than the public key of some other Steven Bellovin or a fake key that the NSA or the FSB created that claims to be mine? (I’ve put my actual PGP key at https://www.cs.columbia.edu/~smb/smbpgp.txt, but of course that could be replaced by someone who hacked the Columbia University Computer Science Department web server.) PGP and S/MIME have very different answers to the question of assuring that a retrieved key is genuine. With PGP, anyone can sign someone else’s certificate, thus adding their attestation to the claim that some particular key is really associated with a particular person. Of course, this is an unstructured process, and a group of nasty people could easily create many fake identities that all vouch for each other. Still, it all starts with individuals creating key pair for themselves. If they want, they can then upload the public key to Facebook even if no one has signed it.

By contrast, S/MIME keys have to be signed by a certificate authority (CA) trusted by all parties. Still, in many ways, S/MIME is a more natural choice. It’s supported by vendor-supplied mailers on Windows, Macs, and iToys (though not by the standard Android mailer). Facebook is big enough that it could become a CA. They already know enough about people that they’ve inherently solved one of the big challenges for an online CA: how do you verify someone’s claim to a particular name? At the very least, Facebook could say “this key is associated with this Facebook account”. No other company can do this, not even Google.

This, then, is a possible future. Facebook could become a de facto CA, for PGP and/or S/MIME. It could sign certificates linked to Facebook accounts. It could make those certificates easily available. It could develop software apps, desktop or laptop programs, what have you—that go to Facebook to obtains other people’s keys. The usability issues I outlined earlier would remain, but when it comes to certificate handling Facebook has advantages that no one else has ever had. If this is the path they choose to go down, we could see a very large bump in the use of encrypted email.