[cryptography] The next gen P2P secure email solution

Natanael natanael.l at gmail.com
Tue Dec 24 05:03:30 EST 2013


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
Den 24 dec 2013 10:21 skrev "grarpamp" <grarpamp at gmail.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 at 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 at 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 at 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 at 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 at 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 at 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.
> =====
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20131224/13b1e7de/attachment-0001.html>


More information about the cryptography mailing list