[p2p-hackers] The next gen P2P secure email solution

[grarpamp]

On Wed, Dec 25, 2013 at 7:21 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> So there's already a system that until very recently did peer-to-peer
> delivery of messages over encrypted channels between hosts that participated
> in a peer-to-peer overlay. It was Skype.

Afaik, skype used a central lookup to get to unknown peers, not a DHT.
So they perhaps knew who wanted to talk to who. Of course now skype
is untrusted by anyone with a clue.

> And none of these proposed solutions are viable until there's a solve for
> the very reason that Skype is moving away from P2P technology... and that is
> that the majority of the billions of new users joining the Internet over the
> next few years are doing so with the only Internet-accessing device they
> have: a mobile phone. When they're on WiFi, the bandwidth is good, but they
> sleep most of the time even in that case to preserve their otherwise meager
> battery life... and when they're on 3G/4G, the bandwidth isn't as good and
> it can be very expensive, and it burns the battery up even faster.

Sure, there's a class of users that want this, a big class. They can
have and use their modified legacy centralized email as they wish.
There's another big class that want's something more than that.

We're also going to see faster hardware, lighter code, and maybe
even wearable battery packs... because as you say, these users
want it all and are willing to go to almost any means to get it.

There could also be ways to make the heavier weight anonymous
routing p2p transport let these lightweight clients stub in just to make a
direct p2p connection for encrypted voip/messaging (if say you
published your node as accepting that option).

> These users want to be able to send and receive messages when their device
> is on, but the recipient's device isn't. Because most of the time, the
> recipient's device, even if they put it in their pocket 10 seconds ago, is
> already asleep, trying to preserve as much battery as possible.
>
> That pretty much eliminates all designs that do direct transfer from sender
> to receiver, irrespective of the traffic analysis risks of doing so.
>
> Additionally, it also means that nearly all the participant nodes are also
> unable to participate in a peer-to-peer overlay network, because they can't
> afford the network uptime (and consequent battery drain) necessary.

We're exploring ideas. What is to say we are able to develop into it some
kind of automaton taho-lafs delivery storage nodes. Storing messages in
transit under some expiry policy is not a huge space concern. So who knows.

Maybe everyone with their uber important phones will end
up VPN to their home/colo servers where the horsepower is.

Predicting mobile is hard. Throw more apps out there and your
$30-50/mo unlimited data plans go away. Now is everyone going
to pay $150+/mo for that? Where is free open wifi going to end up
spanning? And so many other things.

What I think is clear is that there will for the far to indefinite forseeable
future be some form of real workstation/laptop in the home and office.
Phones just can't replace that. Maybe we're seeing something in how
you see larger tablet/netbooks/laptops with headsets being carried about
now as if it is natural. And lots of those people will want a highly
secure system to communicate over with their peers in this new
world of disgustingly gratuitous surveillance and databasing.
I would not underestimate the demand for that sort of a comms system.

> So we're back to fetching the email off of servers, and just having the
> paths between the servers be over this magical new peer-to-peer network.
> Only that's already approximately what we have now.

That could be the multimodal thing above. Or the in network thing.

> Oh, and those servers can do interesting things you can't do at the receiver
> nearly so well, like correlate likely spam between recipients and drop it...
> or detect viruses before they're delivered, and drop those.

DSPAM, spamassassin, clamav and the like do fairly well enough
on their own locally.

I suggest not cataloging a defeatist list of what you think you can't
do... but rather what you could do, what you would gain and what
could happen if you build it :)

> ps. And then there's the other unsolved problem: If you do actually build a
> popular service that lets people securely exchange messages, the government
> comes with an order to reveal the content of the messages, and threats to
> lock up the principals if those demands aren't met. I wish I could tell you
> more stories about this, but of course I'm subject to the same sorts of
> non-disclosure that everyone else who's ever gotten one of those is.

That's why you should be doing the development of these new
protocols entirely within existing secure networks such as Tor
and I2P. And why you should bootstrap via peers instead of
clearnet authorities like Tor that can be shutdown... it's a little
less secure, but you can have in network authorities wrapped
in web of trust and then rejoin listening only to them later. And
if clearnet get''s that bad, it becomes a freedom of speech issue
which is well, SHTF time.