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

Mon Apr 28 04:46:04 PDT 2014

-----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
joe at cdt.org
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-----