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:
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. =====
On 24/12/13 at 04:20am, grarpamp wrote:
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 danimoth@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.
On Tue, Dec 24, 2013 at 5:01 AM, danimoth <danimoth@cryptolab.net> wrote:
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 danimoth@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.
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
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 post handoff to you: 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.
On 24/12/13 at 04:20am, grarpamp wrote:
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.
On Tue, Dec 24, 2013 at 5:09 AM, danimoth <danimoth@cryptolab.net> wrote:
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.)
On Tue, Dec 24, 2013 at 5:09 AM, danimoth <danimoth@cryptolab.net> wrote:
On 24/12/13 at 04:20am, grarpamp wrote:
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)?
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 account@node. All the MTA's [connected directly to the internet] die off in time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 24 Dec 2013 04:20:51 -0500 grarpamp <grarpamp@gmail.com> wrote:
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.
That is exactly what we have implemented already: http://enigmabox.net/en/encrypted-emails/ And it works pretty well. We rely on cjdns for everything network related (transport, end-to-end encryption, address allocation). - -- 42 <42@enigmabox.net> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSueHPAAoJELqmW1wGWUSYqVkP/jDH0pm9hLRO+zwCRrzmKGjT Q+j6/YXiNwvxv6KJsE4xZOF3f2uuA1496/jDhhSwE042daM7wU1Lt5AH6s0KlQJB f2lE1q7xutvH9MxNlntpJOvMG5ROGID554CGF6hDjs8lvto1HDkvm+D4qx/lWSAR Q1AEwiCWpcpP3aFKxCqGw3/X91UYvSDhpewzGiBcJljNmbzEWa4YmlB4bUavR3qL INVB7NIj/XdbwWOW1OSU5NF1FQoLqz9W5rJ3VP3Nkl8dK4rPp5tcvp+ZNXJ6awSD jVr1WIKncmIbJwVrItKPMb+Y16STF0mMO/DOFH3Zsj5Po8F/QsXsr54de1WkHCkY 82DVAsxl9dkrLekugVShDsWIfNoS4w4P3hOCshBV+9bWplIZ8vLQfdQX3RRxL2L0 BwEIWqkGBfPShq8rZiswA79jVVcmWaCRZ37EtfNJKndjgRx+/yzJWGsLF253UiQn jOs0m7+Qmj3i0joNWnsr17hldLW+P6bJwPyHaJL/MMlHgSuJgfZoOvOjmBoH5VZO y+P4QHPlu7w2ehipbCcdnNlKZXL/pMKBF8o89l4b0cRVaLOcxBvfJWs5BEqEhhdr flGdhQbgNS/H5t6hqd93M6J4y3Gj+YZ1mRv9LgOpSvQaCQnq3PM4NHNDGr7XCipL +RvlfRziqmpmRApgVt+d =3CQb -----END PGP SIGNATURE-----
Anyone looked at BitMail p2p ? http://sourceforge.net/projects/bitmail/?source=directory 2013/12/24 grarpamp <grarpamp@gmail.com>
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.
On Wed, Dec 25, 2013 at 7:19 AM, Randolph <rdohm321@gmail.com> wrote:
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.
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 2013/12/25 grarpamp <grarpamp@gmail.com>
Anyone looked at BitMail p2p ? http://sourceforge.net/projects/bitmail/?source=directory
If you need hosting for code,
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.
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.
Message du 22/04/14 20:30 De : "Randolph"
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.
Although technical solutions are feasible, we ought to consider some things: - Email is older than the web itself; - Email has three times as many users as all social networks combined; - Email is entrenched in the offices, many a business is powered by it; Given the enormous energy necessary to remove such an appliance and replace 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?
Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-crypto@laposte.net pisze:
Although technical solutions are feasible, we ought to consider some things: - Email is older than the web itself; - Email has three times as many users as all social networks combined; - Email is entrenched in the offices, many a business is powered by it;
Given the enormous energy necessary to remove such an appliance and replace 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)? -- Pozdr rysiek
On Fri, May 9, 2014 at 11:49 AM, rysiek <rysiek@hackerspace.pl> wrote:
Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-crypto@laposte.net pisze:
Although technical solutions are feasible
Then do it and see what happens.
we ought to consider some things: - 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.
Message du 13/05/14 05:55 De : "grarpamp" A : cypherpunks@cpunks.org Copie à : p2p-hackers@lists.zooko.com, cryptography@randombit.net Objet : Re: [cryptography] The next gen P2P secure email solution
On Fri, May 9, 2014 at 11:49 AM, rysiek wrote:
Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-crypto@laposte.net pisze:
Although technical solutions are feasible
Then do it and see what happens.
we ought to consider some things: - 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-... 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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Little proprietary walled gardens are absolutely not the answer for this problem.
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.
I actually think, having used it for some time and liking it on the whole, that Retroshare isn't suited to this. The primary reason is RS only receives mail if the sender and recipient are online at the same time. There's no store-and-forward, even though all messages are PGP encrypted to recipients. RS also has a lot of feature-bloat; it's better thought of as P2P Facebook than a simple communication system. Finally, RS is engineered to a simple and admirable purpose which makes it unsuited to email replacement; it's Friend to Friend. That's great in its use-case, but I think email should be: 1) Rapid and censorship-resilient routing 2) Single canonical addresses for each participant, which are human-readable. 3) Churn-tolerant 4) Expensive to send, to deter spam otherwise facilitated by to (1) 5) Practical for payloads between 10M and 20M, no greater. I do *not* think the core of a replacement email should guarantee anonymity, but the protocol should make allowances for that if possible. I think the above could be satisfied using a pseudo-blockchain for name->key mappings, and a key-routed DHT for creating routes for mail delivery. Credit is earned by routing other people's mail in store-and-forward fashion, like email. Credit can be spent to register new mail address:key mappings and to pay for routing of larger messages, or to prolong retention of messages before they bounce (if your intended recipient does not run a high-uptime mailserver and may need a day or two to log in). That resembles Twister, the coupling of DHT:Blockchain, but may be better suited to the model than twister is (because twister hit problems with scaling DHT use to many followers, I think), because email is slower and stabler than microstatus systems; more amenable to P2P-isation, whereas rapid updates coupled with mass-queries to other feeds is a setup better suited to a client:server interaction. The blockchain would need tweaking, because Twister is using scrypt, which is now apparently ASIC-able, e.g. useless. I think a password encrypting function whose parameters are set dynamically by the value of the prior block might help fix matters; the goal is for the ideal "ASIC" for the function to be a consumer CPU, not a GPU or dedicated ASIC. Anyway, sorry for the wall of text. Killing/replacing email is often on my mind. On 15/05/14 13:36, tpb-crypto@laposte.net wrote:
Message du 13/05/14 05:55 De : "grarpamp" A : cypherpunks@cpunks.org Copie à : p2p-hackers@lists.zooko.com, cryptography@randombit.net Objet : Re: [cryptography] The next gen P2P secure email solution
On Fri, May 9, 2014 at 11:49 AM, rysiek wrote:
Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-crypto@laposte.net pisze:
Although technical solutions are feasible
Then do it and see what happens.
we ought to consider some things: - 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-...
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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com
OHAI, Dnia czwartek, 15 maja 2014 16:39:51 Cathal Garvey pisze:
Little proprietary walled gardens are absolutely not the answer for this problem.
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.
I actually think, having used it for some time and liking it on the whole, that Retroshare isn't suited to this.
The primary reason is RS only receives mail if the sender and recipient are online at the same time. There's no store-and-forward, even though all messages are PGP encrypted to recipients.
Wouldn't that be possible to change? For example by creating store-and-forward servers that would not be *required* for RS operation, but would add this as an added feature?
RS also has a lot of feature-bloat; it's better thought of as P2P Facebook than a simple communication system.
That is very true.
Finally, RS is engineered to a simple and admirable purpose which makes it unsuited to email replacement; it's Friend to Friend. That's great in its use-case, but I think email should be:
1) Rapid and censorship-resilient routing 2) Single canonical addresses for each participant, which are human-readable. 3) Churn-tolerant 4) Expensive to send, to deter spam otherwise facilitated by to (1) 5) Practical for payloads between 10M and 20M, no greater.
I do *not* think the core of a replacement email should guarantee anonymity, but the protocol should make allowances for that if possible.
It should at least guarantee pseudonymity, IMHO.
I think the above could be satisfied using a pseudo-blockchain for name->key mappings, and a key-routed DHT for creating routes for mail delivery. Credit is earned by routing other people's mail in store-and-forward fashion, like email. Credit can be spent to register new mail address:key mappings and to pay for routing of larger messages, or to prolong retention of messages before they bounce (if your intended recipient does not run a high-uptime mailserver and may need a day or two to log in).
Interesting.
That resembles Twister, the coupling of DHT:Blockchain, but may be better suited to the model than twister is (because twister hit problems with scaling DHT use to many followers, I think),
https://github.com/miguelfreitas/twister-core/issues/24 https://github.com/miguelfreitas/twister-core/issues/165
because email is slower and stabler than microstatus systems; more amenable to P2P-isation, whereas rapid updates coupled with mass-queries to other feeds is a setup better suited to a client:server interaction. The blockchain would need tweaking, because Twister is using scrypt, which is now apparently ASIC-able, e.g. useless. I think a password encrypting function whose parameters are set dynamically by the value of the prior block might help fix matters; the goal is for the ideal "ASIC" for the function to be a consumer CPU, not a GPU or dedicated ASIC.
Makes sense.
Anyway, sorry for the wall of text. Killing/replacing email is often on my mind.
Yeah, I also have a love-hate relationship with this communication medium. -- Pozdr rysiek
On Thu, May 15, 2014 at 8:36 AM, <tpb-crypto@laposte.net> wrote:
- 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.
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.
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-... 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).
you clearly haven't been in may offices in your life.
Don't say on others position until you are their shadow.
Oh boy, here we go.
Message du 15/05/14 23:14 De : "grarpamp"
http://arstechnica.com/security/2014/05/good-news-for-privacy-fewer-servers-... 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.
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.
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.
- 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.
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. 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.
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 :)
Dnia czwartek, 15 maja 2014 20:26:27 grarpamp pisze:
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.
And I don't think they're hidden in any meaningful way on the server-to-server wire. As in: whose mailserver validates TLS of the destination server? That's actually an interesting research question. This goes for other semi- decentralised, client-server services like XMPP for instance. And even if they do validate it, thinking that NSA et al do not have root certs allowing them to MITM the communication as they wish is naivety. -- Pozdr rysiek
Message du 16/05/14 02:26 De : "grarpamp" A : p2p-hackers@lists.zooko.com Copie à : cypherpunks@cpunks.org, cryptography@randombit.net Objet : Re: [cryptography] The next gen P2P secure email solution
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.
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?
- 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;
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.
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.
... 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. ...
Yes. Yes. Yes. The HTTP Archive says that the average web page today makes out-references to 16 different domains as well as making 17 Javascript requests per page, and the Javascript byte count is several times the HTML byte count.[HT] A lot of that Javascript is, as you well know, about analytics which is to say surveillance of the user "experience." I wish I could get it across to those who like free as in paid for by advertising and the video junkies that it is their demand for, and their willingnesss to accept, remote procedure calls from arbitrary servers (RPCs written in Turing complete languages I might add) that will have the effects that we here can so well anticipate. Mozilla's announcement that it will bend to demand and build in DRM is indicative. In short, can this baby be saved? I really don't know. --dan [HT] Trends, HTTP Archive; www.httparchive.org/trends.php
In May 2014 someone wrote:
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.
It is not possible to have fast p2p unless: - 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.]
Message du 01/06/14 20:37 De : "grarpamp"
In May 2014 someone wrote:
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.
It is not possible to have fast p2p unless: - 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.
We all wish privacy, not necessarily 4k videos. The current bandwidth can provide for 4k videos and also privacy, no matter if a littler slower, for a little chat, work and file transfers. Except if you are into media production or warez, the current bandwidth already does the trick for all the rest.
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. On 2 June 2014 02:33:56 GMT+01:00, tpb-crypto@laposte.net wrote:
Message du 01/06/14 20:37 De : "grarpamp"
In May 2014 someone wrote:
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.
It is not possible to have fast p2p unless: - 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.
We all wish privacy, not necessarily 4k videos. The current bandwidth can provide for 4k videos and also privacy, no matter if a littler slower, for a little chat, work and file transfers.
Except if you are into media production or warez, the current bandwidth already does the trick for all the rest.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I think frivolous stuff could wait some more ... but you can always bundle several connections by means of bonding interfaces. I know it is not the best approach, but let's suppose you need to command a robot or conduct a surgery over p2p. Bonding a few openvpn connections together would do the trick.
Message du 02/06/14 03:45 De : "Cathal (phone)" A : tpb-crypto@laposte.net, tpb-crypto@laposte.net, "grarpamp" , p2p-hackers@zim.maski.org Copie à : cypherpunks@cpunks.org, cryptography@randombit.net Objet : Re: [cryptography] The next gen P2P secure email solution
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.
On 2 June 2014 02:33:56 GMT+01:00, tpb-crypto@laposte.net wrote:
Message du 01/06/14 20:37 De : "grarpamp"
In May 2014 someone wrote:
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.
It is not possible to have fast p2p unless: - 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.
We all wish privacy, not necessarily 4k videos. The current bandwidth can provide for 4k videos and also privacy, no matter if a littler slower, for a little chat, work and file transfers.
Except if you are into media production or warez, the current bandwidth already does the trick for all the rest.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sun, Jun 1, 2014 at 9:45 PM, Cathal (phone) <cathalgarvey@cathalgarvey.me> wrote:
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.
On Fri, May 16, 2014 at 6:01 AM, <tpb-crypto@laposte.net> wrote:
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.
participants (9)
-
42 -
Cathal (phone) -
Cathal Garvey
-
dan＠geer.org -
danimoth -
grarpamp -
Randolph -
rysiek -
tpb-crypto＠laposte.net