[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cryptography] The next gen P2P secure email solution

On Fri, May 16, 2014 at 6:01 AM,  <[email protected]> wrote:
>> >> pesky to/from/subject/etc headers.

>> > Those are hidden by use of TLS.

>> weaknesses intrinsic to SMTP discussions?
>> Yes, they are hidden in TLS transport on the wire.
>> No, they are not hidden in core or on disk at
>> the intermediate and final message transport
>> nodes. That's bad.

> There is no way to hide metadata because you need a destination for your messages to arrive ... has to find its destinations to deliver its contents.

I generally meant TLS hides the multitude of headers, but
headers themselves are not today encrypted to the recipient
or to the network, so they end up sitting in the open... and
their SMTP style and purpose totally unnecessary to a new
transport network.

Yes of course... the minimum necessary for delivery is the
destination address. If the network design ends up yielding
control protocol returned from the network to the sender, the
source must be present. Your network client node handles
decrypting the content to find enclosed within (or to configurably
affix if missing) any further traditional headers if needed by your
local messaging agent, routing stack, etc. Such content may
contain the unique address key of your correspondant, be signed
by them, etc.

Dest: unique destination address key
Optional network metadata: ...
Src: optional unique src address key if control feedback
Content: encrypted blob

'Optional network metadata' may be needed depending on
the network design, full of sigs, routing, storage or other data.
But it most certainly won't be SMTP headers as we know them
today. And will be encrypted to shield from all but the most
minimum of nodes possible.

Further, if the network ends up being general purpose
bidirectional, such that you might run IP traffic/apps over it,
the source address key will obviously be required in
either the Src or Content contexts.