Group keys and replication

Two ports

This page is about one kind of key: the content key a group encrypts its shared space with, held by every member’s device and replaced whenever the membership changes. A person’s own keys, the seed, the anchors per context and the device keys, are the Identity layer’s and are explained in Foundations.

A group has two kinds of truth. Who belongs and what is allowed is decided by the authority logAutoritätslog Der nur anwachsende Operations-DAG, der in der Genesis-Operation wurzelt; die einzige Quelle des Berechtigungszustands. GlossarAuthority log The append-only operation DAG rooted in the genesis operation; the sole source of authorization state. Glossary: every device replays the same signed entries and arrives at the same answer. What the content is encrypted with is produced by the key portSchlüssel-Port Die Schnittstelle, über die ein registrierter Adapter Epochengeheimnisse erzeugt, die die Invarianten KV1 bis KV6 erfüllen. GlossarKey port The interface through which a registered adapter produces epoch secrets satisfying the invariants KV1 to KV6. Glossary: a procedure that turns the current membership into a secret only members hold.

The protocol keeps the two apart. The authority side is the protocol’s own and the same for every group. The key side is a port with six invariants, and a group picks a registered adapterAdapter Eine registrierte Bindung eines Schlüsselvereinbarungsverfahrens an den Schlüssel-Port. GlossarAdapter A registered binding of one key-agreement procedure to the key port. Glossary to fill it. Whatever the adapter does, the log decides and the keys follow: when the log says someone is out, the adapter owes a key that person cannot derive.

Spec: Access Layer §9.1 · §9.2

Key states, not epoch numbers

Every removal, rotation or rule change starts a new key state. A key state is named by the entry that created it, not by a counter, because two members who act at the same time both create one, and the group must be able to tell them apart afterwards. Each new state says which states it succeeds, so the history of keys is a small graph that grows with the log.

Where two states meet, the adapter brings them together into one, either by merging their secrets or by a fresh rotation that heals the split. Until it has, members keep reading and writing waits; one member is designated to issue the rotation, so the wait is short. The epochEpoche Ein nummerierter Abschnitt der Schlüsselwelt der Gruppe; Durchsetzung wirkt als Epochenübergang. Begriff wie in MLS (RFC 9420). GlossarEpoch A numbered period of the group’s key world; enforcement takes effect as epoch transitions. Term aligned with MLS (RFC 9420). Glossary number still exists, but only as a counter for views and ordering.

Spec: Access Layer §7.1 · §9.2

Reading back

A member holding the current key can read the group’s history as far back as the adapter’s chain reaches. Under the first adapter each new state carries the previous key sealed under the new one, so a newcomer unlocks the past step by step from the group’s own copy. History is never narrowed: a welcomeWillkommen Das versiegelte Dokument rltp-welcome/0.1, das einer aufgenommenen Person das Schlüsselmaterial eines Schlüsselzustands bringt, gebunden an Gruppe, Person und die beantwortete Annahme. Die aufnehmende Operation verpflichtet sich über den Digest auf seinen Klartext; Geschichte trägt es nicht. GlossarWelcome The sealed rltp-welcome/0.1 document that carries the key material of one key state to an admitted person, bound to the group, the person and the accept it answers. The admitting operation commits to its plaintext by digest; it carries no history. Glossary brings one key, the replica brings the rest.

A group that opens its content to the world publishes its keys from that moment on. Opening older content is a separate, recorded decision, and it always opens from the beginning, because a key opens everything its chain reaches.

Spec: Access Layer §8 · §9.4.1

Two adapters

linear/0.1 is the procedure in use today: one content key per state, delivered to each device individually, healed by rotation when states merge. It is simple and costs one message per device per change.

beekem/0.1 is experimental: a key tree in the style of MLS and Keyhive, where a change costs a path through the tree instead of a message per device. It is registered so that implementations can try it against the same log and the same invariants; the parts that are not settled are listed as open issues.

Spec: Access Layer §9.4

What the replication service may know

Members are rarely online at the same time, so a group may register a replication serviceDienst Eine Partei, die die Einträge einer Gruppe speichert und weiterleitet, ohne ihre Schlüssel zu halten; ihre Klasse (blind, view, log) ist die registrierte Aussage darüber, was sie von der Gruppe weiß. GlossarService A party that stores and forwards a group's items without holding its keys; its class (blind, view, log) is the registered statement of what it knows of the group. Glossary: a party that stores its encrypted entries and hands them to whichever member connects next. The service holds no keys. What it knows beyond the ciphertext is the group’s choice, stated at registration in one of three classesDienstklasse Die bei der Registrierung erklärte Aussage, was ein Dienst von einer Gruppe weiß: blind (nur Chiffrat), view (auch Berechtigungssichten) oder log (auch das Autoritäts-Log). Die Wahl trifft die Gruppe. GlossarService class The statement, declared at registration, of what a service knows of a group: blind (ciphertext only), view (also authorization views) or log (also the authority log). The group chooses. Glossary:

Class	Knows	Can do
blind	ciphertext and addresses	store and hand on, nothing else
view	also which devices a signed viewBerechtigungssicht Das verkettete, per Quorum signierte Objekt, durch das ein Dienst der Klasse view die Epoche und die berechtigten Geräte-Identitäten einer Gruppe erfährt. GlossarAuthorization view The chained, quorum-signed object by which a service of class view learns a group’s epoch and authorized device identities. Glossary lists	refuse content from devices the view does not list
log	also the authority log itself	check every entry on its own

Four rules hold for every class. A service never blocks an entry of the authority log, whoever wrote it. It rejects nothing silently: a refusal is visible and the sender can try again. A member who was removed still receives the notice that says so. And a service declares how much it will take in, so nobody is surprised by a limit.

A view is signed by a quorum of the previous view, so a service cannot be talked into a new membership by the newcomers alone. The group pays for the view class with one known residual: if an honest group shrinks below its own quorum, the service freezes until the group registers it again. A service of class log reads the removals itself and has no such freeze.

Spec: Access Layer §9.3 · §7.3

Getting in, and getting back in

Keys travel in three situations, and each has its own path.

A newcomer receives a welcome sealed to the key in their acceptanceAnnahme Die signierte Zustimmung der eingeladenen Person zu genau einer Einladung, an sie gebunden über deren Credential-Digest. Sie trägt die eigene Karte der Person, an deren Schlüsselvereinbarungsschlüssel das Willkommen versiegelt wird, und sagt, ob die Person der Gruppe vor der Aufnahme als Kandidatur gezeigt werden darf. GlossarAccept The invitee's signed consent to exactly one invite, bound to it by the invite's credential digest. It carries the person's own card, to whose key-agreement key the welcome is sealed, and states whether the person may be shown to the group as a candidacy before admission. Glossary, together with the entry that admits them. They keep it provisionally, fetch the log, and become a member once the log confirms the admission. If the welcome never arrives or turns out wrong, they ask again, naming their own acceptance; a fabricated admission in a bad welcome cannot send them down a dead end.

A second phone is bound by the person’s first phone with a signed device cardGerätekarte Die signierte Bindung des Schlüsselmaterials eines Geräts an den Mitgliedsanker der Person, der es gehört; steht im Autoritäts-Log. GlossarDevice card The signed binding of one device's key material to the member anchor of the person it belongs to; recorded in the authority log. Glossary in the log, and receives material sealed to its own key. If the first phone is lost before the second ever synced, the second one bootstraps on its own: it asks any member, keeps the answer provisionally, and the log confirms that the person is a member and the device is bound and not revoked.

A lost phone is revoked by another of the person’s devices, and the group moves to a new key state. If it was the last device, the person binds a new one under the rule that governs revocation; the membership itself was never in question.

Spec: Access Layer §10.1 · §5.1 · Membership Tasks §3.3

What this does not promise

A service of class blind can delay or withhold messages, and nothing in the protocol proves that it did; what it cannot do is change who belongs or read what members write. A person who was removed keeps what they already read. And an adapter that is honest about its invariants is still only as strong as the devices that hold its keys.

Where this comes from

None of this runs in a simulator yet. The two ports, the key states and the service classes were derived in the port experiments: one authority log driven against three existing key-agreement systems and against a service that enforces what it is told, with the scenarios that produced each rule recorded there.