Private-Groups Spec | v2.0.0
A specification for implementing private groups in scuttlebutt.
The fundamentals of this spec are:
- uses envelope for encryption of content
- has group_ids which are safe to share publicly
- adding people to the group is done with group's knowledge
- supports disclosing of message content
- but this leaks info about the group (peak at other messages / authors)
envelope encryption in scuttlebutt
In adition to the envelope-spec, there are some scuttlebutt-specific specifications
See spec here
recipient key derivation
box1 took feedIds from the content.recps
field and directly used these for encryption.
In envelope, we instead take "ids" from content.recps
, and map each to a key+scheme pair { key, scheme }
where":
key
is the encryption key which will be used in a key_slot
, andscheme
is the "key management scheme" which that key is employing
see key-schemes.json
for the canonical list of accepted schema labels
recipient restrictions
We talk about key_slots
or recipients / recps
a little interchangeably.
Let's assume content.recps
are mapped to key_slots
preserving their order.
:warning: The following restrictions must be followed :
- there are max 16 slots on a message
- if there is a group key
- a) there is only 1 group key
- b) the group key is in the first key_slot
- we disallow you from making a shared DM key with yourself
More detail:
- (1) means all implementations know to look 16 slots deep when trying to unbox the msg_key
- (2.a) provides a guarentee that infomation is not leaked across groups, in particular tangle info would leak info about group memember as these ids are not cloaked in this version
- (2.a + 2.b) means we that we only need to try group keys in the first slot. If that fails, we can try DM keys on slots 1-16. (nice and fast!)
- (3) is a tight restriction which we think will help people write better apps
- it's a step towards forward security
- if you want to send to self, it encourages people to mint a group, which is a better practice when moving to support multi-device identities
- we may relax this restriction when we have more experience
group management
A minimal amount of agreement to make coordination easier:
TODO
describe
- how all these things might be woven together
- where state is tracked off-chain (in a key-store)
changes in v2
Group IDs have moved from being sigil links like
%g/JTmMEjG4JP2aQAO0LM8tIoRtNkTq07Se6h1qwnQKb=.cloaked
to being SSB URIS like
ssb:identity/group/g_JTmMEjG4JP2aQAO0LM8tIoRtNkTq07Se6h1qwnQKb=
scuttlebutt private-groups spec (v3 ?)
Could modify this spec:
-
-
-
- supports privacy fiendly disclosing of message content
- all internal cypherlinks are "cloaked"