[cryptography] Email encryption for the wider public

Henry Augustus Chamberlain henryaugustuschamberlain at gmail.com
Wed Sep 17 09:43:29 EDT 2014

Hash: SHA1



I think I might have a way to make email encryption easily accessible to
the general public, and would be very grateful if you could share any
comments you might have.

I think the existing algorithms (RSA, Diffie-Hellman, Elliptic Curve
equivalents) are perfectly sound, as are the software programs (GPG and
email client plug-ins), but the user is still required to understand
concepts like public/private keys and digital signatures. I think these
conceptual difficulties are what are holding back a more widespread
adoption of email encryption, and this is what I wish to solve. (See "Why
Johnny Can't Encrypt".)

I propose that we use the local part of the email address to store the
public key, so instead of HenryAugustusChamberlain at gmail.com, my email
address would be (64 random letters)@gmail.com. (This is by no means a new
principle - Bitcoin does something similar, although it uses a hash of the
public key rather than the key itself.) RSA keys are too long, but elliptic
curve keys would work fine.

I think combining addresses and keys actually makes intuitive sense. When
you send an email to a particular address, you expect it to be read by that
person and no-one else. Likewise, when you receive an email from some
particular address, you expect to have originated from that address and
nowhere else. This is precisely what public-key encryption guarantees, by
means of encryption in the former case and digital signatures in the latter
case. Using keys as addresses would remove the need for the user to
understand public keys, encryption and digital signatures: everything would
"just work" automatically - without compromising security in any way.

Having long (and unmemorable) email addresses would certainly create some
problems, although perhaps fewer than one might initially imagine. "Mailto"
links on web pages would continue to work as they always have done, as
would institutions' email directories and private individuals' address
books. Exchanging email addresses in person might be problematic, but QR
codes might be of use here: they can be displayed on a smartphone screen or
printed on business cards. Passing email addresses over the telephone
remains a problem (although in the case of mobile phones, a text message
could be used instead).

Somebody not using encrypted emails could still click on your "mailto" link
and send you an email, although it will be unencrypted (and they would
probably ask you why your email address is such a strange one!). Perhaps
some people might choose to add a footer to unencrypted emails - like
Hotmail used to do - explaining that they use encryption, and encouraging
others to do likewise.

The issue of private keys still remains, but perhaps they could take the
place of passwords: when configuring a desktop (or mobile) email client,
one would provide a private key file (or a QR code) instead of a password.
SSH already allows users to login using public key certificates rather than
passwords. Configuring a phone (or new PC) is only ever done once, so
hopefully this small hurdle would not impose an undue burden on the user.
Webmail would be tricky to use, since a user could hardly be expected to
memorise a 64 character password, but one might question whether webmail
can have any place at all in an end-to-end encryption system.

In summary, I believe my proposal would allow encrypted emails to very
closely resemble the existing unencrypted system that users are accustomed
to. As far as the user is concerned, encrypted emails work just like normal
emails, except that the email addresses are longer, and their password is
replaced with a QR code that needs to be printed off and stored somewhere
safe. In return for this, their messages are guaranteed to be encrypted
end-to-end and digitally signed, or from the user's point of view, emails
would "just work" the way they should: "To Mr X" means that only Mr X can
receive it, and "From Mr Y" means that only Mr Y could have sent it.
Version: GnuPG v1.4.11 (GNU/Linux)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20140917/7fcb4314/attachment.html>

More information about the cryptography mailing list