[Cryptography] The next gen P2P secure email solution ["meta" data]

grarpamp grarpamp at gmail.com
Wed Jul 16 01:32:11 EDT 2014


On Tue, Jul 15, 2014 at 5:03 PM, John Denker <jsd at av8n.com> wrote:
> http://www.metzdowd.com/pipermail/cryptography/2014-July/022150.html
> It seems to me that the binary distinction between "metadata" and
> other data is a crock.  As a glaring example of the problem, common
> protocols for encrypted email encrypt only the main body of the
> message, leaving /all/ the headers unencrypted.  This is a serious
> security breach, as discussed below [*].
>
> We can do better than this.  We need to do better than this.
>
> At first glance, one might think that "data is data" and we should
> not distinguish "metadata" from other data, but actually I wish to
> go in the other direction, and distinguish /more/ classes of data.
> ...
> Let's be clear:  A great deal of the stuff that appears in RFC822
> headers is not needed for delivery of the message, and MUST NOT
> be sent in the clear.
> ...
> To say the same thing another way:  Assume the law of the jungle.
> The only privacy rights you have are the ones you can enforce on
> your own, using the strength of your cryptography.

Well, when you give up those rights by still disclosing your
source IP and trusting your 'destination organization' [aka provider]
with address info regarding you and who you're mailing... it's not much
of a solution. Put in as many classes as you want... besides the body
of the message which you control, you can't fix centralized Email.

Here's another class of provider and browser based non solutions...
https://cpunks.org/pipermail/cypherpunks/2014-July/004894.html

There's a thread of this subject ongoing that acknowledges Email
can't really be fixed against the issues of the day... and discusses
other possible messaging designs towards a next gen solution...

https://cpunks.org/pipermail/cypherpunks/2013-December/002638.html
https://cpunks.org/pipermail/cypherpunks/2014-July/004900.html

The goal is likely one or both of these over an anonymous P2P network...
o  direct delivery to your recipients online node.
o  stored delivery to same (push or pull, only exposes destination).

More interesting than wasting time on futility of old Email.


More information about the cryptography mailing list