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

[Odinn Cyberguerrilla]

my slightly selfish plug for my recent blog post on open source /
decentralization / etc.
             |
             |
             V
"please read and share (or comment on, critique, use as virtual toilet
paper, etc..." :-)
https://odinn.cyberguerrilla.org/index.php/2014/01/02/opensourcebuildguide/



> On Mon, Dec 30, 2013 at 12:34 AM, ianG <iang at iang.org> wrote:
>> On 28/12/13 09:24 AM, grarpamp wrote:
>>>
>>> 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.
>>
>>
>> So sad.  I have a clue and don't trust Skype.  But I can't for the life
>> of
>> me migrate my friends off of it.  It's as addictive as crack.  It's just
>> better than the alternatives.
>>
>> As a serious business problem, if one wants to share documents on a
>> frequent
>> basis, which system would one choose for security?  Skype, google docs
>> aka
>> drive, or something else?
>>
>> I need something that ordinary people can use.  So no complicated
>> "download
>> this on 100 machines and ..."
>>
>> Also, should be free and can make a nice cup of coffee.
>
> There is slick, and then there is utility. I'm seeing some good utility
> in a few of the listings on https://www.prism-break.org/ . When it comes
> getting utility done, it's not to hard to introduce (even firmly) people
> into using utilities. Slick helps, but it's not required, and will come in
> time. Everyone throws up BS about adoption and thus nothing ever
> gets built, or even researched, screw that, I say build it and see.
>
> I also question a few of those listings.
>
>>>> 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.
>>
>>
>> I'm going to make a call here.  I reckon that future phone bandwidth and
>> batterywidth will be sufficient to close the gap, to the point that this
>> problem goes away.
>>
>> So, moving away from p2p notions that are popular with the
>> one-laptop-per-everyone western world would be the wrong strategy.
>>
>> Although it seems that the phone market is 'different' it is catching up
>> fast in the things that matter.  Right now, the only thing where they
>> are
>> arguably short is VoIP.  Hell, they're happy watching utube on phones...
>>
>> But that's no problem because in today's world, what dominates is chat &
>> apps.  Lack of good VoIP over phones is just a short term issue.
>>
>> (It's a prediction, not a claim!)
>
> I agree with this hardware path, especially for the subject of p2p
> secure messaging.
>
> I think voip is currently not a user priority on devices with a cell
> stack because that
> stack is already activated and paid for. With good apps and wider access
> to free
> wifi in particular, encrypted voip should take off. Or we will see
> more use of cell
> based IP plans. Another twist is going out of voiceband to get the key
> material
> of your peer, then with the more open phones out there, grab the cell
> mic/vocoder/modem
> on them and stuff your encrypted voice over that if voip doesn't work
> at that moment.
> But that's way off topic to p2p secure messaging... at least until
> that hardware path
> allows for p2p secure <everything>.
>
>
>>>> 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.
>>
>>
>> In the market I'm in, people are very used to switching off Apps when
>> they
>> see the bandwidth being sucked.  Just an observation...  I think it's a
>> problem that solves itself, a warning to developers that they have to
>> think
>> outside their tech box.
>
> Right... I think not everything has to run in RAM... we have a few GiB
> to store the network state in, as a sliding tradeoff for reconnection
> speed
> when switching them back on. CPU is another available slider. So is
> network rate/transfer limits.
>
>
>>> 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.
>>
>>
>>
>> I see this as rather a rich western world observation.  It probably
>> works
>> for Apple.  It doesn't so much work in the non-rich world, where things
>> are
>> much more widely driven by Android, etc.
>
> I gather Africa does a lot of things with simple text messaging on
> simple non-I/Android/MS/Unix phones. What is their path for phone tech
> advancement, and when?
>
> Is it reasonable to expect to truly need to develop for more than the
> 'West' as a userbase? Keep in mind the West now probably includes
> China and many other places, so we're looking at more than 1B nodes
> anyways. We probably mean 'Western class' of phones. And by the
> time a p2p secure messaging platform the subject of this thread is
> deployed in a handful of years, that class will be much more widespread.
> So perhaps natural convergence of this software and hardware will occur.
>
> Yes there are West/first vs. second/third disparities, if everyone
> waited we wouldn't have what 'western' tools we have today.
> There are folks in the west that need them too, even to work on
> solving those disparities, so it is not much of an argument to expect
> to limit develop only for western class HW.
>
> See what you can build for intel/amd CPU's.
> See what you can fit in ARM, snapdragon, android, etc.
>
>
>
>>>> 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.
>>
>>
>>
>> Easy to say :)  And then you meet your users, and they don't want that,
>> they
>> want something different.
>
> ie: I2P has it's main repo in .i2p and some anon developers.
>
> I don't see bootstrapping into the net via peers as 'unwanted',
> they are your trusted real world friends for the most part. What
> your app does after that with the network db it learns from that
> doesn't necessarily need to involve your friend anymore.
>
> What don't they want? A little less initial security for a day while
> the app crunches and sorts things out? Possibly selecting a trust chain
> other than that introduced to them by their friend? Reading the
> public consensus on that?
> It sounds like the BS adoption issue people like to claim in
> order to not build anything.
> Granny learned to surf the net, so Johnny can learn to encrypt.
> And both of them know how to read the manual. Seriously.
>