Facebook's email encryption
The adoption of transport layer encryption (TLS) has grown drastically over the recent few years. In part, I have no doubt that Edward Snowdon's revelations regarding alleged widespread surveillance by the intelligence industries caused service providers to reconsider their perspective on using encryption.
Encryption is a technique that can be used to accomplish many things. Most commonly, it is used to protect message contents from unauthorized inspection (confidentiality) and/or alteration (integrity), and to prove that the message came from the person who claims to be the sender (authentication and non-repudiation).
The problem with using cryptographic techniques is that we need secure user-friendly tools to actually implement these techniques, and that we need to develop mathematically sound protocols that actually offer the ability to provide reasonable levels of protection. Furthermore, users must have realistic expectations of what cryptography can provide, and what it cannot. It turns out these are difficult problems to solve.
Remember: even if we develop the appropriate crypto algorithms, and even if we develop secure protocols, we still need to create flawless implementations that are designed in such a way that they are user-friendly, yet at the same time, create reasonable expectations for security and privacy, and don't offer users the ability to downgrade the security provided by making simple mistakes.
At the moment, there really isn't anything out there that addresses all requirements for truly secure communication. And, as it is with crypto, even the hint of a flaw pretty much makes the adoption of a particular set of tools obsolete.
Facebook announced that it will offer the ability to send all email notifications encrypted with a technique called Pretty Good Privacy (PGP). Making that decision takes courage. Fortunately, they decided to use an established cryptographic set of technologies, rather than reinvent something new. While the actual techniques are very similar to those used in TLS, one of the major difference between PGP and TLS is that PGP offers end-to-end encryption, rather than point-to-point encryption. In other words, if your message flows through a number of points on the Internet, it will be protected the entire way, rather than just on one leg of the journey. Secondly, PGP's trust model (the web of trust) is based on fundamentally different assumptions that the public key infrastructure, TLS's trust model.
By supporting email encryption using PGP, Facebook knows that it is targeting a small group of folks who have the ability to generate a private/public key, and know what do to with it. Facebook also knows that it selected one set of tools (PGP), which, even though not perfect, does offer some level of protection. Finally, if users do not manage their secret keys properly, Facebook knows that users will get locked out of their account and might not be able to regain access to it.
Sending the emails encrypted with PGP is only side of the equation. Encrypted messages are worthless, unless the intended recipient is able to decrypt them. In an ideal world, that recipient is also the only one who is able to do so. In order to decrypt encrypted messages, normal every-day users must be given the appropriate tools to do so. While some support is available for dedicated email clients, most notably Enigmail in Mozilla Thunderbird, in the age of web-based email and users who switch between devices and platforms as a rule, more than an exception, finding the right tools to support PGP encryption and decryption has been a challenge.
I recently discovered Mailvelope plugin for Google Chrome and for Mozilla Firefox. The plugin offers the ability to encrypt/decrypt some PGP encrypted messages in web-based environments. It appears to do an okay job in the way that it manages secret keys, and, the first couple of tests, do seem to work well. The product doesn't appear to be as feature-rich as traditional command-line PGP implementations, such as GnuPG. Most notably, I'm not sure yet on how it deals with encrypted attachments and with HTML formatted emails. Both of those are hard problems to crack, so I'm not too surprised. However, for encrypting/decrypting simple messages, Mailvelope does appears to be sufficient.
It is undeniable that by using proper cryptography, the privacy of a conversation is enhanced. However, it also comes at a price. Enterprise information security protections that inspect network traffic for signs of malicious activity will not be able to peer into the protected messages. Especially when it comes to PGP encrypted messages, that is not a problem that any vendor will be able to solve. Because PGP encrypted messages are not-inspectable, widespread use of encryption (if that ever happens), will require enterprise information security teams to rethink they way that they protect online resources.
Finally, without having access to the private keys are are needed to decrypt conversations, the use of encryption will also prevent legitimate law enforcement to obtain access to the content of messages. The same is true for intelligence agencies. How much of a problem that is, is for every individual to decide for themselves.
Encryption is a technique that can be used to accomplish many things. Most commonly, it is used to protect message contents from unauthorized inspection (confidentiality) and/or alteration (integrity), and to prove that the message came from the person who claims to be the sender (authentication and non-repudiation).
The problem with using cryptographic techniques is that we need secure user-friendly tools to actually implement these techniques, and that we need to develop mathematically sound protocols that actually offer the ability to provide reasonable levels of protection. Furthermore, users must have realistic expectations of what cryptography can provide, and what it cannot. It turns out these are difficult problems to solve.
Remember: even if we develop the appropriate crypto algorithms, and even if we develop secure protocols, we still need to create flawless implementations that are designed in such a way that they are user-friendly, yet at the same time, create reasonable expectations for security and privacy, and don't offer users the ability to downgrade the security provided by making simple mistakes.
At the moment, there really isn't anything out there that addresses all requirements for truly secure communication. And, as it is with crypto, even the hint of a flaw pretty much makes the adoption of a particular set of tools obsolete.
Facebook announced that it will offer the ability to send all email notifications encrypted with a technique called Pretty Good Privacy (PGP). Making that decision takes courage. Fortunately, they decided to use an established cryptographic set of technologies, rather than reinvent something new. While the actual techniques are very similar to those used in TLS, one of the major difference between PGP and TLS is that PGP offers end-to-end encryption, rather than point-to-point encryption. In other words, if your message flows through a number of points on the Internet, it will be protected the entire way, rather than just on one leg of the journey. Secondly, PGP's trust model (the web of trust) is based on fundamentally different assumptions that the public key infrastructure, TLS's trust model.
By supporting email encryption using PGP, Facebook knows that it is targeting a small group of folks who have the ability to generate a private/public key, and know what do to with it. Facebook also knows that it selected one set of tools (PGP), which, even though not perfect, does offer some level of protection. Finally, if users do not manage their secret keys properly, Facebook knows that users will get locked out of their account and might not be able to regain access to it.
Sending the emails encrypted with PGP is only side of the equation. Encrypted messages are worthless, unless the intended recipient is able to decrypt them. In an ideal world, that recipient is also the only one who is able to do so. In order to decrypt encrypted messages, normal every-day users must be given the appropriate tools to do so. While some support is available for dedicated email clients, most notably Enigmail in Mozilla Thunderbird, in the age of web-based email and users who switch between devices and platforms as a rule, more than an exception, finding the right tools to support PGP encryption and decryption has been a challenge.
I recently discovered Mailvelope plugin for Google Chrome and for Mozilla Firefox. The plugin offers the ability to encrypt/decrypt some PGP encrypted messages in web-based environments. It appears to do an okay job in the way that it manages secret keys, and, the first couple of tests, do seem to work well. The product doesn't appear to be as feature-rich as traditional command-line PGP implementations, such as GnuPG. Most notably, I'm not sure yet on how it deals with encrypted attachments and with HTML formatted emails. Both of those are hard problems to crack, so I'm not too surprised. However, for encrypting/decrypting simple messages, Mailvelope does appears to be sufficient.
It is undeniable that by using proper cryptography, the privacy of a conversation is enhanced. However, it also comes at a price. Enterprise information security protections that inspect network traffic for signs of malicious activity will not be able to peer into the protected messages. Especially when it comes to PGP encrypted messages, that is not a problem that any vendor will be able to solve. Because PGP encrypted messages are not-inspectable, widespread use of encryption (if that ever happens), will require enterprise information security teams to rethink they way that they protect online resources.
Finally, without having access to the private keys are are needed to decrypt conversations, the use of encryption will also prevent legitimate law enforcement to obtain access to the content of messages. The same is true for intelligence agencies. How much of a problem that is, is for every individual to decide for themselves.