You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
The group creator preemptively generates a series of blinded seeds, denoted as [s_0, s_1, s_2, ..., s_n], utilizing a deterministic key derivation function. Upon generation, the initial blinded seed (s0) is distributed to all group members, following by the subaccount generation and signing process, as well as informing the group swarm for the 'subaccount signing root pubkey'. In the event that a member opts to leave the group or is removed by the creator, any device associated with the group creator can retrieve exactly the same subsequent blinded seed from the pre-configured list. This device then performs the subaccount generation and signing operations again, distributes the succeeding seed alongside the signed subaccounts to the remaining group members, and instructs the group swarm to abandon the former subaccount signing 'root pubkey' in favor of the newly established subaccount 'root pubkey'. This ensures seamless coordination across all devices linked to the group creator.
In future scenarios where the creator introduces new moderators, an refilled list of blinded seeds, [sk, s_(k+1), ..., s_(n+k)], will be exclusively shared to these moderators. If a moderator decides to remove a group member, they can take the following blinded seed from this list, distribuite it to the surviving group members, redo the subaccount generation and signing operations, instructs the group swarm to abandon the former subaccount signing 'root pubkey' in favor of the newly established subaccount 'root pubkey', on behalf of the group creator.
This procedure closely mirrors the encryption key rotation proposal. The codebase instrumental in the rotation of blinded seeds might be compatible with, and hence shared with, the encryption key rotation framework.
Note: Certain technical details have been skipped for brevity.
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.
The text was updated successfully, but these errors were encountered: