Secure Post Types / End-to-end Encryption
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.
goob Sat 3 May 2014 12:31PM
There's an earlier discussion about encryption of data: https://www.loomio.org/d/KQfdUlox/encryption-in-diaspora
[deactivated account] Sat 3 May 2014 2:05PM
(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.)
Julian Steinwachs Sat 3 May 2014 2:36PM
Rasmus Fuhse Wed 7 May 2014 11:46AM
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.
Jonne Haß Wed 7 May 2014 1:42PM
Rasmus Fuhse Wed 7 May 2014 2:06PM
Usually a hack-attack lasts only for a few minutes and not for weeks. So this attack is theoretically possible but not quite probable.
Julian Steinwachs Fri 9 May 2014 8:28PM
Jonne Haß · Sat 3 May 2014 12:13PM
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.