Subject: [Cfrg] Email encryption for the wider public

From: Henry Augustus Chamberlain <[email-masked]>
Date: Wed, 17 Sep 2014 15:43:29 +0200

17/09/2014

Hello.

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 [email-masked], 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.

---

From: Henry Augustus Chamberlain <[email-masked]>
Date: Wed, 17 Sep 2014 21:19:40 +0200

I think maybe I didn't make the bit about private keys very clear:
we're talking about proper randomly-generated private keys, just in
PGP. I was just suggesting that since you have to walk around with a
private key file, at least it gives you an excuse to get rid of
passwords, and just authenticate with the server using the private
key.

On 17/09/2014, Ryan Carboni <[email-masked]> wrote:
> The majority of people are no more capable of GnuPG than understanding why
> RAM can't be solely used on a computer.
>
> GnuPG has some weird defaults that are difficult to change as well without
> some command line commands.
>
> Ultimately your system will have a major flaw: passwords are typically have
> low entropy, and anyone with the same password will read the same mail
> unless you concatenate a salt the user has to remember.
>
>
> The ideal system would be to use Tor in conjunction with guerrillamail. Or
> to use a preshared key with a block cipher, and hide the encryption (since
> evidently you want to avert the attention of the NSA to be encrypting in
> the first place) using steganography.
>

---

From: Henry Augustus Chamberlain <[email-masked]>
Date: Wed, 17 Sep 2014 21:48:58 +0200

On 17/09/2014, Maarten Billemont <[email-masked]> wrote:
>
> I'm not sure I understand what problem you've just solved.  Senders still
> need to generate a keypair and encrypt their mail, receivers still need to
> decrypt their mail.  All you've done is remove key lookup and replaced it
> with a From: header.
>

I haven't invented any new cryptography - functionally, it's similar
to what already exists.
But I think the reason that encryption still isn't widely used (after
more than 2 decades!) is the usability. Even if encryption/decryption
are automated, you still need to understand concepts like public keys
and digital signatures in case something goes wrong.

By combining the address and the public key, I think everything makes
much more sense to the end user: when they send emails to some
address, they know it can't be intercepted, and when they receive an
email from some address, they know that it definitely came from there.

The encryption/decryption can be handled automatically by something
like Enigmail, but now the user can easily understand the problem if
something goes wrong: errors will say things like "this email didn't
really come from that address", rather than "this digital signature
doesn't match the key".

---

From: Michael Hamburg <[email-masked]>
Date: Wed, 17 Sep 2014 13:10:01 -0700

What about revocation?

> On Sep 17, 2014, at 12:48 PM, Henry Augustus Chamberlain <[email-masked]> wrote:
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Henry Augustus Chamberlain <[email-masked]>
Date: Wed, 17 Sep 2014 22:22:49 +0200

> What about revocation?

Revocation is interesting, because it's basically a message which is
signed but not encrypted: the sender is a specific person, but the
"recipient" is the whole world.

I guess it would be similar to the current system: you prepare that
message in advance and sign it. If you lose access to your old
address, you get yourself a new one and send out the pre-prepared
message saying that you've lost access to your old address.

Essentially, keys and addresses serve a similar function: both are
"online identities". Keys are used by the cryptographic systems to
identify you, while addresses are used by the email server (and
routing system) to identify you. I think it makes sense to combine the
two.

---

From: Werner Koch <[email-masked]>
Date: Fri, 19 Sep 2014 10:31:25 +0200

On Fri, 19 Sep 2014 06:57, [email-masked] said:

> She can send you email at [email-masked] once, and when your replies
> all come from:
>
>   From: Derek Atkins <[email-masked]>
>
> then when she replies to you, she'll be sending encrypted emails.  But

The same can be achieved with a separate mail header for the key and a
local association of key and mail address for future communication
(which you need for the above scheme also).

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Henry Augustus Chamberlain <[email-masked]>
Date: Fri, 19 Sep 2014 11:33:31 +0200

Hi all,

Some very interesting points so far. To avoid making this email too
long, I'm going to reply without quoting - I hope this doesn't
inconvenience anyone.

Regarding the memorability issue, all I can say is that end-to-end
encryption really does require sharing 100+ bit keys - it's essential!
You may be able to memorise your email address at the moment, but
that's only half the story, since you can't memorise your public key!
I can't solve every problem with PGP, but I still think this proposal
solves a fair few of them. In some cases it improves on PGP, and in
the other case it's at least no worse: you can still use online
institutional directories etc if you want.

Don't forget all the advantages this scheme could bring! Simplicity
and transparency for the end user is really important! They're more
likely to understand the significance of a public key if it forms part
of the address (despite not understanding why it has to be this way).

Perhaps it doesn't help Derek's mum - nor my mum, for that matter -
but there are plenty of people for whom PGP is to complex whereas this
scheme would be manageable. If you wish, you can send some emails
encrypted and others unencrypted, just like you can with PGP - in this
case, you'd just need two addresses (which is surely no worse than
PGP, where you have an address and a key).

Regarding telephone conversations: if it's with a mobile phone,
perhaps a text message would work; if it's a landline, you probably
have internet access, so an initial unencrypted email would work if
you're not worried about man-in-the-middle attacks. (If you are
worried about such attacks, then a bit of effort might be required,
beyond just rattling off a short email address over the phone.)

By the way, I'm suggesting printable characters to encode the key, not
arbitrary bytes. An alphanumeric character stores nearly 6 bits (or 5
if it isn't case-sensitive), so 256-bit keys would require around 50
characters. Email standards allow 64 characters for the local part of
the address, so there's room for error-correction too.

Regarding the point about forged email addresses: for cryptography to
work, you need to identify people using their keys, not their
addresses. With PGP, you could send an email to my mum, using my email
address but the wrong signature; if my mum is just relying on the
email address, then that defeats the purpose of PGP. Of course, most
PGP systems compare the key with that stored in the address book; a
similar system can be used for my proposal, but with the advantage
that forged emails don't give rise to the situation where the address
is known but the key is unknown, which might lead a naive user to
assume something's broken with the crypto software.

Regarding webmail... I still haven't solved that one. Maybe there's an
inherent contradiction in trying to include webmail in an end-to-end
encryption system.

I like the idea of using the "[email-masked]" technique,
although it does contradict the idea of "identify people using the
key, not the address". Also, in my original proposal, I suggested
using the private key (instead of a password) to login to the email
server. I reckon Gmail is unlikely to allow that in the near future :)

Best wishes,

Henry