Rewrote the paragraphs on public-key routing, added several projects and improved the overall accuracy of assertions

[symlynX]

No description provided.

[elijh]

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, by 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 (scramble is one example where originally the idea was public key identifiers in a non-p2p system, but it has been dropped, afaik).
• 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.

[symlynX]

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.

[symlynX]

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.

[symlynX]

... even if all your computers and devices get stolen on a single day, as long as you have a QR print out of your private master key hidden in your attic or buried in grandma's garden, public-key based routing software could be engineered in such a way that it can recover your identity, subscriptions, configuration, social graph and even a relevant slice of communication history from the nodes you have been interacting with. And it's even safe from tampering. This is so much ahead of what SMTP/IMAP can offer.

[elijh]

To achieve perfect forward secrecy only the first exchange between any two partners needs to be processed

This is not a minor detail! Such behavior is fundamentally different than how email-like communication normally works. Protocols like Axolotl (pond & textsecure) have to jump through a lot of hoops to get asynchronous forward secrecy that does not require an initial online negotiation.

[elijh]

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.

For historical capture, I think most people would rather trust the symmetric encryption using relatively very long ephemeral keys of a PFS ratchet rather than trust the dubious longevity of public key cryptography, particularly RSA.

[elijh]

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... So where exactly would the more susceptability be?

Because key availability is a subset of data availability. P2P networks spend a lot of time and resources on the data availability problem, but the performance, speed, and reliability still lags behind centralized and federated systems. This is just one of those natural trade off. With existing technology, P2P systems have many many advantages, but data availability is not one of them.

[elijh]

The difference between P2P and federation is only semantic, is that what you say?

Nope, I said the difference, in the problem space of messaging, between P2P messaging and public-key routed messaging is semantic, since there are not yet any P2P messaging projects that don't use public key routing.

(except for http://twister.net.co, which is not email-like. it uses namecoin-like blockchain to hand out handles)

[elijh]

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 am not sure what report you are reading, but clearly everything in the report is an experiment. All the projects are doing new things, either new things with OpenPGP or new things without. My only point was that you got upset I didn't mention things like key exchange via QR code in a section where I didn't mention any method of key exchange that the projects are trying, including the method that I designed. Yes, QR codes, etc deserve mention, but you can't get mad at me for excluding them from a section where I also exclude all other such methods.

[elijh]

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.

Any objective reader would find many of your changes to be trolling by pull-request. I read through every single change you proposed, and I didn't find any that seemed appropriate.

[symlynX]

Axolotl's ratchets are an improvement over regular DHE, you can and should apply it to synchronous exchanges as well. And they are optional. You can do asynchronous forward secrecy without advancing a ratchet at each round. Yes, I prefer DHE too, but it's not generally proof against future cracking as you suggest in your document. The problem with your world view of P2P is that many of those tools NO LONGER DO P2P. They have relay nodes and supernodes in the backbone of the Internet which do not have the problems you list and which do have the capability of offering data availability, or they take care of running the hashtables or blockchains so the load on the "client" nodes is reduced. So you are talking from a point of view which is at least ten years old. And merely repeating what you said before, while ignoring what I say, will not make it better. Yes, P2P that doesn't do public-key routing exists, but what's much more important, there is a lot of public-key routing that does NOT use P2P! Just look at Tor - how many relay nodes are still running behind a DSL router? I can't get mad at you for excluding QR codes? Of course I can if they are the proof that you are wrong about "ALL PROJECTS DOING TOFU." That is just complete humbug. Just because LEAP is dependent on TOFU doesn't mean that more advanced tools have to be: QR codes provide strong authentication from the very start. So does the bluetooth handshake. Also the social adoption is a lot safer practice than TOFU. But all your key validation paragraph talks about is TOFU, a technique that should by all means be discontinued! How can you expect me not to get mad at you for promoting such bad medicine? Any objective reader will find very useful information on https://github.com/symlynX/secure-email that she won't find on your version for reasons that only you can explain.

[elijh]

Axolotl's ratchets are an improvement over regular DHE, you can and should apply it to synchronous exchanges as well. And they are optional. You can do asynchronous forward secrecy without advancing a ratchet at each round

The fundamental misunderstand that you have is that the document section "common" problems was written originally as a place to simply define the problem, not to go into any detail as to what the possible solutions are. So yes, the section on asynchronous forward secrecy does not discuss the varied approaches to solving the problem because the problem is not "solved" and these solutions are still evolving, even and especially axolotl.

Some discussion of "solutions" have crept into the "problems" section, so for completeness I have added a sentence to briefly mention the possible strategies.

[elijh]

Yes, I prefer DHE too, but it's not generally proof against future cracking as you suggest in your document

I would never claim it is. Many people, including cryptographers much smarter than I, have read the document and not come away feeling like this is the claim, but I have slightly modified the text to make this more clear.

[elijh]

The problem with your world view of P2P is that many of those tools NO LONGER DO P2P. They have relay nodes and supernodes in the backbone of the Internet which do not have the problems you list and which do have the capability of offering data availability, or they take care of running the hashtables or blockchains so the load on the "client" nodes is reduced. So you are talking from a point of view which is at least ten years old. And merely repeating what you said before, while ignoring what I say, will not make it better.

Yes, of course, modern P2P uses a power law distribution, but this is no magic bullet. First, it is a clear attempt to fix the problems which I identify as endemic to the model, so it is valid to note this challenge. Second, supernodes introduce their own problems and are no magic bullet.

[elijh]

Yes, P2P that doesn't do public-key routing exists, but what's much more important, there is a lot of public-key routing that does NOT use P2P! Just look at Tor - how many relay nodes are still running behind a DSL router?

If you read what I wrote, the domain space we are dealing with here is clearly limited to messaging, not applications like Tor.

[elijh]

I can't get mad at you for excluding QR codes? Of course I can if they are the proof that you are wrong about "ALL PROJECTS DOING TOFU." That is just complete humbug.

Aha! At last, we have found something where you have a reasonable ground to criticize the document. Yes, it is an exaggeration to say that all projects are doing TOFU. When I wrote that, it was true, but now many more projects have been added.

[elijh]

Just because LEAP is dependent on TOFU doesn't mean that more advanced tools have to be

LEAP's design is to only use TOFU as a temporary stopgap when communicating with legacy systems, nothing more. I disapprove of TOFU more than anyone I know.

[elijh]

I can't get mad at you for excluding QR codes? Of course I can if they are the proof that you are wrong about "ALL PROJECTS DOING TOFU." That is just complete humbug.
Aha! At last, we have found something where you have a reasonable ground to criticize the document.

It turns out the wording is "Nearly every project here uses Trust On First Use (TOFU) in one way or another". This is very different than "all projects doing tofu" as you claimed.

[elijh]

I will leave this pull request open in case anyone else wants to join the flame war.

[symlynX]

So you decide that ratcheting that a bunch of applications have been using for a while is not an existing solution, with available code and everything? So you insist on telling the old legend, that ephemerals only function over synchronous connections? Who gives you the right to tell incorrect things to your audience?

Congratulations for the "slight modification" but "Without forward secrecy, an attacker is more likely to be able to capture messages today and simply wait for computers to become powerful enough to crack the encryption by brute force." Hmm, forward secrecy makes no difference on the capability of the attacker to capture messages. So it is still incorrect.

"Second, supernodes introduce their own problems and are no magic bullet." I remember Skype functioning because of them. I see Tor having taking a leap in performance thanks to running the relays in the Internet backbone. And the most obvious thing about all of this: if there are nodes in the backbone and no direct connections between people, it is NOT P2P. You are insisting on providing false information. Where is the evidence to assert that supernodes would be in any way more problematic than federated server architectures? So far the opposite seems to be the case. If you look at the concrete cases. Since those relays have a very similar role as your federated servers, the major difference being that they are better at respecting privacy and more efficient at distributing load, you are being opinionated rather than scientific. Does your sensation of that architecture being more complex stem from your limitations in understanding it? There is no magic involved ANYWHERE.

Tor is NOT AN APPLICATION. Tor is a routing infrastructure. It happens to have exit nodes as its main application, but Pond and Cables are great examples of mail systems that run on Tor. Also Retroshare works on Tor. And Tor is only the most popular of routing infrastructures out there. You are stuck in a romantic old-fashioned thinking of what P2P used to be.

Yes, "Nearly every project here uses Trust On First Use (TOFU) in one way or another" is what you wrote and I summarized a bit. Still NONE of the public-key routed alternatives use TOFU (at least not intentionally) and if you do not ignore half of them you'll notice that they make up half of the document. So the thing you say is really very inaccurate and distracting from the fact that there are real world solutions to the discovery and validation problem. Your text suggests a helplessness in the encryption community which isn't appropriate.

[symlynX]

Saw your latest edit adding "Several of the email-like P2P approaches rely on a P2P network for data availability." I'm glad you're trying to improve your version of the document, but it is still inaccurate to call those relay nodes "P2P network." I also saw that you cherry-picked some of my edits manually, thus avoiding to credit them to me... ;-)

[kalikaneko]

🍿