[cryptography] Email encryption for the wider public

grarpamp grarpamp at gmail.com
Wed Sep 17 17:14:11 EDT 2014


On Wed, Sep 17, 2014 at 9:43 AM, Henry Augustus Chamberlain
<henryaugustuschamberlain at gmail.com> wrote:
> I propose that we use the local part of the email address to store the public key,
> ...
> my email address would be (64 random letters)@gmail.com
> ...
> Somebody not using encrypted emails could still click on your "mailto"
> link and send you an email, although it will be unencrypted

Putting keys into some_encoding at example.com might cover
some bases related to offline key lookup and message validation.
Most user and system mail tools would need changes to handle
string width and keytype, addressbooks updated, etc. Totally burying
OpenPGP, passphrase and key lookup/use behind a fully integrated
MUA GUI for grandma would work just as similarly well right now today
with no such encoding.

But in the end, all you're doing is covering the message body, and in today's
world that's clearly not enough. No one's yet solving the huge issues
with leaving mail exposed to what is essentially open-for-all-to-inspect central
storage and mail routing. The "who's IP talking to who", "From To Subject,
daemon headers, etc" metadata, when, how much/often, provider logs, someone
sending you unencrypted mail, you giving up your private keys to the
provider or running blobs they provide to you, etc. This is all unfixable with
traditional "Email" models.

This is why that to really solve anything more than the message body,
you need to go completely nextgen and turn that 'email address' into
an anonymous P2P overlay network node address, run your overlay
client [which supplies a mail/messaging front end] and send/receive
mail through that from/to your usual MTA/MUA/messaging toolchain.

The real work there is in pushing the P2P node count up...
- Research how many users globally might leave their messaging
node up 24x7 for a direct realtime overlay connection with the far
end "user at node"... 1/10/100/n*1000 million?
- Develop message storage [and forward/poll/expiry] within the
overlay for those that aren't in online mode.
- Determine any hardware limitations and thin client models.

There is an ongoing thread with the subject
 "The next gen P2P secure email solution"
that contains various people's initial thoughts/framework on this.


More information about the cryptography mailing list