Feature request: Implement groups with encryption

[ghost]

This is probably a far-fetched feature request for some future version, but it would be perfect to have Diaspora*/G+-style groups where one could post encrypted messages that only members of the group can decrypt.

This would probably involve creating/recreating a symmetric key whenever the set of members of a group changes which is then distributed (asymmetrically encrypted) to each member and subsequently encrypting the actual content messages to the group with that key. In my opinion, this would greatly enhance the attractivity of Twister for privacy enthusiasts.

[genjix]

This doesn't require any changes to the protocol, and is an implementation detail - a way for people to share a symmetric key which they can all read/write to (with encrypted posts).

The group creator would encrypt the key for each participant and send it to them. Upon receipt of the key, they will notify the group creator so he knows when everyone's received the key.

[ghost]

That sounds great! Actually, it would probably even suffice to have one-way encryption, i.e. distribute a key to a number of followers and then encrypt messages with that key, so that one can share messages selectively with groups. This was one of the features that got Diaspora* originally some attention.

Of course, this would also require an UI change that filters out encrypted posts for those who cannot decrypt them. If anyone would implement this, I would consider it a killer feature!

[ghost]

Bounty: https://www.bountysource.com/issues/1376796-feature-request-implement-groups-with-encryption

[ghost]

Of course, the initial key distribution mechanism would have to be secure, i.e. the way direct messages are encrypted at the moment.

[iShift]

+1 good feature

[rbertoche]

I don't know it's a good idea to generate a new pair of keys at each user set change. All users must have all old keys, otherwise it will restrict access to old messages to old users - only those who get the first key will read the first message. Is that the idea? Each user having a collection of key-pairs to cover each change in group members? In a long-lived group, won't it cause noticeable overhead?

Maybe each user gets it's own key from the user who invited him (encrypted as a normal PM) and then who joined writes messages with that key. This guy who invited him will use it's own public key to share this new key to other users in that group. All users have a key for each user. That way we can reduce the number of keys to the current number of users inside this group. The drawback is that a user that gets kicked or quits may have a way, with a hacked twisterd, to silently read all new messages, even from new users without getting inside the group again, if they manage to keep all current user's keys.

[ghost]

These are great points to think about!

Just a couple of issues to focus the discussion:

(1) Maybe the term "groups" is misleading. I wanted to propose something like G+'s "circles" and Diaspora*'s "aspects", i.e., a simplified way for one person X to send posts only to some of their followers A,B,C. The members of a circle do not even know that they are in X's "family" or "colleagues" circle, and they consequently cannot add other users to that circle or address posts to that circle. Implementing Facebook-style "groups" is much more complex than that, because it's hard to introduce that into the follow-style model of twister.

(2) When X sets up their "friends" circle, they send A, B, and C each an encrypted private message containing a symmetric encryption key S. A's (lets say) twister client filters such messages out and stores the pair (X,S) in a database.

X can now choose, when composing a post, to share it either "public" or with "friends". In the latter case, the post is marked as encrypted and symmetrically encrypted with S. When A receives an encrypted post from X, A looks up in their database all symmetric keys received from X and tries to decrypt the post with each of them. In case that fails, A assumes that the post was intended for a circle in which A is not a member and ignores the post.

(3) The question about how to deal with additions/deletions from circles is spot on. It seems to me unavoidable to distribute a new key to all circle members whenever one member is deleted from a circle, such as to make subsequent posts inaccessible to that member. It is an open question whether the same should hold for additions, i.e., whether one wants to ensure that people can read posts only from the moment in which they were added or whether additions have retroactive effects. I would prefer the formers since it conforms, I think, to our natural privacy expectations.

This, of course, leads into the problem that the database of shared symmetric keys grows over time (and thus, the time needed to try out all relevant keys on encrypted posts). I don't think space constraints are much of an issue - an AES256 key has only 8 bytes and even combined with a user id, even thousands of keys will not take up much space.

The worse problem is that of runtime: If I have 100 keys stored for a contact and I receive a post intended for a circle in which I am not a member, I will find out only after 100 unsuccessful decryption attempts. Especially on mobile, this will be a problem.

The only solution I can think of is discarding unused keys after a while but thereby losing the ability to decrypt old messages from friends that had not been received before. This can be a bit improved by storing decrypted messages after receiving them on the client either in the cleartext or encrypted with a local (non-shared) key so that one can access them even if the key one had received from the creator of that message is expired and was deleted.

Steps to implement:

• Create a local database on the client to hold user-key pairs
• Implement a way to distribute and receive keys via private message
• Implement UI to create/manage groups and connect that to sending/recreating keys
• Implement automatic decryption and long-term storage of encrypted posts
• Implement private posts with transparent encryption

[Erkan-Yilmaz]

+1 (I am used groups from statusnet / gnu social)

[rysiekpl]

+1 for identica-style groups. Aspects/circles would also be nice, but groups are definitely the feature I miss the most in Twister and Diaspora. it was a huge boon for the community.

[miguelfreitas]

+1

[ghost]

Is this feature now implemented with the new group chat mechanism? From what I read on the google group, it seems as if the answer is yes.

If so, this can be closed and some has earned themselves 10 dollars (https://www.bountysource.com/issues/1376796-feature-request-implement-groups-with-encryption) :-)

[miguelfreitas]

Cool, I didn't even remember this bounty! The feature is not yet usable due to the lack of UI. So i'd propose the bounty should go to whoever implements the missing part :-)