[liberationtech] Overview of projects working on next-generation secure email

[carlo von lynX]

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


-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet