[cryptography] Email encryption for the wider public
kevinsisco61784 at gmail.com
Wed Sep 17 11:35:46 EDT 2014
On 9/17/2014 9:43 AM, Henry Augustus Chamberlain wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> <mailto:HenryAugustusChamberlain at gmail.com>, my email address would be
> (64 random letters)@gmail.com <http://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)
> -----END PGP SIGNATURE-----
> cryptography mailing list
> cryptography at randombit.net
As someone who deals with security measures each day I need to come at
it from that angle. Your method is great save for the fact that
spammers love spoofed addresses. I doubt anyone could trust something like
abcdcdhhiklklklmnfffffff at hotmail.com
Am I missing something? If I'm not, it seems more measures should be
taken. What about digital signatures? Would you change the scheem?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography