Fully encrypted social network theory

Question

I have this idea about building a social network that stores all its data encrypted. The idea is that a member's data is stored on multiple 'base servers' (of the member's choice). Each member has 3 datasets and 3 encryptionkeys.

• keyP for his own private data and settings
• keyF for his profile (posts, photos, friendlist), he gives this key to all his friends
• keyA for his public info (name, city, etc.), also given to friends. Friends can share this one with their friends (this allows people to find friends of friends)

A friendlist would contain the ID, serverlocation and keyA of all your friends.

Members can switch baseservers whenever they want to. When they do, their encrypted data will be completely removed from the server. When a baseserver is added the encrypted data will be copied to the new server and that location will be sent to all friends so they know where to find him. If a member wants to 'remove himself' from the only server he has left there should be some extra confirmation.

I've added a rough sequencediagram to give a visual impression what it could look like.

Question: Do you think this concept is realizable without big performance issues and do you think the security can be maintained?

Update: maybe "Social network" is not really a proper name for it, I want it to be a platform with a security-first mentality and try to outsmart even NSA-like organizations from decrypting the data (which would require to be very careful with the keys instead of sharing it with all your friends).

Answer 1

A first generic comment is that when you give a key to a friend, there is no way you can prevent that "friend" from sending the same key to other people, or blabbering about your semi-private information. In that sense, encryption cannot make a useful distinction between "keyF" and "keyA". In a security setting, there are only two categories of information: that which you do not tell to anybody, and that which you tell to at least one person. Since it would be quite pointless to upload the former on any server, we could say that there is, in a social network, only one kind of information, meant to be shared. And you cannot really control how far some data is shared.

This is not new. Propagation of secrets through gossip is a well-known phenomenon and is probably as old as language itself.

However you may try to work in a setup where friends are "trusted", i.e. they will keep secrets (I strongly doubt this scenario is practical if the set of friends includes more than three people, but hey, one can always hope). In that case, you may indeed share data by revealing to these select few the key which encrypted the data. This then calls for a second important comment: you cannot enforce forgetfulness.

This means that if you want to "remove" a friend, then you cannot make him "forget" the key which was previously shared. The only method is to create a new key, share it with your remaining friends, and thereafter encrypt your data with the new key only. This implies that removing people from your set of friends implies distribution overheads proportional to the number of remaining friends. This may cause scalability issues.

---

It is somewhat unclear what you are trying to protect against. Server operators ? Search engines ? Your friends ? Maybe traffic analysis (i.e. reconstruction of the friendship graph) ? This should be defined with great precision. Appropriateness of any algorithm of protocol can be analysed only if we know what kind of security property we want to achieve.

I still urge you to consider the generic comments above. They can be summed up as: data propagation is hard to control. It makes things simpler to think about social networks as repositories for public data: everything you write on such a network may become public or close enough.

Answer 2

The security is only as effective as your trust in your friends to not share it. Distributed systems like this have been thought up before, but adoption is a challenge. You actually really want the information to be replicated across multiple servers so that you have redundancy and can track a graph of where it is.

Another alternative idea is that you can give each user a public/private key pair. You can then categorically associated data keys with any data elements you want to group permissions for.

You can create groups of friends by creating a public/private key pair for that group and encrypting the private key with the public key of each member of the group. You can then encrypt the data key for any information you want to share with the public key of either a group or a set of friends that you want to give access.

You can also either decide to trust the server to handle key management or the end user. If you are willing to trust the server, you can protect the keys so that users never gain access to the group private key or the data element keys, thus they can't share it to additional people, this requires trusting that the server won't misbehave while running though. (Offline attacks are still protected since the server never has the information needed to use the private key of any user offline.)

If you do it locally on the other hand, the private keys and data keys become available to anyone with access and can not be revoked without re-encrypting everything someone had access to every time you want to remove their access (which would be potentially expensive.) You would then re-encrypt the new data key or group key pair for everyone who still should have access.

Answer 3

Take a look at this:
https://joindiaspora.com/
https://github.com/diaspora/diaspora

Diaspora uses public and private keys to encrypt the content and communication. It is also decentralized.

You don't have to reinvent the wheel ;P