[cryptography] Email encryption for the wider public

Kevin kevinsisco61784 at gmail.com
Wed Sep 17 11:35:46 EDT 2014

On 9/17/2014 9:43 AM, Henry Augustus Chamberlain wrote:
> 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 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.
> Version: GnuPG v1.4.11 (GNU/Linux)
> 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+
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
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...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20140917/c6bb2b48/attachment-0001.html>

More information about the cryptography mailing list