str4d, great news! You must have a great community following since the crypto mainstream keeps disregarding I2P quite a bit, me included. I still haven't made my mind up if garlic routing is a valid strategy, but all strategies are being heavily questioned these days, and there's also always people who criticize code quality.. but people used to criticize my code for having too many #ifdef's, so I can imagine how superficial such criticism can be. In any case I2P Bote does end-to-end crypto plus hiding the traces of conversation also avoiding central honey pots of store and forward, so in theory that qualifies it as a better solution than any other in the race.
On Mon, Nov 17, 2014 at 10:37:40AM -0500, Nathan of Guardian wrote: > While I understand where you are coming from, and acknowledge the > limitations in protocols like XMPP. I am also very excited about the > extremely important work on next-generation systems and protocols like > Pond, Secushare, and the like. I was very happy to see TheGrugq's port Actually I come from Bitnet Relay and IRC.. then I had this idea of making a federated chat system since I couldn't stand the oligarchy implied in the architecture of IRC. PSYC was doing a great job at that, ever since 1997, but unfortunately I was too perfectionistic to open source it, so Jabber suddenly slashdotted out of nowhere. PSYC turned out to be a great business however - whenever clients needed a chat system that actually scales. Around 2008 my co-devs started ranting at the hopelessness in trying to architect a properly safe use of X.509 with federation. We thought of certificate pinning, which led to the side project that implements certificate pinning for Firefox, but ultimately overthrew the entire federation architecture after understanding that things like GNUnet, I2P, Retroshare and Tor actually work and remove the necessity for insecure and administration-intensive servers. The advent of virtualization ultimately killed off any hope concerning the safety of servers: VPS are cheap and insecure as hell, and you never know if your high security conversation partner is corrupted because she has her account on one of those cheap VPS. So, that is where I'm coming from. I've been THROUGH all that. I have thrown away a piece of software I invested ten years in, because the architecture is wrong: it is designed to run on servers. I have the impression some people would rather not swallow the bitter pill that what they have been doing the past ten years has been obsoleted by technology - and that sort of thinking is keeping many of us from moving forward. From my analysis of current technology I must conclude that working for federation today equals working against the benefit for humanity, because it isn't even a reasonable in-between step. It's just plain wrong. > of Pond to Android, and with the years work on systems like Briar coming > to fruition, I do think we are about to take a big step forward on > protecting mobile metadata. grugq's mobile Pond is also great news, although as usual people will be too lazy to set up their own servers, thus they will end up on honey pot servers which make de-anonymization by traffic shaping a lot easier. So from my current analysis Pond scores second to I2P Bote, but my evaluation may be too simple considering all the other things Pond does (I recommend ioerror's video presentation on http://youbroketheinternet.org to learn about Pond properly). Yes, Briar is a neat design that we should support. It has an opportunistic distribution strategy like Retroshare, but for smallish working groups that is perfectly sufficient. The way it does not strictly depend on the Internet is epic. With Briar a group of kids in a classroom has a better chance of forming a constitutionally protected political opposition group than, for example, the members of this mailing list. I bow to Briar for contributing to democracy, although I frequently disagree with Mike's views on current priorities. ;) > The EFF was focused on helping mass market users they can reach with > taking the first step up from insecure SMS and messaging that offers > basically no defense at all from a variety of bad actors. They need to > offer apps available today that a had a history of being maintained and > updated (Moxie, Nadim and I have been at this awhile now), and could > offer good user experiences to even novice users. I also know this is > only the first step in a process for EFF, and that I hope they will be > open to feedback such as you have provided. I can only hope that these "mass market users" will be willing to move on to safer technologies as they become available, not get stuck for all times on something that was given to them as Snowden compliant. By referring to Ed, the website kind of makes that claim, while it completely ignores THE Snowden HOPE-X criterion: metadata protection. Somebody please fix that. Somebody please admit how metadata is a huge problem that those tools aren't fixing. ChatSecure at least tries it in several ways (see below), although the 0.0.11 version I have doesn't show any of those. In theory encryption is better than nothing, but if metadata is the actual meat of the conversation rather then the love and kisses inside, and if encryption keeps people from solving the metadata problem, then encryption is doing harm in detracting atention from the main issue. I have mixed feelings about IAB focusing on encryption but ignoring metadata, which is completely in accordance with what government agencies want us to do. They want us to only do encryption. But leaving metadata unattended is a threat to the stability of democracy. It may sound radical, but maybe EFF would do humanity a better job if that web page was empty and there was only a download button for I2P Bote. Then instead of asking all companies to audit their irrelevant proprietary play things, get them to audit the only properly distributed messaging system we seem to be having for mobile platforms. > I would like to point out some particular features of ChatSecure that do > combat and minimize metadata-based surveillance. I think Cryptocat, by > its transient nature, also has some of these characteristics. You might > dismiss them as band-aids, but we see them as practical defense-based on > what is available today. Oh yes, I am notable for dismissing band-aids, but I understand the motivation. > 1) One-tap use of Tor, which both means the ability to circumvent > network surveillance by our WISP/Telco, and the ability to connect to > Tor Hidden Service hosted XMPP servers. This is why EFF mentioned > "ChatSecure + Orbot" Yes, that is great stuff... I understand we all didn't fully realize that just because a popular server has a hidden service address it is still very de-anonymizable and that by traffic shaping the return traffic (once you get reasonably close to where the server is hosted) I presume you can also de-anonymize the users of such popular servers. If you do traffic shaping long enough, you should be able to figure out who is talking to whom, so metadata is slowly dismantled. Still, it is a lot more effort than doing encryption only, so this is a great step forward from regular TLS/PGP. But I2P Bote has a distributed architecture for the store & forward, so it is IMHO less susceptible to de-anonymization and metadata reconstruction. Last year, when getting funding from the Wau Holland foundation, we joked that one of the aims would be to get secushare to the point that we can stop having to finance and operate jabber.ccc.de because we would tell the users to migrate to a more secure platform. Unfortunately we need more attention to get there. > 2) Support for multiple accounts and in-app creation of accounts on any > server you choose, over Tor if you choose, and offer a built-in list of > geographically diverse, vetted XMPP hosts. Maintaining multiple Multiple identities still do not cut it if the client logs them all in in the same instant. It's easy for an observer to deduce that they all belong to the same person if the same pattern is observed each day, day-in day-out. Clients would at least need to employ random delays. Also you should probably influence Orbot to use seperate circuits even when all accounts are on the same server. > identities is meant to be easy to. This also means anyone can run a > server based on open-source/free software, and using our Lil' Debi (our > Debian-on-Android system), a more experienced user can run an XMPP > server on a phone or tablet inside a Hidden Service. Good, that is an architecture that avoids large popular servers. This is almost like TorChat or Retroshare+Tor, but having an entire server platform is actually much more complicated. Dedicated software designed to deal with P2P interaction is simpler to deploy than re-architecting federation for P2P use. It's also slicker and cleaner as it gets rid of all the legacy DNS and X.509 code. The only problem remaining with this sort of architecture is that hidden services are currently enumerable, so the agencies may routinely start opening circuits to it, just to find out who is running that service. > 3) Support for a secret identity/burner account that generates a > randomly named account on a Tor HS based server (Calyx) that only > supports OTR-encrypted messaging and does not log. This can be used for > communicating with only one contact, ideally using the same app and > method to connect, such that the buddy list only shows one contact. That's pretty neat. Now we need many many such servers and a fix for Tor to not have the agencies figure them out and run traffic shaping attacks on them. If everyone just uses one Calyx, they can routinely use the same analysis software they already developed for jabber.ccc.de. As a side note, if you use a different jabber server, then talk to people on other servers, you are using XMPP federation which is even more likely to expose your metadata than having all your contacts on a central server. But that is why people are making these single contact servers.. a smart idea! The less XMPP you use, the better. > 4) Full encryption of all account data, messages, contacts and shared > media data on the device and no integration with built-in contact lists > on the phone, to stop any leak of data from the ChatSecure environment > into your phones unencrypted/insecure storage. When thinking about > mobile, you must also consider metadata physical extraction, as well as > inherent insecure of the OS services themselves. Ok, that sounds reasonable considering that we are putting sensitive applications in a completely hostile environment. To me the way smartphones function is anti-constitutional anyway, that's why we wrote a proposal to regulate them. In the architecture proposed by the law proposal you would not need to take these extra steps since the device would not legally be a hostile environment. > 5) No requirement for using your actual phone number or device > identifiers, and no integration/dependency upon Google Cloud Services > (push, etc). Yes, that too is inhibited in our law proposal. But for current real life conditions, it is good you wrote ChatSecure this way. Thank you a lot in any case. I appreciate, even if I'm a perfectionist. > > I know very well that they are all experimental, > > but it is irresponsible not to openly say: Sorry people, > > What do you mean by experimental? Whenever I mention Pond, GNUnet, Retroshare or I2P, PGP advocates say that is experimental stuff. I chose not to deny that bit. Still I'd rather use something experimental that may de-anonymize me if it fails, rather than something which isn't anonymous already. It's like saying I'm not using the bike because the chain may break. > > there IS no well established and stable messaging system > > that will actually protect you as it should. All we can > > offer are tools that will protect what you talk about, > > not you as a person. > > Yes, I agree that is generally true, but I do hope that you appreciate > the work we've done in minimizing metadata leakage. Yes, thank you for the effort spent. I know it must be a very Sisyphussian sensation when you work on something as advanced as Calyx and then find out that it is still de-anonymizable because it is still too much thinking in client/server terms. I must say that I feel better not trying to work on low-hanging fruit. Each time you try, you find out that the fruit isn't so low after all, and once you're done you find out the threat scenario has already become worse. Chasing low-hanging fruit is a race we can't win. We must all focus on doing the best imaginable architecture - no shortcuts, no cheap tricks, no band-aids. Only then we have a chance of winning the race. MHO. And, ironically, we have never been so close at actually being able to deploy a "GNU Internet" as some of us call it. I believe doing the right thing is the lower hanging fruit than band-aiding the broken Internet. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
