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
--
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].
