Loomio
Sat 3 May 2014

Secure Post Types / End-to-end Encryption

JS
Julian Steinwachs Public Seen by 85

Hey all,

I am really glad to see how this project gains traction again. It feels like it is the most/only active of the federated social network projects. Diaspora* helps people stay in control of the technology they are using. There are many reason why diaspora is better than its commercial competitors. However, in terms of data security, communicating through a federated network like Diaspora* is actually worse than a centralised scheme, because you have to trust every server on which you have friends. Most of the servers are inside some cloud infrastructure where it is totally unclear who has access. So i think Diaspora* should offer a way to send end-to-end encrypted posts. That way you would not need to trust any server that is transporting your message. Because end-to-end encryption is always less convenient to set up and to use, it should be optional. I think the best way to implement this would be an extra set of "secure" post types. These are encrypted by the browser of the sender with an extra public key. The private counterpart of this key would not be stored on the recipients server but in the local storage of the recipients browser. The posts would then be decrypted by the browser. The Diaspora* servers would manage the communication of public keys and their revocation. One flaw of this approach is that meta-data (sender and recipient identities) are only encrypted between the servers. This could be circumvented with an onion routing scheme, but probably not in a first iteration.

Greetings

JH

Jonne Haß Sat 3 May 2014

http://www.matasano.com/articles/javascript-cryptography/

Apart from that, I've never seen it as the goal of diaspora* to provide an ultimately secure and private communication channel. Instead the main goal is to reduce commercial exploitation of your data (with or without your consent) to a minimum. For secure and private communication you should resort to proven tools and protocols like PGP/GnuPG. These spit out ASCII text so you can very well use diaspora as a transport for these, but at that point just using your mail account is much more convenient.

G

goob Sat 3 May 2014

There's an earlier discussion about encryption of data: https://www.loomio.org/d/KQfdUlox/encryption-in-diaspora

DU

[deactivated account] Sat 3 May 2014

If you cannot trust your own pod then you also cannot trust any JavaScript crypto stuff provided by the pod. If you want to do crypto with local libraries (by means of a browser extension) and you want to do key management on the pod to make this a little easier you run into the same problem. An untrusted pod cannot be trusted to provide the correct public keys for your contacts.
(I tried simplifying encryption with Libertree under the assumption that the home server could be trusted, but even then the gains were too small.)

End-to-end encryption ultimately means that the user has to take care of key management (not only for private keys but all public keys of contacts) and that encryption has to be perform by trusted libraries offline. You will never get this with a server-based system, and there is nothing that can be done on the server to simplify this in the least as long as browsers have no built-in support for cryptography (see the W3Cs stalled Crypto API).

Even with built-in crypto support you don't gain enough to manage most of the ugly stuff on the pod.

Like @jonnehass I recommend using GPG instead. (With GPG you can also encrypt to multiple recipients -- the message is encrypted with a symmetric key once and the symmetric key is encrypted with each recipient's pubkey.)

JS

Julian Steinwachs Sat 3 May 2014

Ok, i got it. Crypto code in javascript tags is a bad idea. But the Diaspora software can still help to make it easier to use something like PGP. The servers can for example act as key servers and deliver the recipients keys to the webclient. The crypto itself can happen in a browser extension (like https://webpg.org/ ).

RF

Rasmus Fuhse Wed 7 May 2014

If you cannot trust your own pod then you also cannot trust any JavaScript crypto stuff provided by the pod.

I think you're talking about different things: end2end encryption in browsers is not about mistrusting the server. It is a question of timing. When I trust you and your server any my server, I can still not be sure that your or mine server will never be hacked. Probably in a month or so some government or a hacker will require/gain access to the database of a server and receive all contents of my discussions in cleartext. In this case it'd be nice if our servers would have stored the encrypted contents in the database. And this is the case with end2end encryption.

JH

Jonne Haß Wed 7 May 2014

If your server is hacked, the hacker can just modify the Javascript encryption library to sniff any passwords/private keys and send them to the attacker.

RF

Rasmus Fuhse Wed 7 May 2014

Usually a hack-attack lasts only for a few minutes and not for weeks. So this attack is theoretically possible but not quite probable.

JS

Julian Steinwachs Fri 9 May 2014

Until the crypto API (http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/) is not build into browsers the best way would be to built browser extensions. In principle one could write an extension right now that rewires the javascript of the diaspora webapp such that posts are decrypted before displaying and encrypted before sending if the the recipient also has a key published. Because diaspora uses email-like identifiers, the extension could use all normal PGP keyservers. Someone did the same for gmail already: https://chrome.google.com/webstore/detail/mymail-crypt-for-gmail/jcaobjhdnlpmopmjhijplpjhlplfkhba