In June, Google released an alpha version of its End-to-End (E2E) e-mail encryption extension for Chrome browser. E2E was presented as a response to pressing privacy issues surrounding the revelations about secret NSA and GCHQ programs of illegal mass surveillance. Despite the fact that Google was not wholly uninvolved in these activities, its security experts set out to bring use of e-mail encryption closer to the less technical userdom.
Honesty of intentions aside, although E2E is still in alpha stage, there have been some important developments in both project’s codebase as well as more general considerations on practical cryptography.
E2E is based on OpenPGP – an open standard created in the nineties and firmly holding the position of the least of all evils in e-mail encryption. Although there has been a lot of both warranted and unwarranted critique towards OpenPGP, it is perhaps best to first note how great it is. First of all, OpenPGP works. It is also an old project – that is, tested, checked, broken and fixed many times – and for all these reasons it remains a sound cryptosystem trusted by many users.
However, for those who seek to be one click away from privacy, OpenPGP is pain to use. That is mainly due to its particular key distribution model.
OpenPGP is a standard that implements public-key cryptography. What this means is that each user has a pair of keys – one for decrypting others’ e-mails and one for encrypting one’s own. The key used for encrypting is called public and it has to be imported by others in order to write secret messages addressed to the user who owns it.
In most of today’s implementations, the public key has to be imported manually. That is, other users have to find a way to get it (via e-mail, USB drive or download it from a keyserver) and add it to their keyring. But besides having a repulsive effect on those who are scared by human-unreadable hex codes and other weird strings of symbols, such key distribution model is highly vulnerable.
If someone, say Alice, wants to give Bob her secret key so that Bob can encrypt a love letter to her and only her, the only way to do it securely is by giving the key in person. If Alice sends her key via e-mail, it can be tampered without Bob knowing it. The same goes for storing keys in keyservers. In this case Bob would write a letter that would be read by someone Bob never intended to write, for example an eavesdropper named Eve.
The problem is that key distribution gives a very serious puzzle in cryptography. OpenPGP keys have to be exchanged either unsecurely or in person not because the developers are lazy to implement something better – it’s that no one could really think of anything better.
But E2E developers have suggested a novel way to share public keys. In this model, user registers with a key directory which then releases their e-mail address and a public key. The directory entries can not be modified in any way – and a special third party entity called a ‘monitor’ ensures that this is the case by checking if the entries are valid and do not contain malicious code that could alter the log.
When Alice wants to send Bob an encrypted message, she looks up the key directory to retrieve it and attaches a super-compressed version of this key directory to her ciphertext, similarly to the way each Bitcoin transaction contains all the previous ones – in this way all the other users, including Bob, can easily check that Alice got the same key as everybody else. Monitors too will get these special versions of key directories and will be able to check their validity.
Key directories are somewhat similar to what is now called a keyserver in that it stores multiple public keys belonging to various people. However, keyservers are different in that they do not provide a compressed list of their entries to verify the integrity of the server. Also, there are no third parties monitoring their directories and thus owners of a key server can easily send you the wrong key on purpose.
But the key directory model presented by E2E developers is far from perfect. First of all, a user can be fairly easily attacked by the key directory provider (which is most likely going to be his e-mail provider as well). Given that most online service providers – perhaps paradoxically including Google – are quite fast to trade user data if the payoff is right, this poses a serious problem, because user privacy becomes essentially dependent on the service provider. The integrity of a directory log would highly depend on the monitors – however, who exactly would take up monitoring and, even more importantly, why should the monitors be trusted more than key directory or e-mail providers, remains unclear.
Another shortcoming of the proposed scheme is that the log includes user ID and metadata. This means that all this information is highly vulnerable. Given the informational weight that metadata carries as illustrated by numerous recent examples, this remains a serious threat for privacy.
Several commenters have asked what is the motivation behind storing the actual e-mails instead of hashed identifiers that would not reveal the actual identities. “[…] the benefits of storing a checksum vs. the email itself are still unclear at the moment”, say E2E developers.
But all in all, E2E’s effort to better cryptographic key distribution is a praiseworthy endeavor. Despite the obvious shortcomings of the proposed model, it is a step forward and could even be better than the current OpenPGP or some centralized (such as TLS) key distribution – provided that those who want to verify the keys manually are free to do so. Ideas like these are critical to bringing use of encryption to a wider audience than several privacy-savvy hackers.
Reference: KeyDistribution, End-to-End wiki, source link