-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This kind of dispute is exactly what forking is for. It would be nice if you both could come to some good-faith common understanding of the technical issues and build a better document, but it doesn't seem like that's in the cards.
Thanks, either way, for working on this. best, Joe On 4/28/14, 4:49 AM, carlo von lynX wrote: > Hello everyone. You may remember the OpenTechFund asked us to > participate in a survey of "next-generation secure email" projects. > The result of this has materialized on their github including an > open invitation to improve it. I found it following an announcement > tweet. > > Since there were many projects missing and quite some inaccuracies > concerning 1. common problems, 2. those projects that follow a > public-key routing based principle (based on Tor, I2P etc) and 3. > even the cryptography, I forked the thing and took the initiative > to work on that. > > At least I think those were inaccuracies, but I may be terribly > wrong and Elijah may be dramatically right, so I am asking you the > libtech community to comment on our debate: > > > This is what Elijah of LEAP and OpenTechFund says: >> Were I to accept your proposed changes, this report would >> grievously suffer. For example, systems which use public keys as >> identifiers are more susceptible to the problem of key >> synchronization, not less as you claim. Also, systems which rely >> on both parties being online for forward secrecy cannot be >> considered asynchronous, but the very definition of asynchronous. >> I could go on. >> >> You seem to have two primary issues with this report: >> >> - You think it would be more precise to label systems that route >> via public key as "public key routing" rather than >> "peer-to-peer". The difference is merely semantic, because there >> is little motivation for public key routing if you are not also >> building a peer-to-peer system. - You feel I left out the means >> by which people are experimenting with public key discovery for >> systems where the key is the identifier (e.g. QR codes, >> bluetooth, etc.). Well, I also left out any discussion of >> alternative key discovery and validation in the overview section >> and left that for the individual projects. > > This is my reply: >> The assertions you make are not correct. >> >> 1. To achieve perfect forward secrecy only the first exchange >> between any two partners needs to be processed. It's practical if >> they happen to be both online on the first day they meet, but >> even that isn't strictly necessary. Once the first exchange is >> settled, the ephemeral keys stay valid and can even be advanced >> mathematically (ratchet etc). See Pond and Briar for very nice >> examples of this principle. Your current document also contains a >> factual inaccuracy about forward secrecy indicating you have not >> fully understood how it works. "Without forward secrecy, an >> attacker might also be able to capture messages today and simply >> wait for computers to become powerful enough to crack the >> encryption by brute force." <- It is not correct to say that >> forward secrecy protects from brute force, it doesn't. >> >> 2. Key sync is a problem for all. While tools like Briar, >> Retroshare, secushare etc could use shared pubsub channels >> between each instance to sync their "client" state and thus the >> keys of their social graph, using the regular capabilities of >> their respective protocols, traditional mail tools will have to >> come up with a special protocol, possibly on top of IMAP, that >> allows clients to sync that sort of data. So where exactly would >> the more susceptability be? >> >> 3. The difference between P2P and federation is only semantic, is >> that what you say? The difference between federation and >> public-key routing is that instead of THE server there is a vast >> number of relay nodes, instead of letting THE server have insight >> about metadata SOME relays get some jobs to do without really >> knowing what they are about, instead of making THE server an >> ideal point to attack the communications of a certain user, there >> is a vast number of relays that would need to be shut down in >> order to censor a person. Have you looked at the Tor architecture >> anytime recently? It does zero peer-to-peer because there are >> always relays in-between which aren't in anybody's home. They are >> full-fledged high capacity servers in the Internet backbone. You >> think P2P is still P2P, and I am saying P2P is dying and being >> replaced by a non-federation of agnostic routing servers. That's >> why the term "server" is wrong, so we call them relay nodes. >> >> 4. Experiments? Why do you have to present the old-fashioned >> methods related to one specific tool (PGP) as the only ways to do >> key discovery while the problem has tangible solutions that >> absolutely deserve being mentioned and taken seriously? How dare >> you call other people's successes "experiments?" Do they harm >> your world view? Would you prefer the Earth to be flat? >> >> I find it a very inacceptable abuse of your powers to simply >> CLOSE this pull request instead of learning from its contents. I >> was told that you would be appreciative of constructive feedback >> as this one, so I spent about a day and a half to make YOUR >> document actually reflect the scientific facts. And then you >> insist with your antiquated points of view, rejecting how the >> world has evolved since you started making up your mind. >> >> Elaborating on (2): In fact when migrating an identity from one >> mail client to another, you not only need to take your PGP keys >> with you, you also need to migrate user names, server names and >> passwords. With PK-routing systems your private key is all you >> need to identify you - it can give you access to all the data >> related to you. It is only a question of actually coding the >> stuff, it isn't an architectural limitation that has no way >> around it. That's why key sync is easier in PK-routing systems >> than with federated ones. > > My version of the document can be seen at > http://youbroketheinternet.org/secure-email or > https://github.com/symlynX/secure-email > > (I am not a fan of centralized social networks, so I prefer to keep > a copy on our website) > > His version is at https://github.com/OpenTechFund/secure-email > > The discussion happened at > https://github.com/OpenTechFund/secure-email/pull/10 > > The comparison of the two versions is at > https://github.com/symlynX/secure-email/compare/OpenTechFund:master...master > > > - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 [email protected] PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXj98AAoJEF+GaYdAqahxVMoP/3q4fcCqqGNdtdc4/BuUE8sZ PhLh5QThe9oBH84gv6sKrqC+LB1RooROw52gr7GWy/OrE3XIz7DdCn3H8vB06FRc aOQ2o48bn99kDxIUPhkWPlrN2gcRVpAoLIzMUsNYaAorPWiDcEyhGhVuKvfb4B6d Iy2tu+RvZ2Vri0TaIq6Kps0FhentMVBVc+WCccu11t2Ng3Q+SeEFXCX6j78zfSAH BPCvrq5jhyauXhyXYXR3WnocuuLG1N+VcyPo5j0FmWqVXqcD4jL0Mywulsi0EWQz kbM88n5lzYO6Cb5SS2xgr8Ac0IlNvD0zrMRVT0588ZcrliUjTUwC1AQoQ2HigYOB 7JNBhJkwdH643fkvykVJYtAsUdzQM3Fpf4geg1Z1jlWdud2sXqIyEzm/lBLpAqxO buTw2TqfHz3qXx9DC5aqds+dzksN7Tjoy+SiRIDpkXJ6761My1O+eXWmEPmiHImJ W1KUcp3jQ48IGAsl+6VqA0UxN5pxBizstIYj6V7cFFPgDpivXgsZo8ZUJ4SzlPnW Ys9HDFfz2Af8mt5kxN8cf0R7cdY3+tHnCFIejYsL64Nv2xURG40ltFNf5YEhguZS nqphAQE8xWJ/zxGHzdhKS6e+djwTEQr/lwmRUt86b103AulfYN/OFKVltVWIxQD4 iuLIoi5cY6gnd3uP42Ee =uOEy -----END PGP SIGNATURE----- -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
