[Cfrg] Email encryption for the wider public

Henry Augustus Chamberlain <henryaugustuschamberlain@gmail.com> Wed, 17 September 2014 13:43 UTC

Return-Path: <henryaugustuschamberlain@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ACF1A040E for <cfrg@ietfa.amsl.com>; Wed, 17 Sep 2014 06:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9zOKWrbfwIb for <cfrg@ietfa.amsl.com>; Wed, 17 Sep 2014 06:43:32 -0700 (PDT)
Received: from mail-lb0-x243.google.com (mail-lb0-x243.google.com [IPv6:2a00:1450:4010:c04::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACCD1A03E6 for <cfrg@irtf.org>; Wed, 17 Sep 2014 06:43:30 -0700 (PDT)
Received: by mail-lb0-f195.google.com with SMTP id u10so544492lbd.2 for <cfrg@irtf.org>; Wed, 17 Sep 2014 06:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5Cwm8YJ6V/d2C3wNTM0RahdUu0yPKUDkah/FC6esQmM=; b=jYJp2UGsw9+IVwlutsVSmfH42DbTaC667qhgvUkAfe+kXVXQf+2EZB59VZC5daAT1Y fx5U2vXxEmABOGWWVbpjhCPo8p4fykpqoT8m7SpDfaRNuXs4ntneQ1bUXsit9LOKFtgi jHw1228AyzNjsSFmV9zCRBROSQTyClxFWCVcxdhd1iD9J1eQ48LFNMS2yQ2wxSbSXaFX AIKDislhSNuK5Jnel4vUwcjNWIR3pF4gDGzTQ30QJTHFL75kyQB+bjJKNLL4jwMmDqO3 9DtO66cQCofkIBShDV4rNlcfLbnZ/W3ACyU7jKztyA3Nd3pszrZuyQNo9aFgJJF0aWGM clig==
MIME-Version: 1.0
X-Received: by 10.152.170.194 with SMTP id ao2mr19049382lac.78.1410961409296; Wed, 17 Sep 2014 06:43:29 -0700 (PDT)
Received: by 10.25.41.145 with HTTP; Wed, 17 Sep 2014 06:43:29 -0700 (PDT)
Date: Wed, 17 Sep 2014 15:43:29 +0200
Message-ID: <CABU-GB37qpwUuTtK15VmykzuR4_-AVQvSFUYXO=W8VC3J2hEFA@mail.gmail.com>
From: Henry Augustus Chamberlain <henryaugustuschamberlain@gmail.com>
To: cryptography@metzdowd.com, cryptography@randombit.net, cfrg@irtf.org
Content-Type: multipart/alternative; boundary="089e011615f297ceab0503430d9c"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/RgMQUGmCkghBbjwq48gU8bZXwf8
Subject: [Cfrg] Email encryption for the wider public
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Sep 2014 13:43:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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 HenryAugustusChamberlain@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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUGY8lAAoJEIvCuPSbZIqXRvQP/3L5igSHyhmEQ+SiHWPSxT0m
N/t3TTxxFxQ6hO/kwI3kasVOEQL7csSyRXCQP4nSM8OqLkj2HU8fCMt+ytVrSdqp
c/Y2WyQczlcy8nIKfOi3Ua6fxd/WpUFV4BtSLbJ+BV/XIuzH8lXYJIiV0DRbVOlo
3I16IIWNDWNRc8pDp0v7olwsbA2pROWJhOb1bJ2uyiyxIGhREEx0smKs2DNKtyCI
DUxNkpF6yxLRTBoH4UT2Q5Q/D8A2X0n+6EvcpBpkf/BKcoky9tRpnhJrzd59n8AY
Clr2+DRcZbJv3JC3eVSOdsLUKvadznvvLx3JlbQWTGlXOMuA6vGmOFkxHozqrZWU
RwotrmoC2YLj0yAnxxaaTlvcmkGRJU04p/8js5KuDNcPbhkLg0Ld3P+Cqo/x7+db
ntRGudUn3mSu44cxLNF/IPqqrr9Y6FZlFRvjddIQ/YXTQ46cQVQnawOk+twM8Uk/
lLnX0u17+jIjUmwSoRBCTZKMfSxDLY71yPrej86MVFrUKNq2qeAC83lmJBcHF6zb
4K3W5IoWhGkAuJHLkwlW9wlCin9tKLnoRXHN0CAaVFc63o5ZWxinJlf7J7ml1q90
zIZyyCaGWLVfUD7RD8nw9FEMUVwEW+4zm4A9mudegJdvKmt7nxmKG1qHwrDfWKON
j19BQ7StRyX1WEa0W6JK
=MiF+
-----END PGP SIGNATURE-----