A specification for implementing private groups in scuttlebutt.
The fundamentals of this spec are:
In adition to the envelope-spec, there are some scuttlebutt-specific specifications
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 employingType of id | How key is derived |
scheme |
---|---|---|
private group id | a key-store | "envelope-large-symmetric-group" |
feedId (someone else) | diff-hellman styles | "envelope-id-based-dm-converted-ed25519" |
feedId (yours) | locally stored key | "envelope-symmetric-key-for-self" |
P.O. Box id | diffie-hellman styles | "envelope-id-based-pobox-curve25519" |
see key-schemes.json
for the canonical list of accepted schema labels
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 :
More detail:
A minimal amount of agreement to make coordination easier:
describe
Group IDs have moved from being sigil links like
%g/JTmMEjG4JP2aQAO0LM8tIoRtNkTq07Se6h1qwnQKb=.cloaked
to being SSB URIS like
ssb:identity/group/g_JTmMEjG4JP2aQAO0LM8tIoRtNkTq07Se6h1qwnQKb=
Could modify this spec:
While we have tried our best to create a secure end-to-end encrypted communication protocol, this spec is not fit for use in safety critical situations. The specification has not been vetted by an independent party. Even assuming a bug-free spec, we have intentionally left out several security features that are considered state of the art in other apps such as Signal, such as "forward secrecy".
Because of this, we advise that anyone that implements this spec in an app, includes prominent UI that warns the user about possible risks.
ssb-tribes2