[cryptography] The next gen P2P secure email solution

[grarpamp]

On Tue, Dec 24, 2013 at 5:01 AM, danimoth <danimoth at cryptolab.net> wrote:
> In these months there was a lot of talking about "metadata", which SMTP
> exposes regardless of encryption or authentication. In the design of
> this p2p system, should metadata's problem kept in consideration or not?
> IMHO exposing danimoth at cryptolab or my <key> it's the same, as there is
> a function between them. I2P and/or Tor adds complexity to avoid such
> mapping to any non-state-level adversary.

I'd assume the design will rightly provide complete end2end encryption between
your source spool and your recipients spool over whatever bits are in between,
as a result of having the key, equivalent to the node, equivalent to
the address.
Store and forward might need to expose only the destination key to the storage
and routing net. A direct circuit would not.

All the legacy 'received' headers are gone by definition. A full raw message
might contain some required bits for continued use with your favorite mail tools
post handoff to you:

>From - As with today, this may or may not end up being authenticateable by the
recipient. Since the net itself would seem to need to be anonymous, then it is
likely not. Nor is it a problem if it is... you just generate yourself
a new node if concerned.
To, Cc, Bcc
Date
Subject
Message-ID
[Threading]
Body

Antispam/antivirus becomes responsibility of the sender/recipient so no
headers there. No legacy dkim, spf, etc, either.

There may be a new set of transport preference headers if the design calls
for it. ie: You might be able to use the net with full mail clients
like mutt, thunderbird.
Or with a light 'messaging' client protocol. Each of which might have
a slightly different
interface into and out of the node.

Addresses might look like:
[user/function or protocol/arbitrary string]@[node pubkey/hash]

I've no idea, only to see if interested people think some sort of nextgen
P2P/DHT system is actually possible at scale.