Re: [cryptography] The next gen P2P secure email solution
On Sun, Jun 1, 2014 at 9:45 PM, Cathal (phone) cathalgar...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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.] ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Fri, May 16, 2014 at 6:01 AM, tpb-cry...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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-cry...@laposte.net, tpb-cry...@laposte.net, grarpamp , p2p-hack...@zim.maski.org Copie à : cypherpu...@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-cry...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
Message du 16/05/14 02:26 De : grarpamp A : p2p-hack...@lists.zooko.com Copie à : cypherpu...@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. SF 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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
Message du 13/05/14 05:55 De : grarpamp A : cypherpu...@cpunks.org Copie à : p2p-hack...@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-cry...@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-sending-e-mail-naked-facebook-finds/ I think that answers your concern about SMTP transport in the clear, in less than one year the darkest bar in that chart will be close to 100%. If 80% of hosts demand strict encrypted transport, it will force the other 20% to change. Considering the snowden revelations and the fact that one year ago we barely used encrypted transport, having 1/4 already and accelerating is a good prospect. Reread the threads, forget about that old SMTP box, think new. Fixing the problem is better than overhauling all offices in the world, you clearly haven't been in may offices in your life. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Thu, May 15, 2014 at 8:36 AM, tpb-cry...@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-sending-e-mail-naked-facebook-finds/ I think that answers your concern about SMTP transport in the clear Yes, great, we're now moving towards strict and PFS encrypted transport. That's not much of a complete achievement since it does not solve any of the other snowden-ish issues recent p2p threads are meant to encompass... - [secret/trollish/illegal] orders against centralized mail servers/services to store and disclose all metadata and [unencrypted] content, including transport headers and pesky to/from/subject/etc headers. - voluntary 'cooperation' to do the same. - capability for messaging over encrypted anonymous p2p overlay networks so that the only real place left to compel is the investigated user themselves (or millions of users if you want to fight up against free speech / privacy). you clearly haven't been in may offices in your life. Don't say on others position until you are their shadow. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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-sending-e-mail-naked-facebook-finds/ I think that answers your concern about SMTP transport in the clear Yes, great, we're now moving towards strict and PFS encrypted transport. That's not much of a complete achievement since it does not solve any of the other snowden-ish issues recent p2p threads are meant to encompass... - [secret/trollish/illegal] orders against centralized mail servers/services to store and disclose all metadata and [unencrypted] content, including transport headers and pesky to/from/subject/etc headers. pesky to/from/subject/etc headers. Those are hidden by use of TLS. Regarding government wanting your data in the clear by requesting it to the ISP you use, well switch your communications to another country, problem solved. - voluntary 'cooperation' to do the same. - capability for messaging over encrypted anonymous p2p overlay networks so that the only real place left to compel is the investigated user themselves (or millions of users if you want to fight up against free speech / privacy). p2p is no panacea, it doesn't scale and it will never, ever be able to handle the latest netflixy app Joes are so much into. p2p is for techead kids like you, not for the masses. The masses do not understand it unless it brings spiderman, batman, faggotman hollywood garbage faster to their living rooms. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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. 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 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. and it will never, ever be able to handle the latest netflixy app Joes are so much into. p2p is for techead kids like you, not for the masses. We are talking messaging, not bulk data. However, once you have the nodes scalable to millions of communicators, there is probably no issue transporting bulk data among a select few along their path metrics. Cathal brings up a great and tricky issue regarding choices to store-and-forward. SF 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 :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Fri, May 9, 2014 at 11:49 AM, rysiek rys...@hackerspace.pl wrote: Dnia wtorek, 22 kwietnia 2014 20:58:50 tpb-cry...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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=Gmailct=aes256pa=dotcomht=sha512xt=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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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=Gmailct=aes256pa=dotcomht=sha512xt=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? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Tue, Dec 24, 2013 at 5:09 AM, danimoth danim...@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 ~1 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)? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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 grarp...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
Anyone looked at BitMail p2p ? http://sourceforge.net/projects/bitmail/?source=directory 2013/12/24 grarpamp grarp...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Wed, Dec 25, 2013 at 7:19 AM, Randolph rdohm...@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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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 grarp...@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@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 i...@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
Re: [cryptography] The next gen P2P secure email solution
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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
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 ~1 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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Tue, Dec 24, 2013 at 5:09 AM, danimoth danim...@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 ~1 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.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Tue, Dec 24, 2013 at 5:03 AM, Natanael natanae...@gmail.com wrote: Somebody in there mentioned allowing IPv6 addressing on top of I2P/Tor. That would be Garlicat/Onioncat. It creates a local virtual IPv6 network interface for your software to use, so that you can map key based addresses to routable local addresses. https://www.onioncat.org/about-onioncat/ It is worth noting that Phantom does this natively without needing an overlay on top of another net. It may also use disk to cache some network information, at least their whitepaper says they are 'for' making that choice. Perhaps it can be scaled? https://code.google.com/p/phantom ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The next gen P2P secure email solution
On Tue, Dec 24, 2013 at 5:01 AM, danimoth danim...@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. 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: From - As with today, this may or may not end up being authenticateable by the recipient. Since the net itself would seem to need to be anonymous, then it is likely not. Nor is it a problem if it is... you just generate yourself a new node if concerned. To, Cc, Bcc Date Subject Message-ID [Threading] Body Antispam/antivirus becomes responsibility of the sender/recipient so no headers there. No legacy dkim, spf, etc, either. There may be a new set of transport preference headers if the design calls for it. ie: You might be able to use the net with full mail clients like mutt, thunderbird. Or with a light 'messaging' client protocol. Each of which might have a slightly different interface into and out of the node. Addresses might look like: [user/function or protocol/arbitrary string]@[node pubkey/hash] I've no idea, only to see if interested people think some sort of nextgen P2P/DHT system is actually possible at scale. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
