The next gen P2P secure email solution

[grarpamp]

This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today. There was
a former similarly named thread on this that diverged... from the
concept and challenge of P2P/DHT handling the transport and
lookups... back to more traditional models. This thread does not
care about those antique models, please do not take it there.

In short, we're attempting to examine and develop some form
of new transport that looks somewhat like a mix between secure
anonymous networks, ***@pubkey node addressing, massive
decentralized dht-like scaling and finally a user facing daemon that
moves messages into and out of local spools for use by normal
user/system tools.

Pasting in a very rough and unflowing thread summary to date
for interested people to pick up and discuss, draft, etc.

=====
grarpamp...

[pgp/smime email encryption, etc]
What is the gap we have to close to turn this on by default?

How many times has this been rehashed the last six months?
You can't fix email as we know it today using todays bolt-ons,
protocols and corporate stakeholders/services trying to profit from it.
The only way to have any real global seamless success is to go
ground up with a completely new model. IMO, that will be some
form of p2p message system where every address is a crypto key,
masked for grandma by her contact list, decrypted out your p2p
daemon and piped into your local mail processing (MUA/filter/lists)
and filesystem (encryption). At least that way your local mail tools
will still work (no one will give those up anyway).

The problem is the antique centralized backend, it needs bypassed.
You've got neat stuff like Tor, bittorrent, bitcoin, etc already... so
boost email into the 2020's the same way. Then let the old world
email services try to keep up, and slowly die like everything else.
=====
grarpamp...

But of course you're right about actual current usage, encrypted email
is an
epic fail on that measure regardless of format/protocol.

Yes, but it's about time we do something about that. Do we *exactly know
why* it is such a failure?

It's an interesting question, and one worth studying for pedagogical
motives. From my experiences from both sides, it is clear that both sides
failed. But for different reasons.
Hence, I've concluded that email is unsecurable.

Obviously. It will never be able to escape the non-body
header content and third party routing, storage and analysis with
any form of patching over today's mail. And it's completely
ridiculous that people continue to invest [aka: waste] effort in
'securing' it. The best you'll ever get clients down to is exposing
a single 'To:' header within an antique transport model that
forces you to authenticate to it in order to despam, bill, censor
and control you.

That system is cooked, done and properly fucked. Abandon it.
What the world needs now is a real peer to peer messaging
system that scales. Take Tor for a partial example... so long
as all the sender/recipient nodes [onions] are up, any message
you send will get through, encrypted, in real time. If a recipient
is not up, you queue it locally till they are... no third party ever
needed, and you get lossless delivery and confirmation for free.
Unmemorable node address?, quit crying and make use of your
local address book. Doesn't have plugins for current clients?,
so what, write some and use it if you're dumb enough to mix
the old and new mail.

The only real problem that still needs solved is scalability...
what p2p node lookup systems are out there that will handle
a messaging world's population worth of nodes [billions] and
their keys and tertiary data? If you can do that, you should
be able to get some anon transport over the p2p for free.

Anyway, p2p messaging and anonymous transports have
all been dreamed up by others before. But now is the
time to actually abandon traditional email and just do it.
If you build it, they will come.
=====
fabio...
I'm strongly against most the ideas to abbandon current email systems,
because the results will be to create wallet garden.

We need something interoperable with existing systems or the system will
just be used by a bunch of paranoid people or fostered by the marketing
of few cryptography company acquiring customers, not user.
=====
grarpamp...
It would be interoperable with current end user interfaces/tools, but not
directly with you-5VMuGeU+***@public.gmane.org
As with everything else, today's seeds grow into tomorrows garden, sometimes
you just have to thorougly plow under last year's chaff first, that's by design.
=====
viktor...
E-mail is basically business correspondence.

- E-mail is stored.
- E-mail is sent to many people outside your personal social network.
- Business recipients of email are often subject to corporate and/or
regulatory policy constraints that are in conflict with end-to-end
encryption.

The above list of features can be greatly expanded, and the
consequences elaborated, but I doubt may on this list truly need
to be re-educated about email.

So I will confidently predict that end-to-end secure email will
remain a niche service used by a tiny minority.
...

Even businesses that one might expect to implement at least encryption
to the "gateway", are in many cases choosing to out-source their
gateway to 3rd-party providers (anti-spam and anti-virus offerings
only work with un-encrypted email, and in many cases the provider
also operates the entire mail store).
....
[and others also said: tls, dane, skype, smime, ca's, smtp, etc]
=====
Jerry...
Medical, Financial
=====
grarpamp...
Nothing here changes, only the backend transport between nodes.
Once your node decrypts the message to your local system pipes,
you can do all this and more with it. Including running a 'business' node
and doing whatever you want with the plaintext after your node daemon
passes it to you. This is not about those ancient protocols. It's also
about 'messaging' not strictly 'email'... those lines are already well
blurred, no need to distinguish between them anymore. A 'light'
messaging client could simply ignore the non transport email headers,
or use your standard ***@nodekey address.
Please do not continue to talk about antique tradional centralized
systems in this thread, except of course to bash and route around them.
The speed of a real P2P/DHT replacement at scale is a research challenge.
=====
coderman...
this would make an interesting bet! i too believe this to be
impossible given the constraints.
=====
grarpamp...
I'm not so sure about this, look at all the global resources being poured
into traditional email, and attempts to 'fix' it. Now redirect fractional 1%
of those resources and put them into a P2P replacement. That's ftw.
=====
natanael...
Say hello to Bote mail on I2P.

I2P provides encrypted anonymizing networking, Bote mail provides DHT
based serverless encrypted mailing with public crypto keys as
addresses (ECDSA or NTRU).

http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add
.us to visit it via an inproxy).

There is also I2P Messenger that is encrypted P2P IM within I2P also
using public keys as addresses.
=====
cane...
You may have a look of "I2P Bote" it is severless, encrypted mail
system, address is the public key, P2P based... nice tool.

https://en.wikipedia.org/wiki/I2P#E-mail
=====
grarpamp...

You may have a look of "I2P Bote" it is severless, encrypted mail
system, address is the public key, P2P based... nice tool.

As in another post of mine, I'll be looking at that again.
My first take was that it stores the messages in the DHT,
which didn't seem scalable or reliable at all. I may be
wrong as I read more later.

Afterwards you can add the "I2P Bote plugin", the serverless mail
system. SMTP- and POP3 support was on the ToDo list some times ago, I

I think that's working now. And is the general idea, create a strong
overlay network with a frontend MUA's can speak to.

As an aside: If you can make that overlay net present an IPv6 tunnel
interface on the local host, that lets you use any IPv6 enabled
app over it. I'm doubting the world needs a dozen application
specific overlay networks. More like just a few classes of network.
- message based store and forward
- low latency IPv6 transport
- data storage and retrieval
=====
natanael...
Bote mail doesn't have to be used for it's anonymous properties, for
me that is just a bonus. For many people it is more than enough to be
able to know that it is impossible for anybody else than the intended
recipient to read the message thanks to public key addressing.
Guaranteed end-to-end security if you can verify the address.
I don't think anything that doesn't fundamentally rely on public key
addressing is the (long term) future. There will inevitably issues
otherwise, including more issues of the type we have with CA:s today.
For those who want to make it more user friendly, nothing stops you
from adding a transparent "address translation layer" where servers
are involved. When you want to send a message to a person with a human
readable address at a server, then the server could then reply with
the public key based address to the mail client, and the user would
have the option to see what that address is. It could even be logged
by the client, with TOFU/POP style trust system that reduces the
amount of trust you have to place in the server. No need to trust
anybody with plaintext.
=====
grarpamp...
I suggest such interfacing with the current legacy system will only prolong
it's long past due extinction. Build a better system and let them come to you,
not the other way around. And bolting in exits will only make it harder to
do correctly and optimally what you need to do as a P2P system. Please,
just forget about interfacing with the legacy transport system. If you really
need that you can run your own p2p daemon node that acts as your
automated gateway between the two. This is mostly about design of
the p2p side, not that.
=====
james...
It is my understanding of the proposed replacement for email. Magic
email addresses that in fact correspond to an identifier of a public
key, for example the hash of a rule that identifies the public key,
and which result in your message not in fact being passed along by
email protocols.
=====
grarpamp...
If you're not going to send directly to the very long ***@nodepubkey, then
yes, you'll need to create another layer on top to hold your h(key). However,
the key must still be obtainable behind that since that is what the messages
will ultimately be encrypted and routed to. It's not much of a stretch beyond
that to ensure userland mail tools can handle say 8k long addresses. I'm not
against such a [vanity/shorthash] layer.
=====
natanael...
Bote mail and I2P messenger are two pieces of serverless software that
ALREADY is public key addressed within I2P. Have you tried them? You
need to add the public keys of the recipients to be able to send a
message to start with, although the DHT based search system Seedless
allow you to publish Bote mail addresses to the network.

(IMAP support for Bote mail is planned but not yet implemented, right
now it has a local web interface.)

Maybe Namecoin could work together with them to enable you to register
your key addresses to your nickname in a secure manner, but then you
still have to have a globally unique nickname and tell people the
exact spelling.
=====

ralf...
If you are so sure, can you tell us how the next generation secure email
solution will solve the "trust problem", please.

grarpamp...
Though unclear, that sounds like the old trust of a CA/PKI system problem.

How does the p2p daemon
find the correct crypto key, so that every user can rely on its invisible
performance?

In general I suggest that people wish to use messaging with each other
once they already know them (or have some other trusted web to them).
As in, Hey John, nice to meet ya today, what's your key (address), I'll
message you later. Or Hey Jane, what's John's address. Same for
employers, businesses, etc. Such peer groups bootstrap and grow
very fast. Thus the perceived need for a cold lookup of Ralf, isn't much of
a real one.
Once you know the address (node crypto key), you put it 'To: <key>',
mua hands to spool, p2p daemon reads spool, looks up key in DHT and
sends msg off across the transport to the far key (node) when it is
reachable. Hopefully the transport looks like I2P/Tor in being a secure
random hop layer. In fact, those could probably be used today, they
have the keys as nodes and user facing ports for inbound/outbound
daemons. They just need scaling work to n-billion nodes (users,
aka: the hard part). People are already plugging postfix, bittorrent,
etc into these networks.

Tor is not currently addressible at the user level by the full key,
it 'shortens' the key into a 16char onion address. As you may be
hinting at... yes, that is bad... collisions, and needing secondary lookup
layers into the full key. Tor may be moving to full key addressibility
soon, see tor-dev for that.

I2P (and Phantom, and probably GnuNet) are addressible with full keys.
So you can send to '***@key' with them if you want, and keep the
John/Jane/Ralf human style lookups in your MUA addressbook (once
you know them) without needing a secondary lookup layer into the full key.

No, I am not sure. But when looking at some of the p2p transport
layers that have come along so far, it seems like a fairly strong
possibility for a new backend transport model while retaining user
level mail tools... mutt, maildrop, mailman, Thunderbird, etc. Most
of what you'd need there is support for very long addresses and
split horizon handoff to local daemon/spool based on recognizing
what the destination net is... .onion, .i2p, etc.
I'd like to read what Pond and I2P-Bote are doing with some parts of
this as well.

I don't believe you need a trusted CA/PKI service to successfully
bootstrap users and their addresses/keys into a new global messaging
system. If I want to know what some unknown like Bruce's key is, I'll
look it up on his website, social net, list posts, etc. If that's what you
mean.
=====
bill...
I feel like I walking in halfway into a conversation, I'm guessing this
started on the cryptography list that I'm not on.

Your DHT comment caught my attention though. What in particular about
DHTs don't seem scalable or reliable?

Seems like DHTs are regularly in the 5-10M range and I don't see any
reason that DHTs couldn't be 10 times that.

Any reasonable churn rate and reliability could be handled with
replication. The bit-torrent DHT for instance claims that 45% of users
that bootstrap from a central node are reachable 15 minutes later. So
typical setups involve 8 nodes per bin, and 20 bins. So every 15
minutes you ping 160 hosts, only reach 45%, and do some work to
repopulate the missing slots.

Given the simplicity of the bit-torrent DHT I think there's plenty of
room for improvement. Larger routing tables are obvious (at the cost of
more network bandwidth to track peers).

The most promising idea for DHT improvements I've seen is to divide
peers into 3 latency groups. High, medium, and low. Much like L1
cache, L2 cache, and main memory. That way common queries are very
fast, yet all queries still to find keys globally.
=====
grarpamp...
Bittorrent is already in the 100m node range. That's not enough. This
needs to replace every possible messaging user on the planet over
the duration of their actiive lifetime. That's at least a couple billion nodes.
Don't forget, you can always use disk to cache things.
=====

james...
Need a system for handing one's keys around that protects end users from
the horrifying sight of actual keys or actual strong hashes of keys.

john...
But at the same time the system has to not say, "I can't deliver your
message to that person because an invisible gnotzaframmit that I won't
describe to you seems to be unavailable to me in the flabogrommit."

grarpamp...
Address books as usual. Name layer if need be. We are humans, we
learn new lexicons, we write manuals, that part is nothing to be afraid of.
Being afraid only holds you back.
=====

grarpamp...
I don't believe you need a trusted CA/PKI service to successfully
bootstrap users and their addresses/keys into a new global messaging
system. If I want to know what some unknown like Bruce's key is, I'll
look it up on his website, social net, list posts, etc. If that's what you
mean.
guido...
http://eccentric-authentication.org/Brucon-Eccentric.pdf

ralf...
This is an interesting idea, because it provides certificates on
demand for ordinary users, if they decide to sign up to a certain
site. The
certs are then being used for other purposes, so the site does act as a
bootstap for using crypto. The one thing that this proposal relies on is
the availability of a common piece of software (user agent) that stores
the private key for the user. It's this part of the picture where things
get tricky.

grarpamp...
There can be no non-distributed/redundant elements in this p2p system,
aka: no 'sites', certainly none with a realworld IP on them, and none where
very high percentages of them vanishing will disrupt the system for others.
This must replace email, therefore system disruption is intolerable.
=====

[Natanael]

Somebody in there mentioned allowing IPv6 addressing on top of I2P/Tor.
That would be Garlicat/Onioncat. It creates a local virtual IPv6 network
interface for your software to use, so that you can map key based addresses
to routable local addresses.

https://www.onioncat.org/about-onioncat/

- Sent from my phone

Post by grarpamp
This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today. There was
a former similarly named thread on this that diverged... from the
concept and challenge of P2P/DHT handling the transport and
lookups... back to more traditional models. This thread does not
care about those antique models, please do not take it there.
In short, we're attempting to examine and develop some form
of new transport that looks somewhat like a mix between secure
decentralized dht-like scaling and finally a user facing daemon that
moves messages into and out of local spools for use by normal
user/system tools.
Pasting in a very rough and unflowing thread summary to date
for interested people to pick up and discuss, draft, etc.
=====
grarpamp...

[pgp/smime email encryption, etc]
What is the gap we have to close to turn this on by default?

How many times has this been rehashed the last six months?
You can't fix email as we know it today using todays bolt-ons,
protocols and corporate stakeholders/services trying to profit from it.
The only way to have any real global seamless success is to go
ground up with a completely new model. IMO, that will be some
form of p2p message system where every address is a crypto key,
masked for grandma by her contact list, decrypted out your p2p
daemon and piped into your local mail processing (MUA/filter/lists)
and filesystem (encryption). At least that way your local mail tools
will still work (no one will give those up anyway).
The problem is the antique centralized backend, it needs bypassed.
You've got neat stuff like Tor, bittorrent, bitcoin, etc already... so
boost email into the 2020's the same way. Then let the old world
email services try to keep up, and slowly die like everything else.
=====
grarpamp...

But of course you're right about actual current usage, encrypted email
is an
epic fail on that measure regardless of format/protocol.

Yes, but it's about time we do something about that. Do we *exactly know
why* it is such a failure?

It's an interesting question, and one worth studying for pedagogical
motives. From my experiences from both sides, it is clear that both

sides

failed. But for different reasons.
Hence, I've concluded that email is unsecurable.

Obviously. It will never be able to escape the non-body
header content and third party routing, storage and analysis with
any form of patching over today's mail. And it's completely
ridiculous that people continue to invest [aka: waste] effort in
'securing' it. The best you'll ever get clients down to is exposing
a single 'To:' header within an antique transport model that
forces you to authenticate to it in order to despam, bill, censor
and control you.
That system is cooked, done and properly fucked. Abandon it.
What the world needs now is a real peer to peer messaging
system that scales. Take Tor for a partial example... so long
as all the sender/recipient nodes [onions] are up, any message
you send will get through, encrypted, in real time. If a recipient
is not up, you queue it locally till they are... no third party ever
needed, and you get lossless delivery and confirmation for free.
Unmemorable node address?, quit crying and make use of your
local address book. Doesn't have plugins for current clients?,
so what, write some and use it if you're dumb enough to mix
the old and new mail.
The only real problem that still needs solved is scalability...
what p2p node lookup systems are out there that will handle
a messaging world's population worth of nodes [billions] and
their keys and tertiary data? If you can do that, you should
be able to get some anon transport over the p2p for free.
Anyway, p2p messaging and anonymous transports have
all been dreamed up by others before. But now is the
time to actually abandon traditional email and just do it.
If you build it, they will come.
=====
fabio...
I'm strongly against most the ideas to abbandon current email systems,
because the results will be to create wallet garden.
We need something interoperable with existing systems or the system will
just be used by a bunch of paranoid people or fostered by the marketing
of few cryptography company acquiring customers, not user.
=====
grarpamp...
It would be interoperable with current end user interfaces/tools, but not
As with everything else, today's seeds grow into tomorrows garden, sometimes
you just have to thorougly plow under last year's chaff first, that's by design.
=====
viktor...
E-mail is basically business correspondence.
- E-mail is stored.
- E-mail is sent to many people outside your personal social network.
- Business recipients of email are often subject to corporate and/or
regulatory policy constraints that are in conflict with end-to-end
encryption.
The above list of features can be greatly expanded, and the
consequences elaborated, but I doubt may on this list truly need
to be re-educated about email.
So I will confidently predict that end-to-end secure email will
remain a niche service used by a tiny minority.
...
Even businesses that one might expect to implement at least encryption
to the "gateway", are in many cases choosing to out-source their
gateway to 3rd-party providers (anti-spam and anti-virus offerings
only work with un-encrypted email, and in many cases the provider
also operates the entire mail store).
....
[and others also said: tls, dane, skype, smime, ca's, smtp, etc]
=====
Jerry...
Medical, Financial
=====
grarpamp...
Nothing here changes, only the backend transport between nodes.
Once your node decrypts the message to your local system pipes,
you can do all this and more with it. Including running a 'business' node
and doing whatever you want with the plaintext after your node daemon
passes it to you. This is not about those ancient protocols. It's also
about 'messaging' not strictly 'email'... those lines are already well
blurred, no need to distinguish between them anymore. A 'light'
messaging client could simply ignore the non transport email headers,
Please do not continue to talk about antique tradional centralized
systems in this thread, except of course to bash and route around them.
The speed of a real P2P/DHT replacement at scale is a research challenge.
=====
coderman...
this would make an interesting bet! i too believe this to be
impossible given the constraints.
=====
grarpamp...
I'm not so sure about this, look at all the global resources being poured
into traditional email, and attempts to 'fix' it. Now redirect fractional 1%
of those resources and put them into a P2P replacement. That's ftw.
=====
natanael...
Say hello to Bote mail on I2P.
I2P provides encrypted anonymizing networking, Bote mail provides DHT
based serverless encrypted mailing with public crypto keys as
addresses (ECDSA or NTRU).
http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add
.us to visit it via an inproxy).
There is also I2P Messenger that is encrypted P2P IM within I2P also
using public keys as addresses.
=====
cane...
You may have a look of "I2P Bote" it is severless, encrypted mail
system, address is the public key, P2P based... nice tool.
https://en.wikipedia.org/wiki/I2P#E-mail
=====
grarpamp...

You may have a look of "I2P Bote" it is severless, encrypted mail
system, address is the public key, P2P based... nice tool.

As in another post of mine, I'll be looking at that again.
My first take was that it stores the messages in the DHT,
which didn't seem scalable or reliable at all. I may be
wrong as I read more later.

Afterwards you can add the "I2P Bote plugin", the serverless mail
system. SMTP- and POP3 support was on the ToDo list some times ago, I

I think that's working now. And is the general idea, create a strong
overlay network with a frontend MUA's can speak to.
As an aside: If you can make that overlay net present an IPv6 tunnel
interface on the local host, that lets you use any IPv6 enabled
app over it. I'm doubting the world needs a dozen application
specific overlay networks. More like just a few classes of network.
- message based store and forward
- low latency IPv6 transport
- data storage and retrieval
=====
natanael...
Bote mail doesn't have to be used for it's anonymous properties, for
me that is just a bonus. For many people it is more than enough to be
able to know that it is impossible for anybody else than the intended
recipient to read the message thanks to public key addressing.
Guaranteed end-to-end security if you can verify the address.
I don't think anything that doesn't fundamentally rely on public key
addressing is the (long term) future. There will inevitably issues
otherwise, including more issues of the type we have with CA:s today.
For those who want to make it more user friendly, nothing stops you
from adding a transparent "address translation layer" where servers
are involved. When you want to send a message to a person with a human
readable address at a server, then the server could then reply with
the public key based address to the mail client, and the user would
have the option to see what that address is. It could even be logged
by the client, with TOFU/POP style trust system that reduces the
amount of trust you have to place in the server. No need to trust
anybody with plaintext.
=====
grarpamp...
I suggest such interfacing with the current legacy system will only prolong
it's long past due extinction. Build a better system and let them come to you,
not the other way around. And bolting in exits will only make it harder to
do correctly and optimally what you need to do as a P2P system. Please,
just forget about interfacing with the legacy transport system. If you really
need that you can run your own p2p daemon node that acts as your
automated gateway between the two. This is mostly about design of
the p2p side, not that.
=====
james...
It is my understanding of the proposed replacement for email. Magic
email addresses that in fact correspond to an identifier of a public
key, for example the hash of a rule that identifies the public key,
and which result in your message not in fact being passed along by
email protocols.
=====
grarpamp...
yes, you'll need to create another layer on top to hold your h(key). However,
the key must still be obtainable behind that since that is what the messages
will ultimately be encrypted and routed to. It's not much of a stretch beyond
that to ensure userland mail tools can handle say 8k long addresses. I'm not
against such a [vanity/shorthash] layer.
=====
natanael...
Bote mail and I2P messenger are two pieces of serverless software that
ALREADY is public key addressed within I2P. Have you tried them? You
need to add the public keys of the recipients to be able to send a
message to start with, although the DHT based search system Seedless
allow you to publish Bote mail addresses to the network.
(IMAP support for Bote mail is planned but not yet implemented, right
now it has a local web interface.)
Maybe Namecoin could work together with them to enable you to register
your key addresses to your nickname in a secure manner, but then you
still have to have a globally unique nickname and tell people the
exact spelling.
=====

ralf...
If you are so sure, can you tell us how the next generation secure email
solution will solve the "trust problem", please.

grarpamp...
Though unclear, that sounds like the old trust of a CA/PKI system problem.

How does the p2p daemon
find the correct crypto key, so that every user can rely on its invisible
performance?

In general I suggest that people wish to use messaging with each other
once they already know them (or have some other trusted web to them).
As in, Hey John, nice to meet ya today, what's your key (address), I'll
message you later. Or Hey Jane, what's John's address. Same for
employers, businesses, etc. Such peer groups bootstrap and grow
very fast. Thus the perceived need for a cold lookup of Ralf, isn't much of
a real one.
Once you know the address (node crypto key), you put it 'To: <key>',
mua hands to spool, p2p daemon reads spool, looks up key in DHT and
sends msg off across the transport to the far key (node) when it is
reachable. Hopefully the transport looks like I2P/Tor in being a secure
random hop layer. In fact, those could probably be used today, they
have the keys as nodes and user facing ports for inbound/outbound
daemons. They just need scaling work to n-billion nodes (users,
aka: the hard part). People are already plugging postfix, bittorrent,
etc into these networks.
Tor is not currently addressible at the user level by the full key,
it 'shortens' the key into a 16char onion address. As you may be
hinting at... yes, that is bad... collisions, and needing secondary lookup
layers into the full key. Tor may be moving to full key addressibility
soon, see tor-dev for that.
I2P (and Phantom, and probably GnuNet) are addressible with full keys.
John/Jane/Ralf human style lookups in your MUA addressbook (once
you know them) without needing a secondary lookup layer into the full key.
No, I am not sure. But when looking at some of the p2p transport
layers that have come along so far, it seems like a fairly strong
possibility for a new backend transport model while retaining user
level mail tools... mutt, maildrop, mailman, Thunderbird, etc. Most
of what you'd need there is support for very long addresses and
split horizon handoff to local daemon/spool based on recognizing
what the destination net is... .onion, .i2p, etc.
I'd like to read what Pond and I2P-Bote are doing with some parts of
this as well.
I don't believe you need a trusted CA/PKI service to successfully
bootstrap users and their addresses/keys into a new global messaging
system. If I want to know what some unknown like Bruce's key is, I'll
look it up on his website, social net, list posts, etc. If that's what you
mean.
=====
bill...
I feel like I walking in halfway into a conversation, I'm guessing this
started on the cryptography list that I'm not on.
Your DHT comment caught my attention though. What in particular about
DHTs don't seem scalable or reliable?
Seems like DHTs are regularly in the 5-10M range and I don't see any
reason that DHTs couldn't be 10 times that.
Any reasonable churn rate and reliability could be handled with
replication. The bit-torrent DHT for instance claims that 45% of users
that bootstrap from a central node are reachable 15 minutes later. So
typical setups involve 8 nodes per bin, and 20 bins. So every 15
minutes you ping 160 hosts, only reach 45%, and do some work to
repopulate the missing slots.
Given the simplicity of the bit-torrent DHT I think there's plenty of
room for improvement. Larger routing tables are obvious (at the cost of
more network bandwidth to track peers).
The most promising idea for DHT improvements I've seen is to divide
peers into 3 latency groups. High, medium, and low. Much like L1
cache, L2 cache, and main memory. That way common queries are very
fast, yet all queries still to find keys globally.
=====
grarpamp...
Bittorrent is already in the 100m node range. That's not enough. This
needs to replace every possible messaging user on the planet over
the duration of their actiive lifetime. That's at least a couple billion nodes.
Don't forget, you can always use disk to cache things.
=====

james...
Need a system for handing one's keys around that protects end users from
the horrifying sight of actual keys or actual strong hashes of keys.

john...
But at the same time the system has to not say, "I can't deliver your
message to that person because an invisible gnotzaframmit that I won't
describe to you seems to be unavailable to me in the flabogrommit."
grarpamp...
Address books as usual. Name layer if need be. We are humans, we
learn new lexicons, we write manuals, that part is nothing to be afraid of.
Being afraid only holds you back.
=====

grarpamp...
I don't believe you need a trusted CA/PKI service to successfully
bootstrap users and their addresses/keys into a new global messaging
system. If I want to know what some unknown like Bruce's key is, I'll
look it up on his website, social net, list posts, etc. If that's what

you

mean.
guido...
http://eccentric-authentication.org/Brucon-Eccentric.pdf

ralf...
This is an interesting idea, because it provides certificates on
demand for ordinary users, if they decide to sign up to a certain
site. The
certs are then being used for other purposes, so the site does act as a
bootstap for using crypto. The one thing that this proposal relies on is
the availability of a common piece of software (user agent) that stores
the private key for the user. It's this part of the picture where things
get tricky.
grarpamp...
There can be no non-distributed/redundant elements in this p2p system,
aka: no 'sites', certainly none with a realworld IP on them, and none where
very high percentages of them vanishing will disrupt the system for others.
This must replace email, therefore system disruption is intolerable.
=====
_______________________________________________
cryptography mailing list
http://lists.randombit.net/mailman/listinfo/cryptography

[grarpamp]

Somebody in there mentioned allowing IPv6 addressing on top of I2P/Tor. That
would be Garlicat/Onioncat. It creates a local virtual IPv6 network
interface for your software to use, so that you can map key based addresses
to routable local addresses.
https://www.onioncat.org/about-onioncat/

It is worth noting that Phantom does this natively without needing an overlay on
top of another net. It may also use disk to cache some network information, at
least their whitepaper says they are 'for' making that choice. Perhaps it can be
scaled? https://code.google.com/p/phantom

[grarpamp]

More summary pasting...

/ Someone...
/ There are people I know who do not mind the extra steps for pgp. I
/ certainly want to get the roll out to use and test and enjoy. Sign me
/ up.

grarpamp...
Encryption is only part of it. There's transport, elimination of
central storage, anonymity, p2p, etc. Many things people want
simply can't be done with modifications to the current system.
With p2p model and every node as a key/address, you don't
need 'pgp' because the node is the key and does lookups and
encrypt2dest / decrypt2you for you. But you can still use pgp with
the usual tools around message bodies if desired for additional
encrypt/auth or if you're disk isn't encrypted. P2P daemon
takes over and all the old transport headers go away.
Spam/AV becomes another local daemon. Mailing lists are
a repeater node someone runs, or the usual local mailman stuff.
It's a transport replacement, so business can use it ***@node.
All the MTA's [connected directly to the internet] die off in time.

[grarpamp]

A problem which could rise is the 'incentive' for peers to continuosly
providing bandwidth and disk space to store messages. I'm a simple dude,
with a mailflow of ~5 email per day. Why I should work for you, with
your ~10000 mail per day for all your mailing list?

I think this is one of many design choices to be made.

Extra bandwidth is hard to avoid, unless the topology is
point(sender)-to-point(recipient). Yet with that, there is no effort made
to hide who is physically talking to who. We want to try to defeat this
type of analysis, so we can't be simply point-to-point.
ie: bittorrent and today's email are point-to-point, no multihop.

Next is storage (mix) vs. latency (tunnels). This seems less clear to
me when up against analysis. Filling circuits (tunnels) with chaff
seems interesting. And with deliverey directly to your recipient over
some tunnel circuit, you don't have to build in complex message redundancy
protocols (more storage float outstanding) to ensure your message 100%
gets there when 90% of the nodes go offline taking your stored message
with them. You also get direct realtime delivery confirmation too.

Somewhere on this list (or p2p-hackers?) there was a post of mine,
regardings an economic incentive between peers, which could be a
solution, but as always technical problems arose, like pricing the
services and a fair exchange between peers.

The question arises, how does one provide free anonymous transport
to those anons who simply can't pay because they are anon? How
do you 'get users' when the mentality is 'for free'? Bittorrent/Tor are
free and seem to work ok. Though it's also probably not unreasonable
to suggest (and harder to enforce) that you get 1:1 what resources you
donate to it. ie: I need to push 1GiB this month, so I need to provision at
minimum 1+Nx1GiB to do that... 1 for me, Nx1 for the net due to my use
(where N is some impact ratio inherent in the design of the net, such
as number hops.)

[t2]

wmn over wpan?
p2pfoundation.net/Arduino
...leverage iBeacon?

(random thoughts)

Post by grarpamp

A problem which could rise is the 'incentive' for peers to continuosly
providing bandwidth and disk space to store messages. I'm a simple dude,
with a mailflow of ~5 email per day. Why I should work for you, with
your ~10000 mail per day for all your mailing list?

I think this is one of many design choices to be made.
Extra bandwidth is hard to avoid, unless the topology is
point(sender)-to-point(recipient). Yet with that, there is no effort made
to hide who is physically talking to who. We want to try to defeat this
type of analysis, so we can't be simply point-to-point.
ie: bittorrent and today's email are point-to-point, no multihop.
Next is storage (mix) vs. latency (tunnels). This seems less clear to
me when up against analysis. Filling circuits (tunnels) with chaff
seems interesting. And with deliverey directly to your recipient over
some tunnel circuit, you don't have to build in complex message redundancy
protocols (more storage float outstanding) to ensure your message 100%
gets there when 90% of the nodes go offline taking your stored message
with them. You also get direct realtime delivery confirmation too.

Somewhere on this list (or p2p-hackers?) there was a post of mine,
regardings an economic incentive between peers, which could be a
solution, but as always technical problems arose, like pricing the
services and a fair exchange between peers.

The question arises, how does one provide free anonymous transport
to those anons who simply can't pay because they are anon? How
do you 'get users' when the mentality is 'for free'? Bittorrent/Tor are
free and seem to work ok. Though it's also probably not unreasonable
to suggest (and harder to enforce) that you get 1:1 what resources you
donate to it. ie: I need to push 1GiB this month, so I need to provision at
minimum 1+Nx1GiB to do that... 1 for me, Nx1 for the net due to my use
(where N is some impact ratio inherent in the design of the net, such
as number hops.)
_______________________________________________
p2p-hackers mailing list
http://lists.zooko.com/mailman/listinfo/p2p-hackers

[grarpamp]

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?
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

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.

[Randolph]

Anyone looked at BitMail p2p ?
http://sourceforge.net/projects/bitmail/?source=directory

Post by grarpamp
This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today.
Pasting in a very rough and unflowing thread summary to date
for interested people to pick up and discuss, draft, etc.

[grarpamp]

Post by Randolph
Anyone looked at BitMail p2p ?
http://sourceforge.net/projects/bitmail/?source=directory

re: bitmail, goldbug, etc.

With all due respect, I doubt few here have or will anytime soon.
You spam out links to binaries no one's heard of, your source probably
isn't deterministic to your binaries, bsd/linux support?, your development
model doesn't appear open, code is hosted on a site few care about anymore,
you've no papers, presentations, mailing list or community involvement,
you've advertised the good name of other projects as being affiliated with
your work without their permission. And you've failed to address any of
this publicly despite people kindly prompting you to do so. In these
communities, that's a big red flag.
As always, full benefit of the doubt is given. If you need hosting for code,
lists, website... some code review, testing, etc... just ask an appropriate
list. We need more cool ideas and software... but you really need to step
up to the plate in these areas if you want people to take you seriously.

[adrelanos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by grarpamp

Post by Randolph
Anyone looked at BitMail p2p ?
http://sourceforge.net/projects/bitmail/?source=directory

re: bitmail, goldbug, etc.
With all due respect, I doubt few here have or will anytime soon.
You spam out links to binaries no one's heard of, your source
probably isn't deterministic to your binaries, bsd/linux support?,
your development model doesn't appear open, code is hosted on a
site few care about anymore, you've no papers, presentations,
mailing list or community involvement, you've advertised the good
name of other projects as being affiliated with your work without
their permission. And you've failed to address any of this publicly
despite people kindly prompting you to do so. In these communities,
that's a big red flag. As always, full benefit of the doubt is
given. If you need hosting for code, lists, website... some code
review, testing, etc... just ask an appropriate list. We need more
cool ideas and software... but you really need to step up to the
plate in these areas if you want people to take you seriously.

I agree with what grarpamp said.

Cheers,
adrelanos

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJSu0JyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5
QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v5cQP/iiyeSHdLC8UzBiltrM7EXNE
6L6lAke5Wwf/7RlRJT/1g1NjF7XXqhIlkrQ4V0s7CNKSNJ17bP37zdV9diid8MuO
wTtdmZkBIzI/JlBv7bj0mMwGdTBeuEzzDMsRQAoMsQ/VvFL1ngEyIMo9iTGkVdsw
nwCKGJYUBj26dXp7a2kTmWkDhk5IaYFmpvDR1Vz3V3LTIqSJ1eZw6cwAEqiTHefW
CzMVALzEzOcWGxXWz2RotUalu5Z1u1hA1EnBuLCoIYqX2HwByDJV8bTo2JzLt09+
qJHNmCSLHZw3s6n/OdHM/umfvbpAvSOkMfY0Km2xoOMNUI0M2EnPHyzEAWWdtB0h
SIjm1RTVJacto4Pdygli8+YkWY0SlvPCRnPnb4IErBuEjGgugrqZKCpYQN+xtnHc
RimFW3/5ldAILLOX3yUvAjWgi2/JqpsIupPxTGvUr9yFUbCDvWKpsgNzNF2DDrX4
rsL2LCLapqLcYaO1qZ2LjXtzoRDt4YUPtpHaek17kTdI/qj/TjdzkF1ZB456wXIj
n08rySDKh72mtK7NzdjuI2Mny4MiVdF0nALXZXzdFXYUiFtfh/lY/mKooMpEn5VW
m4YXyH+9OzcQ06z9q2jzQHUvavvng2b0RcW2NdU0M2Ch+Dj7lNwBZvvMWORaB+Yk
m8+K/Ndz6kXLL7ZveW9J
=PNUk
-----END PGP SIGNATURE-----

[Randolph]

Hi Garpamp and Adrelanos,
I agree with you too!.. as I am not affiliated with BitMail, .. all that is
needed, you request. It seems to be a model like waste.sf.net out as a
reference. The difference maybe is, I tried to evalute it, and we could
share experience. Anyway.., it is definately a p2p email model. Regards

Post by Randolph
Anyone looked at BitMail p2p ?
http://sourceforge.net/projects/bitmail/?source=directory

If you need hosting for code,

Post by Randolph
lists, website... some code review, testing, etc... just ask. We need more
cool ideas and software... need to step
up to the plate in these areas if you want people to take you seriously.

[grarpamp]

On Wed, Dec 25, 2013 at 8:21 AM, Jeremie Miller

This thread seems pretty immense and in various places, what's the best way to contribute to it?
I'm pretty keen on the topic, been working on /real/ p2p infrastructure for 5+ years now :)

I'm not sure that it has a proper home. I do not suggest metzdowd,
which is where I think you picked it up. cypherpunks has the most
thread content to date. Though p2p-hackers is perhaps best for now
unless anyone else has a better idea? ie: another p2p centric list
with a good bit of anonymity and crypto representation.
p2p-hackers is having delivery issues at the moment so maybe
continue to cc cypherpunks for another week till that is sorted out.

[Matthew Kaufman]

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.

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.

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.

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.

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.

Matthew Kaufman

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.

[grarpamp]

Post by Matthew Kaufman
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.

Post by Matthew Kaufman
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).

Post by Matthew Kaufman
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.

Post by Matthew Kaufman
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.

Post by Matthew Kaufman
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 :)

Post by Matthew Kaufman
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.

[ianG]

Post by grarpamp

Post by Matthew Kaufman
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.

Post by grarpamp

Post by Matthew Kaufman
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.

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!)

Post by grarpamp

Post by Matthew Kaufman
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.

Post by grarpamp
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.

Post by grarpamp

Post by Matthew Kaufman
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.



iang

[grarpamp]

Post by grarpamp

Post by Matthew Kaufman
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.

Post by grarpamp

Post by Matthew Kaufman
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>.

Post by grarpamp

Post by Matthew Kaufman
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.

Post by grarpamp
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.

Post by grarpamp

Post by Matthew Kaufman
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.

[ianG]

Post by grarpamp

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?

They want their lives made easier.

Post by grarpamp
Possibly selecting a trust chain
other than that introduced to them by their friend?

Yes, and that is the big question. They trust their friends [0].

As well as friends, people trust their brands. But brand is almost a
synonym for 'things people trust' so maybe that's a tricky observation.
E.g., USA is a brand, many people trust it. But when they don't, what
happens? And how to deal with it? That's when the arguments start and
we end up down the rabbit hole.

Beyond that, not much is trusted. However they can also not trust to a
very casual degree, hence the ability of viruses to spread via funny
email forwards.



[0] This is why Facebook worked. If you ever want to understand the
secret of Facebook, it's in the movie. It's curious, nobody could tell
me what the secret was, but it's laid out in clear terms, the script
writer is a true genius. I must blog one day about it, I did a
movie-lesson-case-study for startups and wrote up all the notes; that
movie is the one movie I insist all of our people see and understand,
because it documents our space to perfection, but it also lays out why
our business works. And sets the scene for the next evolution.

Post by grarpamp
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.

The adoption issue is because people only recommend things that make
their lives easier. Privacy doesn't make our lives easier, it makes it
safer, and we don't see the protection we got because when privacy works
we don't get any feedback.

So you have to seek the 'easier' lifestyle choice. The place to watch
here is the startup space. They have all the ideas. What they lack is
the implementation capabilities that are found here, e.g.. Put them
together and watch ...

Which is why I'm in yastartup...


iang

[ianG]

Post by grarpamp
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/ .

Nice link!

Post by grarpamp
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.

Post by ianG
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>.

Tough call, but a good thought. If phones had a p2p viral vpn .. where
would that take us?

...

Post by grarpamp

Post by ianG

Post by grarpamp
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?

Android. 50% market share in 2 years.

Post by grarpamp
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.

Well, I think the world is opening up. Although iPhone dominates the
'west' it doesn't scratch anywhere else because it's priced out. Here,
it's all dumb, feature and android.

I'd also say that China is not 'west' now, or ever. Only maybe 100m of
the 1b are at that point, and even then they'll only be muddling class
but never western. Now, that muddling level is enough to get Apple's
attention apparently but the economy driver is still on the base.

Also, I would say this: be very cautious of stuff you read in the
western press. It's highly filtered, highly ignorant. In order to
understand what is happening in a particular region, you have to go there.

For example: in our startup space here where we do lots of android work
(because we're in the payments capital of the world ;-) ) we get lots
and lots of western investors, NGOs, mba-tourists, etc. (The
mba-tourists are hilarious, they come here to do the "NGO adventure" so
they can get into MBA school, it's an institution.)

Westerners come here and impose their western ideas on the locals and
find that the ideas don't take root. The locals don't have the
experience to tell them why, and they're too polite to tell them to sod
off. But the longer term more worldly experienced types -- those who've
lived in minimum 3 countries for many years -- can see it in a
heartbeat: western ideas only work in the west (c.f., Hernando de Soto)
. Everywhere else, there are totally different assumptions and totally
different working practices.

For further example. There's this famous company that does tech, name
forgootten for now but you can search on it easily enough. They came
here and they discovered that the public transport system is chaos, and
based on cash, and ripe for cleanup. Smell business opportunity!

So they invent a payment system, couple with a bank, and start selling
everyone on these payment tokens and the buses on these payment
accepting devices. Guess what ... it doesn't work! It's not that the
tech doesn't work -- that's fine. It's that *the people* won't let it
work. There is resistance, sabotage, theft, ... the whole kit & kaboodle.

It all comes down to westerners coming here and not leaving their
western ideas at home. Big mistake. They saw the chaos and thought
they could improve; but what they didn't realise is that the public
transport system is perfectly aligned with the local market *and* is one
of the best in the world. It's just that "best" requires completely
leaving behind your western notions, and discovering how the local
market works.

Post by grarpamp
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.

In the old days, what happened in the west happened later elsewhere.

However, the west rather shot itself in the foot in the 2000s with their
great financial folly. So growth has stalled, and the West has entered
a sort of Japanese lost decades phase: In 1990, when the bubble burst
on the Japanese economic miracle, the authorities refused to clean out
the bad banks, so the economy flatlined ... indeed since then.

Now, what happened after 2007 in the west? They refused to clean out
the banking sector, and for the same reasons that the Japanese refused
to do it.

So, the western economy is still bloated with bad banks ... growth now
flatlines, and we have to wait decades for them to fade away.

But not a lot of this effects the developing/emerging world. So their
growth is unabated. So we are seeing the beginnings of a flip. It's
not so much that you could call the end of western civilisation as you
know it, but it is enough to challenge the old world order:
western->rest is now upset.

Post by grarpamp
See what you can build for intel/amd CPU's.
See what you can fit in ARM, snapdragon, android, etc.

For boxen, there are some mighty fine, mighty cheap full scale servers
coming out. Low power. Full function. Like Mac Minis (fantastic
servers!) but a tenth of the price! Yehaa!


So to answer your implied question: we can no longer assume that the
western ideas drive and others follow.



iang

[grarpamp]

Post by ianG

Post by grarpamp
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?

Android. 50% market share in 2 years.

Makes sense, that these markets move to adopt such relatively
open and less costly platforms. That can only help to get rid of the
closed/pricey ones in the west, even if only from driving hw makers
to produce such devices in their lineup.

Post by ianG
Also, I would say this: be very cautious of stuff you read in the western
press. It's highly filtered, highly ignorant. In order to understand what
is happening in a particular region, you have to go there.

Of course.

Post by ianG
totally different assumptions and totally different working practices.

Agreed. Yet I think people's need to communicate / share securely is the same
in all places, even if the motivations as applied are different. So whatever is
written for each class of hardware should have relatively equal takeup wherever
deployed. It would seem a waste of effort to do different verticals
within each class.

Post by ianG
In the old days, what happened in the west happened later elsewhere.
However, the west rather shot itself in the foot in the 2000s with their
great financial folly. So growth has stalled, and the West has entered a
sort of Japanese lost decades phase: In 1990, when the bubble burst on the
Japanese economic miracle, the authorities refused to clean out the bad
banks, so the economy flatlined ... indeed since then.

Yes, lot of footshooting in the west these days... arrogant and foolish.

Post by ianG
But not a lot of this effects the developing/emerging world. So their
growth is unabated. So we are seeing the beginnings of a flip. It's not so
much that you could call the end of western civilisation as you know it, but
it is enough to challenge the old world order: western->rest is now upset.

Even disregarting footshooting, as billion person regions come up
to speed, simple demand of population count will drive this change.
If they demand open hardware and software, that's a win.

[James A. Donald]

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.

Anything that is as good as skype is going to allow contact tracing,
that this person talks to that person.

But it does not have to allow mass interception (the original skype did
not allow mass interception), and it does not have to allow undetectable
interception, which the original skype did allow.

[David Barrett]

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.

Anything that is as good as skype is going to allow contact tracing, that
this person talks to that person.

I think the challenge with building a new phone system is that the existing
phone systems are already amazing. Skype filled a void for cheap long
distance. But now that that void is filled, and you can call anybody in
the world from your phone easily (unlimited nationwide plans are common,
and Skype covers the rest of the world), it'll be very difficult for any
new voice service to take root. But I could imagine it happening if:

1) It's backwards compatible with the current voice services (eg, you can
call anybody with it, and they can call you, regardless of whether you use
the service)

2) It offers tangible value to you even if the person you're calling isn't
using it

3) It offers tangible value to you even if the people calling you don't use
it

4) Those values increase as the number of people who use it increases

5) It automatically advertises itself

With these, then you can fully adopt this service -- without any downsides
-- and gain value from it regardless of whether anybody else does.
Furthermore, the value increases as the network size increases, so you
have an incentive to encourage others to use it. As for what that service
might be, that's a tall bar. But I could imagine protection against
dragnet-style government surveillance being compelling to a certain
demographic.

As for how that might work, that's tough. But imagine a new VoIP client
like the old Skype (eg, P2P with a distributed relay service for
NATs/firewalls), except truly encrypted. That would be pretty
straightforward to do: the audio/video codecs are pretty refined, and there
are great P2P libraries ready to go. The problem is: nobody is using is,
so you have no reason to use it either.

But what if everybody registered their "real" phone number with some DHT,
and then coupled this app with a collection of VoIP->POTS (Plain Old
Telephone System) gateways. So when I type in your phone number, first it
checks to see if I can use this secure system, and contacts you directly
via VoIP. But if you aren't in the system, it just calls you via a POTS
gateway.

Ok, so now we're backwards compatible, but it still doesn't really give me
any advantage if nobody else is using it. So what if rather than just
using one VoIP gateway, there were hundred, scattered across every area
code, and every network. Then when I call you, if I can't use my truly
secure VoIP connection, instead it just routes you through one of hundreds
of random gateways. Voila -- we both get protection from dragnet collection
of metadata (the NSA just sees that someone called you through one of these
many gateways, without knowing it's me) *even though* you don't use the
system.

Next, every time I call someone through this system and it falls back on
the POTS gateway, it plays a message saying something like "This line is
only partially secured; install XXXX app to get fully secured.
Connecting..." Now every user who uses this thing is automatically
advertising what it is to recipients. The more it's used, the more it
grows. Indeed, you could also couple it with SMS such that the first time
anybody calls a new number, it texts a link to that number explaining what
it is and linking to an app download.

Ok, so now we have a system that is backwards compatible, breaks the
"chicken and the egg" dilemma by offering value "out of the box" even to a
single user, and automatically promotes itself. But what about incoming
calls? How can I get the benefit of anonymity, but still give you a number
that you can reliably call to get me?

This one is a lot harder. One approach would be to let me generate new
phone numbers on the fly, such that I can give out different numbers to
everyone and they all go back to me. Again, anybody who calls these
numbers with POTS would get connected to me transparently via the VoIP
gateway (and might hear the marketing message / receive the SMS), and
anybody who calls inside the system gets me directly.

A problem with this is there are only so many phone numbers, and they cost
money. So a different approach might be to just maintain like a hundred
numbers, each of which has an "extension". So I give you a number like
(XXX) XXX-XXX x XXXX -- it's a bit of a pain to use extensions, but it
gives the same effect.

Then tie this with a Gmail plugin that auto-randomizes your phone number in
emails you send out (so you enter your own phone number, and it
provisions/randomizes before delivery), and maybe something that just
provisions a bunch of random numbers and prints out business cards to make
it easy to deliver.

Oh, and all this could work for SMS as well.

Anyway, something like this might allow individuals to "opt in" to a new
secure platform, without needing to "opt out" from the real world.

-david

[grarpamp]

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.

Anything that is as good as skype is going to allow contact tracing, that
this person talks to that person.

No... we are specifically talking about developing decentralized solutions
here, so that that centralized lookup authority context and risk goes away.

Yes... a low latency non-fixed-length non-chaffed network will
still have some characteristic risks... timing, etc. Yet likely nowhere
near the order of the above centralized issues.

But it does not have to allow mass interception (the original skype did not
allow mass interception), and it does not have to allow undetectable
interception, which the original skype did allow.

That is just designing good applied crypto in the former, which nullifies
the latter.

[grarpamp]

On Sat, Jan 11, 2014 at 5:57 AM, Cathal Garvey

Red herring-ish, but if you want to get your friends off Skype, don't
wait for the golden solution. Pick something good-enough and use that.
I've had moderate success migrating people to Jitsi. Similar ease of use

For any app really, ditto on success, especially if there's a windows port.
Various approaches usually work:
- "I need someone to test with"
- "This is what I use a) your thing doesn't work for me b) this is better or
c) tough"
- Etc
If you're willing to put in the time to show people, they will use it.

Back on topic, I'm not sure that it's possible to achieve low-latency
and endpoint obfuscation for something that requires streaming like
VoiP. Tor is already pushing the boundaries of low-latency mixing with
an asynchronous protocol that doesn't *require* perfect synchrony, such
as would be required of VoiP. So you might have to sacrifice obfuscation
of *who* you're talking to in order to achieve security across the wire,
or trust third parties such as VPNs or friend-to-friend connections
(Retroshare model) to provide lots of bandwidth.

There are people reporting that voice over Tor hidden services
is at least barely to actually useable, there is a lot of variance
though. Streaming low bitrate music is no problem. Latency is
about a second, setup can be a few+ seconds. Again, variance rules.

Regarding attacks, low latency and bulk data streams present
different surfaces. It would be interesting to see an anonymous
network that fills the entire banwidth you allocate to your node
with chaff during the time in which you do not otherwise need it.
The anonbib probably has something to say about that.

The subject is regarding large scale P2P secure messaging,(email)
not particularly the subthread of voice / general data transport..
I can see some advantage to using/modifying/merging ideas from
say Tor, cjdns and similar general transports for messaging.
Is there possibly a grand unification transport here?

[danimoth]

Post by grarpamp
Once you know the address (node crypto key), you put it 'To: <key>',
mua hands to spool, p2p daemon reads spool, looks up key in DHT and
sends msg off across the transport to the far key (node) when it is
reachable.

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 ***@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.

[danimoth]

Post by grarpamp
This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today. There was
a former similarly named thread on this that diverged... from the
concept and challenge of P2P/DHT handling the transport and
lookups... back to more traditional models. This thread does not
care about those antique models, please do not take it there.

A problem which could rise is the 'incentive' for peers to continuosly
providing bandwidth and disk space to store messages. I'm a simple dude,
with a mailflow of ~5 email per day. Why I should work for you, with
your ~10000 mail per day for all your mailing list?

Somewhere on this list (or p2p-hackers?) there was a post of mine,
regardings an economic incentive between peers, which could be a
solution, but as always technical problems arose, like pricing the
services and a fair exchange between peers.

[Bill Broadley]

Post by grarpamp
grarpamp...
Bittorrent is already in the 100m node range.

Numbers I've seen show 8-10M for users in the DHT at any one time. If
it's actually 100M all the better.

Post by grarpamp
That's not enough. This
needs to replace every possible messaging user on the planet over
the duration of their actiive lifetime. That's at least a couple billion nodes.
Don't forget, you can always use disk to cache things.

Considering the DHT already scales to 2^23 peers, what causes you to
think the next 2^7th is going to cause problems? Especially when router
table and traffic increases with the log(peers)?

Current bittorrent clients often have 20 bins in use, tracking about 160
peers per 15 minutes. That would only change toe 27 bins (216 hosts)
for 1 billion peers. Seems workable to me. Did you have some specific
concerns?

[grarpamp]

Post by Bill Broadley

Post by grarpamp
grarpamp...
Bittorrent is already in the 100m node range.

Numbers I've seen show 8-10M for users in the DHT at any one time. If
it's actually 100M all the better.

I think if you load Vuze with the mlDHT plugin you'll often see
150m users online.

Post by Bill Broadley

Post by grarpamp
That's not enough. This
needs to replace every possible messaging user on the planet over
the duration of their actiive lifetime. That's at least a couple billion nodes.
Don't forget, you can always use disk to cache things.

Considering the DHT already scales to 2^23 peers, what causes you to
think the next 2^7th is going to cause problems? Especially when router
table and traffic increases with the log(peers)?
Current bittorrent clients often have 20 bins in use, tracking about 160
peers per 15 minutes. That would only change toe 27 bins (216 hosts)
for 1 billion peers. Seems workable to me. Did you have some specific
concerns?

If a DHT can scale to say 10B nodes while performing lookup on an
unknown key in say a minute or less [1], that sounds like a great start.
Are there such designs in effect? The concern is that we don't appear to
have any decentralized p2p messaging network today that is anywhere near
that large. When you ask the current big ones (BT, Tor, I2P, cjdns, etc) they
don't seem to have a scale solution, be they filesharing, transport,
messaging, etc.

[1] Perhaps reasonable latency for delivery of mail across an anonymous
transport (aka: circuit setup time, uncached) may be a few minutes or so.

[Bill Broadley]

Post by grarpamp
I think if you load Vuze with the mlDHT plugin you'll often see
150m users online.

That's much more than I heard, but all the better. Making billions of
peers just a few factors of 2 away.

Post by grarpamp
If a DHT can scale to say 10B nodes while performing lookup on an
unknown key in say a minute or less [1], that sounds like a great start.

I don't see any reason for 10B peers to be a problem.

Post by grarpamp
Are there such designs in effect? The concern is that we don't appear to
have any decentralized p2p messaging network today that is anywhere near
that large. When you ask the current big ones (BT, Tor, I2P, cjdns, etc) they
don't seem to have a scale solution, be they filesharing, transport,
messaging, etc.

Very few software packages have a billion users, that doesn't mean a DHT
wouldn't scale if tomorrow 10B users launched bittorrent.

150M is approximately 2^27 or 24 bins of routing info. Once every 15
minutes you ping any hosts you haven't heard from recently. Worst case
for 150M peers in the DHT is 192 peers, or every 5 seconds or so. Keep
in mind a ping isn't a full DHT traversal, just a UDP packet.

Scaling to 10B is going to change that much, 5 more bins, 40 more host
to ping every 15 minutes.

Post by grarpamp
[1] Perhaps reasonable latency for delivery of mail across an anonymous
transport (aka: circuit setup time, uncached) may be a few minutes or so.

Sounds easy.

[Christian Huitema]

Post by Bill Broadley
Scaling to 10B is going to change that much, 5 more bins, 40 more host
to ping every 15 minutes.

I believe this is actually an issue. The number of pings per host scales as
O(log N), which means the amount of maintenance traffic scales as O(N log N)
-- more than linearly with the size of the network. Given the nature of the
DHT, the addresses to be pinged will be scattered all over the Internet.
That is, nodes in the US will ping nodes in China, Australia, Europe, etc.
So we end up with a substantial background noise over the inter-continental
connections, and the amount of noise will grow more than linearly with the
number of nodes in the network.

-- Christian Huitema

[grarpamp]

On Sun, Jan 12, 2014 at 3:29 PM, Christian Huitema

Post by Christian Huitema
So we end up with a substantial background noise over the inter-continental
connections,

Other than for latency issues in our protocols, there's enough
fiber to generally ignore our global traffic impact... torrent, video
and cloud are dominating that, not messaging anymore.

Post by Christian Huitema

Post by Bill Broadley
Scaling to 10B is going to change that much, 5 more bins, 40 more host
to ping every 15 minutes.

I believe this is actually an issue. The number of pings per host scales as
O(log N), which means the amount of maintenance traffic scales as O(N log N)
-- more than linearly with the size of the network. Given the nature of the
DHT, the addresses to be pinged
and the amount of noise will grow more than linearly with the
number of nodes in the network.

I think the question is, can we do what we want to do within
the bandwidth that our target users have available to them...
such as say a 56k channel, 128k, 512k, etc. If we're using
32 of 56k for maintenance, that may leave little left for the
signal you want to send through.

[Michael Rogers]

I think the question is, can we do what we want to do within the
bandwidth that our target users have available to them... such as
say a 56k channel, 128k, 512k, etc. If we're using 32 of 56k for
maintenance, that may leave little left for the signal you want to
send through.

In all the large DHT deployments I'm aware of, there's a distinction
between peers taking part in the DHT, i.e. holding key/value pairs,
and peers using the DHT, i.e. putting and getting key/value pairs.
Peers taking part in the DHT have to be reachable from the public
internet, and need a certain amount of bandwidth for maintenance
traffic. Peers using the DHT don't.

I think it's totally plausible to imagine a DHT with 10 million peers
taking part, some of them on high-bandwidth home connections, others
run by organisations to ensure the reliability of their own messaging
traffic; and 1 billion peers using the DHT, most of them on
intermittent, low-bandwidth connections and stuck behind NAT.

If there's one lesson to take from Gnutella, it's that not all peers
have equal resources, and you should design your system accordingly.

(If there are two lessons, the second one is not to build an
auto-update mechanism into the dominant implementation... but anyway...)

My concerns about using a DHT for secure messaging have nothing to do
with scalability - they're all about attack resilience and privacy.
When you look up a key in a DHT, you have no control over who sees
your lookup, or who can potentially misdirect it. There's been some
good research in this area in the last few years; I'm a bit behind
with my reading, but these papers are worth checking out:

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.300.6320
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.230.8639
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.308.5867
https://gnunet.org/r5n

Cheers,
Michael

[Bill Broadley]

Post by grarpamp
Other than for latency issues in our protocols, there's enough
fiber to generally ignore our global traffic impact... torrent, video
and cloud are dominating that, not messaging anymore.

Indeed. Even the "3rd world" of home internet connections the USA
(ranked 14th) has an average speed of 7mbit/sec. Any reasonable
multiple of Email/IM traffic is basically zero. Not particularly worth
discussing.

The hardest part of the problem is the feature set and social aspect of
launching a new messaging network. Clearly it's still happening with
Mxit, WhatsApp, WeChat, Line, Viber, MessageMe, Voxer, etc.

I think WhisperPush's approach with TextSecure is interesting:
* they partnered with cyanogen to because the default on a substantial
number of phones
* It "just works" with any SMS user, granted no security/encryption
* It "just works" securely with any other TextSecure user
* It also "just works" on IOS, granted a user has to track it down
and install it.

As far as I know Cyanogen does not have a secure IM app yet.

Post by grarpamp
On Sun, Jan 12, 2014 at 3:29 PM, Christian Huitema

Post by Christian Huitema
I believe this is actually an issue. The number of pings per host scales as
O(log N), which means the amount of maintenance traffic scales as O(N log N)
-- more than linearly with the size of the network. Given the nature of the
DHT, the addresses to be pinged

So yes, per node bandwidth scales with O(log N). System bandwidth with
O(N log N). But it's so small that it's mostly irrelevant. Sure some
phone users will be power limited or have a very low data cap, in those
cases they should install a raspberry pi at home or share a node with
more resources.

Don't worry about 2 billion users before you get 2000.

Post by grarpamp
I think the question is, can we do what we want to do within
the bandwidth that our target users have available to them...
such as say a 56k channel, 128k, 512k, etc. If we're using
32 of 56k for maintenance, that may leave little left for the
signal you want to send through.

10M users DHTs work today with minimal bandwidth overhead (kbit/sec)
while maintaining MByte/sec (factor of 8000 different). The huge
majority of node bandwidth goes to actually downloading torrents.

So basically I don't see any particularly big technical hurdles. Not
that there aren't others. The network effect and social issues being
the big ones.

ChatSecure looks pretty reasonable. In a perfect world I'd hope for a
client that:
* fully decentralized, only has find the bit-torrent mainline DHT to
be able to find peers. Why not use the existing 10M peers to help
find compatible peers.
* IPv6 capable, clearly the easiest way to directly connect other peers
in the future. Comcast is already over 25% and IPv6 seems to be
gathering steam.
* Simple tit-for-tat bandwidth and storage trading between owners.
Reputation based on direct observation (no 3rd parties).
* support for 2 tiers of peers, those with long connection times
bandwidth and power to burn and those with intermittent connections
and are power/bandwidth limited.
* allowing people to have a home node that trades bandwidth/storage
with peers and then a mobile node with the same crypto identify
that can leverage the home node and any of it's peers.

Ideally I could have a 2TB disk ($100) at hosting my more important
files (200GB) and earning the good will of it's peers by hosting
encrypted blobs for them. Leave it connected to a raspberry pi/beagle
board black for $40. Then as needed I can use the goodwill of those
peers to record for whatever bandwidth/storage needs I have.

So basically my node and it's friends could act collectively as my
IM/Mail/File server.

[grarpamp]

Post by Bill Broadley

Post by grarpamp
Other than for latency issues in our protocols, there's enough
fiber to generally ignore our global traffic impact... torrent, video
and cloud are dominating that, not messaging anymore.

Indeed. Even the "3rd world" of home internet connections the USA
(ranked 14th) has an average speed of 7mbit/sec. Any reasonable
multiple of Email/IM traffic is basically zero. Not particularly worth
discussing.
The hardest part of the problem is the feature set and social aspect of
launching a new messaging network. Clearly it's still happening with
Mxit, WhatsApp, WeChat, Line, Viber, MessageMe, Voxer, etc.
* they partnered with cyanogen to because the default on a substantial
number of phones
* It "just works" with any SMS user, granted no security/encryption
* It "just works" securely with any other TextSecure user
* It also "just works" on IOS, granted a user has to track it down
and install it.

Why these 'social launches' work for crappy apps is becuase the windows
writers cater to and know the forum using, bling ridden, pop, idiot-sphere.

While cpunk writers / good apps such as might be found below have
historically shied away from that catering/knowing, there is no reason
they cannot engage it, or that they cannot partner with people that do
to enable their own social launch.

https://prism-break.org/

Post by Bill Broadley
As far as I know Cyanogen does not have a secure IM app yet.

Post by grarpamp
On Sun, Jan 12, 2014 at 3:29 PM, Christian Huitema

Post by Christian Huitema
I believe this is actually an issue. The number of pings per host scales as
O(log N), which means the amount of maintenance traffic scales as O(N log N)
-- more than linearly with the size of the network. Given the nature of the
DHT, the addresses to be pinged

So yes, per node bandwidth scales with O(log N). System bandwidth with
O(N log N). But it's so small that it's mostly irrelevant. Sure some
phone users will be power limited or have a very low data cap, in those
cases they should install a raspberry pi at home or share a node with
more resources.
Don't worry about 2 billion users before you get 2000.

I don't agree. If you do not design for say 2bn users upfront
(as is the general subject of this thread re: nexgen global p2p solutions)
and instead target 200k or less, you will hit major roadblocks that
are very difficult to rip out and cure becuase your entire mindset
from day one was only scaling to a dreamy 200k. Mindset and failure
to think big traps projects like these, and if they somehow capture
and grow users they'll get overloaded to the point of unusability.
The best case they then embarrasingly have is to take a year
basically rewriting from scratch, or they fail and users move on.
And once a project hits unusability issues, that is a hard image to
shake... fool me once. This is a classic issue in systems history,
where better upfront design would have prevented it. The examples
are plenty, there's really no excuse anymore.

Post by Bill Broadley

Post by grarpamp
I think the question is, can we do what we want to do within
the bandwidth that our target users have available to them...
such as say a 56k channel, 128k, 512k, etc. If we're using
32 of 56k for maintenance, that may leave little left for the
signal you want to send through.

10M users DHTs work today with minimal bandwidth overhead (kbit/sec)
while maintaining MByte/sec (factor of 8000 different). The huge
majority of node bandwidth goes to actually downloading torrents.
So basically I don't see any particularly big technical hurdles. Not
that there aren't others. The network effect and social issues being
the big ones.
ChatSecure looks pretty reasonable. In a perfect world I'd hope for a
* fully decentralized, only has find the bit-torrent mainline DHT to
be able to find peers. Why not use the existing 10M peers to help
find compatible peers.
* IPv6 capable, clearly the easiest way to directly connect other peers
in the future. Comcast is already over 25% and IPv6 seems to be
gathering steam.
* Simple tit-for-tat bandwidth and storage trading between owners.
Reputation based on direct observation (no 3rd parties).
* support for 2 tiers of peers, those with long connection times
bandwidth and power to burn and those with intermittent connections
and are power/bandwidth limited.
* allowing people to have a home node that trades bandwidth/storage
with peers and then a mobile node with the same crypto identify
that can leverage the home node and any of it's peers.
Ideally I could have a 2TB disk ($100) at hosting my more important
files (200GB) and earning the good will of it's peers by hosting
encrypted blobs for them. Leave it connected to a raspberry pi/beagle
board black for $40. Then as needed I can use the goodwill of those
peers to record for whatever bandwidth/storage needs I have.
So basically my node and it's friends could act collectively as my
IM/Mail/File server.

The p2p pooled anon secure model is interesting. I think MaidSecure
was the most recent thing making the rounds in this area. Maybe
FreeNet is also similar.

Post by Bill Broadley
_______________________________________________
p2p-hackers mailing list
http://lists.zooko.com/mailman/listinfo/p2p-hackers

[David Barrett]

Post by Bill Broadley
* they partnered with cyanogen to because the default on a substantial
number of phones
* It "just works" with any SMS user, granted no security/encryption
* It "just works" securely with any other TextSecure user
* It also "just works" on IOS, granted a user has to track it down
and install it.

TextSecure is neat, but so far as I can tell it doesn't "organically"
promote itself -- I need to know "out of band" that you use TextSecure
before I can use it with you, because the key exchange message is
unintelligible. If it said something like "I'm using TextSecure; download
it from http://link to talk with me securely", then I could do a key
exchange with everyone without first asking if they know what it is.

Even better, it should automatically send this to everybody I talk with
first thing. This way I wouldn't even need to think about it: just install
TextSecure and it would automatically discover which of my friends have it
installed and silently use it, and automatically encourage everybody who
*doesn't* already have it installed to do so.

ChatSecure looks pretty reasonable. In a perfect world I'd hope for a

Post by Bill Broadley
* fully decentralized, only has find the bit-torrent mainline DHT to
be able to find peers. Why not use the existing 10M peers to help
find compatible peers.

Neat idea! Granted, you still need to somehow bootstrap into the
BitTorrent DHT, but I like the idea of boostrapping one DHT off of another
pre-existing DHT.

Post by Bill Broadley
* allowing people to have a home node that trades bandwidth/storage
with peers and then a mobile node with the same crypto identify
that can leverage the home node and any of it's peers.
Ideally I could have a 2TB disk ($100) at hosting my more important
files (200GB) and earning the good will of it's peers by hosting
encrypted blobs for them. Leave it connected to a raspberry pi/beagle
board black for $40. Then as needed I can use the goodwill of those
peers to record for whatever bandwidth/storage needs I have.

This is a really clever idea too! I like the idea of my home connection
gradually building long-lived "friendships" with other home nodes, and then
my mobile node can call upon my home and all its friends whenever it needs.

-david

[Christian Huitema]

Post by grarpamp
I think the question is, can we do what we want to do within
the bandwidth that our target users have available to them...
such as say a 56k channel, 128k, 512k, etc. If we're using
32 of 56k for maintenance, that may leave little left for the
signal you want to send through.

We went through that discussion several years ago during the design of PNRP.
One of our goals was to ensure that if two nodes were on the same "area"
they could find each other even if that area was cut-off from the rest of
the Internet. It turns out to be an interesting challenge, which leads to
some form of minimization of the maintenance traffic.

There are fewer and fewer candidates for "routing peers" as you go through
the levels of your routing table. At the first level, for each slot, if you
have N nodes in the network and K slots per level in your routing table,
there are N/K candidates per slot. Then, N/K^2 at the next level, etc.
Chances are that you can populate the first levels with nodes that are in
your area. This has the effect of minimizing the maintenance traffic, and
making it easier to contain it.

But at the most granular levels, your adjacencies will be all over the
Internet. There is definitely an effect on transcontinental links. Suppose
each node sends a mere 100bps average of such traffic. If you have 100
million nodes, that's 10 Gbps through the intercontinental link, just for
maintenance. Now, you may say that's a nice problem to have, because it
means wild success. But it still is a problem.

-- Christian Huitema

[grarpamp]

Post by grarpamp
This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today. There was
a former similarly named thread on this that diverged... from the
concept and challenge of P2P/DHT handling the transport and
lookups... back to more traditional models. This thread does not
care about those antique models, please do not take it there.

A problem which could rise is the 'incentive' for peers to continuosly
providing bandwidth and disk space to store messages. I'm a simple dude,
with a mailflow of ~5 email per day. Why I should work for you, with
your ~10000 mail per day for all your mailing list?
Somewhere on this list (or p2p-hackers?) there was a post of mine,
regardings an economic incentive between peers, which could be a
solution, but as always technical problems arose, like pricing the
services and a fair exchange between peers.

There may be advantage to the security of your own traffic if you
also handle the traffic of others.

Economically, it's probably not right to expect 'free' transport in
such a system. Though perhaps at minimum you should be
expected to provide benefit to the network an equivalent of what you
consume, including the extended cost to the net of your consumption.
ie: in a multi-hop network your impact is not just over your own interface.

And in an anonymous network it's most assuredly not right to
force users to pay using non-anonymous payment methods.
Though they may optionally do so if they wish.

How close is the research on these issues to being codeable
into actual p2p transports (whether anonymous (preferred) or not)?

[Bill Broadley]

Hopefully the mailing list is working again.

A problem which could rise is the 'incentive' for peers to continuosly
providing bandwidth and disk space to store messages. I'm a simple dude,
with a mailflow of ~5 email per day. Why I should work for you, with
your ~10000 mail per day for all your mailing list?

Bittorrent works pretty well and handles peers with widely varying
latencies and bandwidth. It has a very simple algorithm, you prefer
peers providing you the best bandwidth, tit for tat.

Why not do the same thing? You look for a N peers to trade for your
inbox size * redundancy factor. Someone with 100x the email needs
either larger or more peers to trade with.

If a peer uses too much bandwidth, if you are polite you notify them, if
not they should notice at the next check and look for a peer to replace you.

Somewhere on this list (or p2p-hackers?) there was a post of mine,
regardings an economic incentive between peers, which could be a
solution, but as always technical problems arose, like pricing the
services and a fair exchange between peers.

I've seen many complicated proposed systems with reputation, micro
payments, etc. While academically interesting I think tit-for-tat
should work just fine for this purpose. Trade a chunk of storage with a
peer and set the redundancy/replication factor to whatever you are
comfortable with. If you want to track down peers you actually know,
all the better.

[Randolph]

Post by grarpamp
This thread pertains specifically to the use of P2P/DHT models
to replace traditional email as we know it today.

*Anonymous Email based on virtual institutions*

What about this model? In a network you send your public email encryption
key to an "virtual institution".
The institution is defined by a name (e.g. AES string) and postal address
(e.g. hash key). Having this information added to your node, all your email
to you or from you will be stored in the virtual email provider
institution. This detaches your nodes IP and encrpytion key from the
institution. That means, care-off (c/o) institutions will be able to house
3rd-party e-mail without needing to distribute their own public keys.

To create a post office for your friends, two methods exist:

1) Define a common neighbor (e.g Alice and Bob connect to a common
webserver as node, and all three have email encryption keys shared), then
the webserver stores the emails, even if Alice or Bob are offline.

2) Or/additionally: Create an virtual institution and add the email key of
a friend to your node. In case your friend adds the magnet link (which
contains name and address of the virtual institution, aka AES key and Hash
key) for the institution as well to his node, the institution will save all
emails for him (as well from senders, which are not registered at the
virtual institution).

A Magnet Link allows to share the virtual institution easily. The magnet
Uri would look like:
*magnet:?in=Gmail&ct=aes256&pa=dotcom&ht=sha512&xt=urn:institution*

With this method an email provider can be build without data retention and
with the advantage of detached email encrpytion keys from nodeÂŽs IP
addresses. Next to TCP, you can use as well UDP and SCTP as protocol.

Virtual Institutions (VI) have been - due to the homepage - introduced by
the lib-version 0.9.04 of http://goldbug.sf.net email and chat application.

If we understand this right, now everyone can create an email provider
without data retention just as a service for friends. In case in a network
of connected nodes everyone uses "gmail" as VI-name and "dotcom" as
VI-address, everyone will host everyone for email, while all remains
encrypted.. could be a nice net or p2p model in a testing.

[grarpamp]

Although technical solutions are feasible

Then do it and see what happens.

- Email is older than the web itself;

So is TCP/IP and the transistor. Irrelevant.

- Email has three times as many users as all social networks combined;

And how did those nets get any users when 'email' was
supposedly working just fine?

- Email is entrenched in the offices, many a business is powered by it;

They are powered by authorized access to and useful end use of message
content, not by email. That's not going anywhere, only the intermediate
transport is being redesigned.

Given the enormous energy necessary to remove such an appliance and replace

Removal is different from introducing competitive alternatives.

it with something better. How could we make a secure solution that plays
nicely with the current tools without disturbing too much what is already
established?

By writing a gateway (i.e. between RetroShare and e-mail)?

MUA's become file readers and composers. They hand off
to a localhost daemon that recognizes different address formats
of the network[s] and does the right thing. Perhaps they compile
against additional necessary network/crypto libs. Whatever it
is, those are not a big change. Ditching centralized SMTP transport
in the clear is... and for the better.

Reread the threads, forget about that old SMTP box, think new.

[tpb-crypto-QFKgK+]

Message du 13/05/14 05:55
De : "grarpamp"
Objet : Re: [cryptography] The next gen P2P secure email solution

Although technical solutions are feasible

Then do it and see what happens.

- Email is older than the web itself;

So is TCP/IP and the transistor. Irrelevant.

You clearly did not get the point, but let's move along your argument.

- Email has three times as many users as all social networks combined;

And how did those nets get any users when 'email' was
supposedly working just fine?

E-mail not allowing one to make his ego appreciated and envied in a structured nicely formatted page maybe?

- Email is entrenched in the offices, many a business is powered by it;

They are powered by authorized access to and useful end use of message
content, not by email. That's not going anywhere, only the intermediate
transport is being redesigned.

Can you recode outlook, eudora and other closed source stuff people use(d) for e-mail handling for business? No? Well, that answers why it is hard to remove.

Given the enormous energy necessary to remove such an appliance and replace

Removal is different from introducing competitive alternatives.

Little proprietary walled gardens are absolutely not the answer for this problem.

it with something better. How could we make a secure solution that plays
nicely with the current tools without disturbing too much what is already
established?

By writing a gateway (i.e. between RetroShare and e-mail)?

The gateway idea is interesting, but it has to be efficient enough and low cost enough for people to switch over. Something like bitmessage is not.

MUA's become file readers and composers. They hand off
to a localhost daemon that recognizes different address formats
of the network[s] and does the right thing. Perhaps they compile
against additional necessary network/crypto libs. Whatever it
is, those are not a big change. Ditching centralized SMTP transport
in the clear is... and for the better.

http://arstechnica.com/security/2014/05/good-news-for-privacy-fewer-servers-sending-e-mail-naked-facebook-finds/

I think that answers your concern about SMTP transport in the clear, in less than one year the darkest bar in that chart will be close to 100%. If 80% of hosts demand strict encrypted transport, it will force the other 20% to change. Considering the snowden revelations and the fact that one year ago we barely used encrypted transport, having 1/4 already and accelerating is a good prospect.

Reread the threads, forget about that old SMTP box, think new.

Fixing the problem is better than overhauling all offices in the world, you clearly haven't been in may offices in your life.

_______________________________________________
cryptography mailing list
http://lists.randombit.net/mailman/listinfo/cryptography

[grarpamp]

Post by tpb-crypto-QFKgK+

Post by grarpamp

- Email is entrenched in the offices, many a business is powered by it;

They are powered by authorized access to and useful end use of message
content, not by email. That's not going anywhere, only the intermediate
transport is being redesigned.

Can you recode outlook, eudora and other closed source stuff people use(d) for e-mail handling for business? No? Well, that answers why it is hard to remove.
Fixing the problem is better than overhauling all offices in the world,

Nobody can recode closed source but them. I would offer [pluggable]
open source alternatives and let gravity move the closed ones
over time.

Post by tpb-crypto-QFKgK+

Post by grarpamp

Given the enormous energy necessary to remove such an appliance and replace

Removal is different from introducing competitive alternatives.

Little proprietary walled gardens are absolutely not the answer for this problem.

Nothing proprietary being made here, all open source, hack and use freely.

Post by tpb-crypto-QFKgK+

Post by grarpamp

it with something better. How could we make a secure solution that plays
nicely with the current tools without disturbing too much what is already
established?

By writing a gateway (i.e. between RetroShare and e-mail)?

The gateway idea is interesting, but it has to be efficient enough and low cost enough for people to switch over. Something like bitmessage is not.

Post by grarpamp
MUA's become file readers and composers. They hand off
to a localhost daemon that recognizes different address formats
of the network[s] and does the right thing. Perhaps they compile
against additional necessary network/crypto libs. Whatever it
is, those are not a big change. Ditching centralized SMTP transport
in the clear is... and for the better.

http://arstechnica.com/security/2014/05/good-news-for-privacy-fewer-servers-sending-e-mail-naked-facebook-finds/
I think that answers your concern about SMTP transport in the clear

Yes, great, we're now moving towards strict and PFS encrypted transport.
That's not much of a complete achievement since it does not solve any of
the other snowden-ish issues recent p2p threads are meant to encompass...
- [secret/trollish/illegal] orders against centralized mail servers/services
to store and disclose all metadata and [unencrypted] content, including
transport headers and pesky to/from/subject/etc headers.
- voluntary 'cooperation' to do the same.
- capability for messaging over encrypted anonymous p2p overlay networks
so that the only real place left to compel is the investigated user themselves
(or millions of users if you want to fight up against free speech / privacy).

Post by tpb-crypto-QFKgK+
you clearly haven't been in may offices in your life.

Don't say on others position until you are their shadow.

[tpb-crypto-QFKgK+]

Oh boy, here we go.

Message du 15/05/14 23:14
De : "grarpamp"

Post by tpb-crypto-QFKgK+
http://arstechnica.com/security/2014/05/good-news-for-privacy-fewer-servers-sending-e-mail-naked-facebook-finds/
I think that answers your concern about SMTP transport in the clear

Yes, great, we're now moving towards strict and PFS encrypted transport.
That's not much of a complete achievement since it does not solve any of
the other snowden-ish issues recent p2p threads are meant to encompass...
- [secret/trollish/illegal] orders against centralized mail servers/services
to store and disclose all metadata and [unencrypted] content, including
transport headers and pesky to/from/subject/etc headers.
pesky to/from/subject/etc headers.

Those are hidden by use of TLS. Regarding government wanting your data in the clear by requesting it to the ISP you use, well switch your communications to another country, problem solved.

- voluntary 'cooperation' to do the same.
- capability for messaging over encrypted anonymous p2p overlay networks
so that the only real place left to compel is the investigated user themselves
(or millions of users if you want to fight up against free speech / privacy).

p2p is no panacea, it doesn't scale and it will never, ever be able to handle the latest netflixy app Joes are so much into. p2p is for techead kids like you, not for the masses. The masses do not understand it unless it brings spiderman, batman, faggotman hollywood garbage faster to their living rooms.

[grarpamp]

Post by tpb-crypto-QFKgK+

Post by grarpamp
pesky to/from/subject/etc headers.

Oh boy, here we go.
Those are hidden by use of TLS.

Have you not been following the 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.

We want all human relevant plaintext content, such pesky
headers included, to be hidden from observation by anyone
other than us (at our origination or final receipt nodes).
There is no oh boy in that sensible new design.

Post by tpb-crypto-QFKgK+
Regarding government wanting your data in the clear by requesting it to the ISP you use, well switch your communications to another country, problem solved.

Have you ever heard of MLAT, extradition, interpol, public
and private cooperation, dealings, and other such things? And
maybe you simply do not trust any 'country' with carriage of your
insistent plaintext. There is no such 'solved' with that.

Post by tpb-crypto-QFKgK+

Post by grarpamp
- voluntary 'cooperation' to do the same.
- capability for messaging over encrypted anonymous p2p overlay networks
so that the only real place left to compel is the investigated user themselves
(or millions of users if you want to fight up against free speech / privacy).

p2p is no panacea, it doesn't scale

I believe it could. Even if requiring super aggregating
nodes of some sort. Layers of service of the whole
DHT space. More research is surely required.

Post by tpb-crypto-QFKgK+
and it will never, ever be able to handle the latest netflixy app Joes are so much into.

p2p is for techead kids like you, not for the masses.

We are talking messaging, not bulk data.
However, once you have the nodes scalable to millions
of communicators, there is probably no issue transporting
bulk data among a select few along their path metrics.

Cathal brings up a great and tricky issue regarding
choices to store-and-forward. S&F is quite more
complex, but possibly more useful, than realtime.

Post by tpb-crypto-QFKgK+
The masses do not understand it unless it brings spiderman, batman, faggotman hollywood garbage faster to their living rooms.

I agree such garbage is rather pointless life endeavour.
I would be happy to message you via such a new
messaging system though :)

[tpb-crypto-QFKgK+]

Message du 16/05/14 02:26
De : "grarpamp"
Objet : Re: [cryptography] The next gen P2P secure email solution

Post by tpb-crypto-QFKgK+

Post by grarpamp
pesky to/from/subject/etc headers.

Oh boy, here we go.
Those are hidden by use of TLS.

Have you not been following the 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, you can't hide it even in Bitcoin, Tor or any other network which has to find its destinations to deliver its contents. The best you can do is cloak it, but like any cover there are means to uncover it.

We want all human relevant plaintext content, such pesky
headers included, to be hidden from observation by anyone
other than us (at our origination or final receipt nodes).
There is no oh boy in that sensible new design.

Post by tpb-crypto-QFKgK+
Regarding government wanting your data in the clear by requesting it to the ISP you use, well switch your communications to another country, problem solved.

Have you ever heard of MLAT, extradition, interpol, public
and private cooperation, dealings, and other such things? And
maybe you simply do not trust any 'country' with carriage of your
insistent plaintext. There is no such 'solved' with that.

What is Iran? What is Cuba? What is China? What is Switzerland?

Post by tpb-crypto-QFKgK+

Post by grarpamp
- voluntary 'cooperation' to do the same.
- capability for messaging over encrypted anonymous p2p overlay networks
so that the only real place left to compel is the investigated user themselves
(or millions of users if you want to fight up against free speech / privacy).

p2p is no panacea, it doesn't scale

I believe it could. Even if requiring super aggregating
nodes of some sort. Layers of service of the whole
DHT space. More research is surely required.

Here is your problem, you hold a belief, I hold knowledge. That's the little difference between us. It is not possible to have fast p2p unless:
- Cable networks collaborate by increasing bandwidth 7 to 8 times the current levels without increasing costs. That was done Brazil and South Korea which now have much better internet than the US. But the US still rule as the biggest market;
- People accept a more bumpy internet experience;

Post by tpb-crypto-QFKgK+
and it will never, ever be able to handle the latest netflixy app Joes are so much into.

p2p is for techead kids like you, not for the masses.
We are talking messaging, not bulk data.
However, once you have the nodes scalable to millions
of communicators, there is probably no issue transporting
bulk data among a select few along their path metrics.

The first thing people complained about Tor was that they couldn't run bittorrents with it and they couldn't see youtube.

Cathal brings up a great and tricky issue regarding
choices to store-and-forward. S&F is quite more
complex, but possibly more useful, than realtime.

Post by tpb-crypto-QFKgK+
The masses do not understand it unless it brings spiderman, batman, faggotman hollywood garbage faster to their living rooms.

I agree such garbage is rather pointless life endeavour.
I would be happy to message you via such a new
messaging system though :)

I would it too, of course. But in order to make it work we have to dial back the complexity of our pages and our want for high definition videos.

It is not interesting to merely have an e-mail substitute, because instead of e-mail metadata spies will request our google search and navigation history. You will certainly send links and those tell a lot about what we are talking about.

[grarpamp]

Post by tpb-crypto-QFKgK+

Post by grarpamp

Post by tpb-crypto-QFKgK+
p2p is no panacea, it doesn't scale

I believe it could. Even if requiring super aggregating
nodes of some sort. Layers of service of the whole
DHT space. More research is surely required.

- Cable networks collaborate by increasing bandwidth 7 to 8 times

My references to scale were not intended to be about...
bulk bandwidth across such networks (for example, right
now, I2P and Tor are doing well enough to see very low
quality video between their hidden nodes if you get a lucky
path, and well enough for moving large files around in non
realtime). ie: the nodes have bandwidth available.

But about scaling the node (user) count from millions to billions...
No device (or its ethernet) will be able to manage a 10 billion
entry DHT with a handful of keys, addresses and flags per entry.
But if you break it up into some many clusters/hiers/roles of smaller
DHT's, each knowing how to route queries, sort, and pass entries
around, it might work. Once you've assembled your multihop
path from querying the DHT for nodes, actual data transfer
rates should remain similar. (Provided the network clients
know to reserve bandwidth mod the network average hop count,
by throttling the users usage at their own node).

It would be nice to check some numbers on this for the list.
Is there a wiki or paper repository that discusses plausibly
reachable DHT sizes, time needed for DHT ops to resolve,
and management schemes for such clusters/hiers/roles?


[aside: This everyone online, big DHT, end-to-end reachable
model mirrors the internet today as a general purpose tool.
Perhaps sufficient for many rather sensitive tasks.
When the purpose is narrowed, other models may apply.
For messaging (as is the subject), everyone still needs a
unique address. And since msg delivery/pickup must be
reliable, there is a question of redundancy needed to avoid
random msg loss. Which may turn you away from store-forward,
mixes, and unconscious central storage, etc... towards everyone
online, contact them directly over a path or retry later.
Today it seems that general purpose may be better researched
and easier than more exotic means. Question is, is GP sufficient,
after applying any recent GP tech post I2P and Tor's designs?
ie: Some say timing attacks may be mitigated by fixed packet
lengths and adding chaff over links as cover.]

[Michael Rogers]

It would be nice to check some numbers on this for the list. Is
there a wiki or paper repository that discusses plausibly reachable
DHT sizes, time needed for DHT ops to resolve, and management
schemes for such clusters/hiers/roles?

A couple of old papers:
http://sahara.cs.berkeley.edu/jan2004-retreat/slides/bamboo-tr.pdf
http://www.iptps.org/papers-2004/li-churn.pdf

The first paper finds that a 1000-node DHT under heavy churn has a 900
byte/second bandwidth overhead, which grows logarithmically with the
number of nodes. The second paper compares the performance of various
DHT designs under churn.

A more recent paper finds that there are 15-27 million nodes in the
mainline DHT:
http://www.cs.helsinki.fi/u/lxwang/publications/P2P2013_13.pdf

Cheers,
Michael

[grarpamp]

On Sun, Jun 1, 2014 at 9:45 PM, Cathal (phone)

What about streaming, which is increasingly used to hold power to account in
real time? Or other rich, necessarily large media which needs to *get out
fast*? Big media isn't always frivolous. Even frivolity is important, and a
mixnet without fun is gonna be a small mixnet.

Would you rather have one 4k video taken from someone's phone
jiggling in their backpocket as they run with blood all over the lens,
ten emails from people in situ known to you, or photodumps from
two balcony photographers... all of which just saw some gov beat
the fuck out of a bunch of sitdown protesters?
Either way, the choice is best left to the sender. Our role is merely
to make good systems, explain their design, options and tradeoffs,
and then carry the data.

[grarpamp]

Post by tpb-crypto-QFKgK+

Post by grarpamp
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.

[p***@gmail.com]

Post by grarpamp

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.

Yes of course... the minimum necessary for delivery is the
destination address.

Is this absolutelly necesary to be on clear? Can't it be possible to
be broadcasted and forwarded to all the peers in the network, or it
would be a no sense? I'm developing a WebRTC signaling channel library
(http://webp2p.io) and for its next version I have been writting a
specification of the protocol, and got to the conclussion that the
destination address is not neccesary to be on clear if you use
public-keys as IDs so messages can only be decrypted by the receiver,
and the data send in clear can be just only a TTL field... The
protocol is designed to be used only to handshake and create a direct
PeerConnection between both peers, so after that the data is send
encrypted using DTLS by the DataChannel itself as WebRTC specification
mandates, so I think the fact of sending the request with the encypted
destination by broadcast would not be such a problem in terms of
bandwidth, but maybe I'm wrong here... Any comments and suggestions
are welcome:

https://github.com/ShareIt-project/WebP2P.io/blob/0.2.0/doc/draft-piranna-webp2p-01.txt

[Michael Rogers]

Post by p***@gmail.com

Post by grarpamp

Post by tpb-crypto-QFKgK+
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.

Yes of course... the minimum necessary for delivery is the
destination address.

Is this absolutelly necesary to be on clear? Can't it be possible
to be broadcasted and forwarded to all the peers in the network, or
it would be a no sense?

It's possible, but it wouldn't scale well. There are some routing
protocols for ad hoc wireless networks that take that approach:

A. Boukerche, K. El-Khatib, L. Xu, and L. Korba. SDAR: A secure
distributed anonymous routing protocol for wireless and mobile ad hoc
networks. In Proceedings of the 29th Annual IEEE International
Conference on Local Computer Networks (LCN 2004), Tampa, FL, USA,
pages 618–624, November 2004.

R. Song, L. Korba, and G. Yee. AnonDSR: Efficient anonymous dynamic
source routing for mobile ad-hoc networks. In Proceedings of the ACM
Workshop on Security of Ad Hoc and Sensor Networks (SASN 2005),
Alexandria, VA, USA, pages 32–42, November 2005.

B. Zhu, Z. Wan, M.S. Kankanhalli, F. Bao, and R.H. Deng. Anonymous
secure routing in mobile ad-hoc networks. In Proceedings of the 29th
Annual IEEE International Conference on Local Computer Networks (LCN
2004), Tampa, FL, USA, pages 102–108, November 2004.

S. Seys and B. Preneel. ARM: Anonymous routing protocol for mobile ad
hoc networks. In Proceedings of the 20th International Conference on
Advanced Information Networking and Applications (AINA 2006), Vienna,
Austria, pages 133–137, April 2006.
http://www.cosic.esat.kuleuven.be/publications/article-636.pdf

Cheers,
Michael

[p***@gmail.com]

Thanks for your references, I'll take them in account. I though about
don't send in clear the destinatary of the message because it would be
an identifier that could be used by others to censor that messages or
also as a target to try to decypher them. Is this reasonable, or too
much paranoid? Could be a per session public-key generated by a random
seed considered enough anonymous, or my concerns would still apply
(censorship and decypher target)?

Post by adrelanos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by p***@gmail.com

Post by grarpamp

Post by tpb-crypto-QFKgK+
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.

Yes of course... the minimum necessary for delivery is the
destination address.

Is this absolutelly necesary to be on clear? Can't it be possible
to be broadcasted and forwarded to all the peers in the network, or
it would be a no sense?

It's possible, but it wouldn't scale well. There are some routing
A. Boukerche, K. El-Khatib, L. Xu, and L. Korba. SDAR: A secure
distributed anonymous routing protocol for wireless and mobile ad hoc
networks. In Proceedings of the 29th Annual IEEE International
Conference on Local Computer Networks (LCN 2004), Tampa, FL, USA,
pages 618–624, November 2004.
R. Song, L. Korba, and G. Yee. AnonDSR: Efficient anonymous dynamic
source routing for mobile ad-hoc networks. In Proceedings of the ACM
Workshop on Security of Ad Hoc and Sensor Networks (SASN 2005),
Alexandria, VA, USA, pages 32–42, November 2005.
B. Zhu, Z. Wan, M.S. Kankanhalli, F. Bao, and R.H. Deng. Anonymous
secure routing in mobile ad-hoc networks. In Proceedings of the 29th
Annual IEEE International Conference on Local Computer Networks (LCN
2004), Tampa, FL, USA, pages 102–108, November 2004.
S. Seys and B. Preneel. ARM: Anonymous routing protocol for mobile ad
hoc networks. In Proceedings of the 20th International Conference on
Advanced Information Networking and Applications (AINA 2006), Vienna,
Austria, pages 133–137, April 2006.
http://www.cosic.esat.kuleuven.be/publications/article-636.pdf
Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJTi5RLAAoJEBEET9GfxSfMIZEH/0wZ31OjI092QJsoqgz7tKe8
4SX0nXsewpK050CELG5pIHNfibX+TkxOSkkZh3ZxnKxqdadhhP/wFrNej2gwmF8v
ULF6QMfPuFHT8KCI205hdw3hsqHU1HIpC7grde7yF2dQHXBQwFog08kY4RlPEPz4
MoLOF0SSC1nZuJZ/Q5XfQo0iOXZ1SF6AMgM+m25bPhYGjzPUWMXaonZh2G7VSMj3
VGdfxPnj4i/6Ximbofmf2+ppm7yFEiOh0aDbrnz9bCryGvcSda3GSp+NKMpOEuRN
eZ1TzMBhcVOWxxKLMp7IO7LkLOj7JOTgashipGTauDJGtGpoz4ExF6udfSnk3PY=
=QtiP
-----END PGP SIGNATURE-----
_______________________________________________
p2p-hackers mailing list
http://lists.zooko.com/mailman/listinfo/p2p-hackers