Re: [Cfrg] Email encryption for the wider public

[Henry Augustus Chamberlain <[e-mail]>]

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 "[e-mail]" 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