public inbox for cryptoparty@lists.cypherpunks.ru
Atom feed
* Fwd: [p2p-hackers] The next gen P2P secure email solution
@ 2013-12-25 16:43 stargrave
  2013-12-25 18:09 ` stargrave
  0 siblings, 1 reply; 11+ messages in thread
From: stargrave @ 2013-12-25 16:43 UTC (permalink / raw)
  To: cryptoparty.ru

[-- Attachment #1: Type: text/plain, Size: 20691 bytes --]

Приветствую всех!

Письмо с приличной выдержкой цитат обсуждений о создании в общем-то
новой инфраструктуры email систем. Довольно много интересного. Никто
конечно не собирается уничтожать MUA, но заменить сами транспорты (MTA)
можно относительно прозрачно.

Для себя отметил что часто упоминаются I2P email и IM системы которые
адресуются по публичному ключу внутри DHT сетей. Ну в общем-то штатный
шифропанковский режим работы. Надо будет заценить. Так как если оно
рабочее, то надо брать на заметку.

Freenet реализация у меня даже с неделями работы как-то не очень
подружилась. Возможно там черезчур сильный упор на анонимизацию. Для
этого легко можно использовать store-and-forward сети, как например
mixmaster но уже внутри/поверх I2P-ных транспортов. Если анонимность не
первое что нужно, а нужна хорошая гарантированная доставка (пусть не с
первого раза ☺) и это в I2P имеется уже сейчас (как и сам I2P IMHO
вполне себе стабильный продукт, опять же в отличии от Freenet-а, к
сожалению) то круто. Плюс можно оценить IM что из себя представляет.
Ибо для real-time conversation Freenet/GNUnet не подходят, а I2P
отлично. Один из главных вопросов конечно совместимость с софтом.

----- Forwarded message from grarpamp <grarpamp@gmail•com> -----

Date: Tue, 24 Dec 2013 04:20:51 -0500
From: grarpamp <grarpamp@gmail•com>
To: cypherpunks@cpunks•org
Cc: p2p-hackers@lists•zooko.com, cryptography@randombit•net
Subject: [p2p-hackers] The next gen P2P secure email solution
List-Id: theory and practice of decentralized computer networks <p2p-hackers.lists.zooko.com>

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, string@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...
On Mon, Nov 25, 2013 at 1:01 AM, ianG <iang@iang•org> wrote:
> On 23/11/13 15:30 PM, Ralf Senderek wrote:
>> On Sat, 23 Nov 2013, David Mercer wrote:
>>
>>> 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@some•dotcom.
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 msg@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 account@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 'account@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...
> You can use an untrusted CA to bootstrap. I show how it can be done at:
>
> 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.
=====
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists•zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers

----- End forwarded message -----

-- 
Happy hacking, Sergey Matveev

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2013-12-28 21:52 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-25 16:43 Fwd: [p2p-hackers] The next gen P2P secure email solution stargrave
2013-12-25 18:09 ` stargrave
2013-12-28 15:19   ` Januk Latushka
2013-12-28 16:10     ` Лепра (was: Fwd: [p2p-hackers] The next gen P2P secure email solution) stargrave
2013-12-28 16:14     ` Лепра stargrave
2013-12-28 19:16       ` Лепра Januk Latushka
2013-12-28 19:40         ` Лепра stargrave
2013-12-28 20:56           ` Лепра Januk Latushka
2013-12-28 21:51             ` Лепра stargrave
2013-12-28 19:50     ` Лепра stargrave
2013-12-28 21:05       ` Лепра Januk Latushka