oxen-io / libsession-util Goto Github PK

Our list of group encryption keys won't be entirely encrypted: anyone will be able to read that it is a list of encrypted keys (but inside that each key is encrypted).

This leaks the group size. We can fix it easily, though, by appending dummy values to pad it out to the nearest increment of some multiple (maybe 64; will need to think about the final sizes) so that it doesn't directly leak the group size.

For group messages we need encrypted messages to decrypt to something (probably a new protobuf type?) that contains sender, signature, and content, where content is encoded Content protobuf, sender is a Session ID, and signature is an XEd25519 signature*.

(* sort of -- official XEd25519 has a reliance on a random value to make the signature, but since we have full ed keys we can make that EdDSA-style deterministic and do a negation, if necessary, so that we can always verify with the positive of the two possible X->Ed pubkeys).

I'm investigating property-based testing for Oxen projects, I think libsession-util is a good start, and session::bt::merge is a good toy study case.

To use property-based testing, the first step is to define data generators, the second step is to define properties.

I implemented a toy data generator for a simplified version of bt_value type, next step is to integrate it into the rest of the code.

Once I have some working prototypes I'll create a draft PR for discussion.

In the meantime comments and feedback are appreciated!

Add a tag to config messages so that we can identify the message type before parsing, and skip wrong/future types.

Change the merge API so that we take pairs of hash => data, then make any stale hashes available in some call after the merge so that Session clients can retrieve them and remove them from the server.

It's unclear why the lib is called libsession-util instead of, for example, libsession. Will this be used for everything but client-specific features (e.g., business logic, UI, persistence, etc.) in Session clients, or is this library only a collection of utilities that are useful for building Session clients but not enough (i.e., you will still need to write custom code for handling the cryptography)?

While the answers to those questions would be satisfying for me, it'd be better to add a short description of what the library is/will be in the README. I do understand that it's still in active development, and this will probably be clarified in the future, but it could be helpful for potential future users of the lib (i.e., if this will eventually cover all aspects of the Session protocol, I can already integrate it into a Session Dart package I'm working, figure out the API, make it more idiomatic for Dart, instead of re-implementing everything from ground-up (my original idea)) :)

In the current new groups (AKA closed groups) redesign, admins of a group generate a signing subaccount for non-admin members and provide them a signature that they can pass along to the swarm to authenticate; effectively the admin delegates permissions to the user.

@venezuela01 brought up a useful point: this would still allow someone with possession of many storage servers to perform some (limited) social graph construction by observing all the subaccount logins, since a swarm member could perform the same pubkey blinding that admins would be performing.

This is, however, relatively easy to solve: groups can have a "blinding seed" that gets stored in the group's published, encrypted metadata -- a random value that gets used in the calculation of subaccounts, but that is only ever visible to members of the group itself. Then when generating a subaccount, the admin can incorporate this seed into the blinding procedure. From a user's perspective, subaccounts would still work the same way, but since this seed isn't public knowledge, it would break the ability to link accounts to groups by anyone not already in the group.

This is a question for @jagerman .

By default, we have lag=5. However, if there are broken clients or upgraded clients with a different lag value, what will happen?

Will clients with different lag values never converge or are they still guaranteed to converge?

Just a function returning a string exposed from the library so we can print on the app startup which version of the library we are running (and include it in the logs if we ever run into an issue)

From the comment in PR #5: remove_key is comparing _keys[0] but should be comparing key.

Right now Session can struggle a bit with dynamically calculating unblinded IDs*, but libsession-util ought to be able to computing the blindings of known contacts quite easily and maintain either a semi-persistent (calculated on startup) or fully persistent (dumped to DB) cache of them to provide fast looking to Session clients.

* - specifically, to figure out if a given blinded ID maps to a known contact. You can't go blinded -> session ID, but given all your known session IDs, you can go from them to their blinded versions for each server pubkey and see if anything matches.