<\/p>\n
GROUP KEY AGREEMENT<\/p>\n
Protecting a conversation between two endpoints is already a stateful protocol. A group adds members who join at different times, use several devices, miss messages and leave while the remaining participants continue.<\/p>\n
Messaging Layer Security organizes that change into cryptographic epochs. Each committed membership update produces a new group state and new key schedule. Members derive the same secrets without sending a separate encrypted key to every participant.<\/p>\n
Removing a member is effective only when the group completes the transition and every remaining client agrees on the new epoch.<\/p>\n
MLS represents group key material in a tree. Each member occupies a leaf and knows private secrets along its direct path. Public values allow updates to be distributed efficiently.<\/p>\n
An update path replaces secrets from one leaf toward the root. Other members use the public information and their own private path secret to derive the new root.<\/p>\n
The work grows logarithmically with group size for common operations rather than requiring one independent pairwise exchange with every member.<\/p>\n
Each epoch commits to the group identifier, ciphersuite, tree, transcript and extensions. Application messages are protected under keys derived for that epoch.<\/p>\n
A client receiving a message from another epoch must apply or retrieve the missing commits before interpreting it. Accepting content under an ambiguous epoch can attach it to the wrong membership state.<\/p>\n
The epoch number is not merely a counter. It names a cryptographic view of who belongs to the group and which parameters they share.<\/p>\n
Add, update and remove proposals describe intended changes. A Commit selects proposals, advances the key schedule and creates the next epoch.<\/p>\n
A displayed administrative action may create a proposal before the group has processed its commit. Until then, the target member may still possess current epoch keys.<\/p>\n
User interfaces and authorization systems should distinguish requested removal, committed removal and confirmation that relevant clients have advanced.<\/p>\n
A properly removed member should not derive keys for later epochs. It can still retain every message and secret it legitimately obtained earlier.<\/p>\n
Cryptographic removal cannot erase history from a compromised device. Nor can it prevent another remaining member from forwarding future plaintext.<\/p>\n
The guarantee is forward exclusion from new group secrets, bounded by the honesty and update state of remaining clients.<\/p>\n
Deleting old epoch secrets protects past messages after a current compromise. Fresh update paths can restore security for future epochs after an attacker loses access to the compromised client.<\/p>\n
Healing is not automatic with the passage of time. It depends on an uncompromised member contributing fresh secret material and affected clients processing the update.<\/p>\n
Backups that preserve every historical secret can defeat forward secrecy. Multi-device synchronization can extend compromise if it copies current state to a device that has not been cleaned.<\/p>\n
A client publishes a KeyPackage containing an initialization key, signature key, credential and supported capabilities. Another member can use it to add the client while that client is offline.<\/p>\n
Initialization keys are intended for controlled use. Reusing a KeyPackage or its private key across additions can weaken security and link group memberships.<\/p>\n
The directory distributing KeyPackages needs authentication, inventory and consumption semantics. An obsolete package can add the wrong device even when the MLS cryptography verifies.<\/p>\n
MLS authenticates credentials and signatures according to the selected ciphersuite and application profile. It does not define what a user account is or which device may represent it.<\/p>\n
An Authentication Service maps credentials to application identities and policies. Account recovery, device enrollment and enterprise membership remain outside the base protocol.<\/p>\n
If the service can silently substitute a credential, key transparency<\/a> can make that change visible and auditable.<\/p>\n MLS can operate over an untrusted Delivery Service. Encryption prevents it from reading application content or forging valid member messages.<\/p>\n The service can still delay, reorder or withhold commits and messages. It can give different clients incomplete histories and observe group-level metadata.<\/p>\n Clients need rules for buffering, fetching missing state and detecting that their local view has stopped advancing.<\/p>\n Two members may create commits from the same epoch before learning of each other. Both cannot simply become the next group state.<\/p>\n The application needs an ordering and retry strategy. A losing commit may need to be reproposed against the accepted epoch with fresh update material.<\/p>\n Consensus over one linear group history is partly provided by the delivery environment, not by the tree alone.<\/p>\n Servers can commonly observe group identifiers, traffic timing, message sizes, membership operations and which devices fetch updates. Encryption protects message content, not all group structure.<\/p>\n Padding, batching and private delivery can reduce exposure, but large dynamic groups create distinctive patterns. The architecture should state which metadata the service is permitted to learn.<\/p>\n A client that loses its current epoch state may be unable to decrypt new messages. Backing up state improves recoverability but creates another copy of current and possibly historical secrets.<\/p>\n A safe design can back up identity credentials separately, re-add a recovered device with a new KeyPackage and avoid restoring old epoch secrets. That choice may sacrifice access to old ciphertext unless messages are backed up under another key.<\/p>\n Recovery behaviour defines the practical boundary of forward secrecy.<\/p>\n MLS does more than encrypt messages to a list. It makes the list part of a shared authenticated state and evolves that state through proposals, commits and epochs.<\/p>\n Security depends on credential distribution, delivery ordering, key deletion and recovery practices outside the core protocol.<\/p>\n Removing a member creates a new epoch because membership is not metadata around the keys. It determines the keys.<\/p>\n Messaging Layer Security makes membership part of shared cryptographic state. A removal takes effect when the remaining group commits and derives a new epoch.<\/p>\n","protected":false},"author":2,"featured_media":366,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","nlabs_series_part":0},"categories":[10],"tags":[68,69,75],"nlabs_series":[],"nlabs_article_type":[36],"class_list":["post-368","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-research","tag-algorithms-primitives","tag-applied-cryptography","tag-protocols","nlabs_article_type-primer"],"_links":{"self":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/368","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/comments?post=368"}],"version-history":[{"count":1,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/368\/revisions"}],"predecessor-version":[{"id":224752,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/368\/revisions\/224752"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media\/366"}],"wp:attachment":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media?parent=368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/categories?post=368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/tags?post=368"},{"taxonomy":"nlabs_series","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_series?post=368"},{"taxonomy":"nlabs_article_type","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_article_type?post=368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Delivery Service controls availability and order<\/h2>\n
Concurrent commits create branches<\/h2>\n
Metadata remains a group property<\/h2>\n
State backup is a security decision<\/h2>\n
Membership is the cryptographic state<\/h2>\n
\nReferences<\/h2>\n
\n