An MLS RFC 9420 implementation, built for enterprise group encryption.
Asynk implements MLS (RFC 9420) for end-to-end group encryption with forward secrecy and post-compromise security. StateStore and ProtectionProvider are pluggable — group state lives in your infrastructure and moves across organizations without re-keying. The patent-pending streamMLS extension adds large-scale bulk data exchange.
The streamMLS whitepaper (patent pending) is available on request after a short professional questionnaire.
The value proposition
MLS gives you group cryptography.
Asynk gives you a way to operate it.
MLS (RFC 9420) specifies the cryptography — groups, epochs, commits, forward secrecy and post-compromise security. But the standard deliberately leaves the operational layer to implementations: where the group state lives, how secrets are protected at rest, how a group is bootstrapped across organizations, how members rotate.
Asynk closes that gap. Pluggable StateStore and ProtectionProvider interfaces, offline bootstrap with Welcome bundles, and the patent-pending streamMLS bulk extension — so the guarantees MLS promises actually ship in production.
StateStore persists the MLS group state — atomically, with generation and epoch metadata.
ProtectionProvider wraps secret material through an external KMS — from a passphrase file to an HSM-backed Vault.
Offline bootstrap moves the group state across organizations without re-keying — even over email.
Two abstractions: StateStore and ProtectionProvider.
Asynk models the runtime around two pluggable components. Together they decouple where the group state is stored from how the secret material is protected at rest — so the same application code runs on a laptop, on a container in a private cloud, or against an HSM-backed KMS.
Atomic persistence of group state
Loads and saves the opaque MLS group blob with generation and epoch metadata. Guarantees atomic updates and rejects stale writes, so two concurrent commits can never fork the group. Implementations range from a Postgres row (asynk_group_state) to a KV entry, an object storage key, or a local file.
Wrap / unwrap the sensitive material
Called by the StateStore before writing and after reading. The wrapping key never leaves the KMS — the provider only sends ciphertext in and gets ciphertext out. But the MLS state itself is a different matter: at load the KMS returns it in plaintext to the Asynk process, because the MLS engine needs the live secrets in memory to operate. So protection covers the state at rest, not the runtime secrets in the process. Strategies include envelope encryption, KV wrapping, and direct transit encryption.
The application talks only to the StateStore. The StateStore delegates protection to the configured ProtectionProvider, which in turn calls the external KMS. Rotating the wrapping key, or migrating to a different KMS, is a provider-level change — the application and the MLS state are untouched.
Vault Transit as ProtectionProvider
A typical deployment configures the vault-transit provider against a named Transit key (for example transit/keys/asynk-group). On every save, the StateStore serializes the MLS state, hands it to the provider, which calls POST /v1/transit/encrypt/asynk-group and stores the returned ciphertext blob plus the Vault key reference. On load, the provider calls POST /v1/transit/decrypt/asynk-group to recover the plaintext state just long enough to feed the MLS engine.
The wrapping key never leaves Vault. Key rotation, audit logging, and access policies are enforced by Vault; Asynk only records which key version protected each stored blob so old records remain decryptable across rotations.
One MLS core. Several consequences.
Once a group exists and its state is portable, the same building blocks compose into very different deployments. Each one is documented in full — with diagrams and CLI flows — in the documentation.
App-to-app
Two organizations bootstrap the group offline, then their applications talk online with continuous key rotation.
Crypto gateways
Workloads that cannot embed MLS delegate to a local gateway per organization, anchored to the trusted boundary.
Zero-trust mesh
Kubernetes pods join as distinct leaves of one group under the same workload identity, wrapping REST payloads as JWE.
streamMLS — the patent-pending evolution of MLS for bulk data.
streamMLS is a patent-pending extension of Messaging Layer Security (MLS RFC 9420), designed for group-oriented streams of very large data. The file is split into chunks; every chunk is protected under the same MLS group, so the whole exchange inherits MLS forward secrecy, post-compromise security and group membership semantics.
Each chunk carries an independent verification artifact (the proof_secret) and the whole stream is committed atomically against a global MLS epoch. Recipients can verify the integrity of every chunk before decrypting it, and the atomic commit guarantees that a stream is either complete and consistent or rejected as a whole — so no chunk is silently dropped or replayed out of order, with no trusted transport needed.
Use cases include payment gateway reconciliation, acquirer settlement, card-circuit clearing, real-time gross settlement (RTGS) batches, and central-bank digital currency (CBDC / Euro Digitale) file transfers. The cryptographic agreement on the group can still be bootstrapped offline with Asynk Welcome bundles; the data plane then moves massive files over any untrusted channel.
streamMLS: a sender (for example a payment gateway) splits a massive file into MLS-protected chunks, streams them to three recipients over an untrusted channel, and each recipient verifies and atomically commits the whole sequence under the same MLS group epoch.
streamMLS is protected by a pending patent application
The streamMLS extension is currently the subject of a patent application submitted to the UIBM — Italian Patent and Trademark Office. Until the application is published and examined, the implementation details and claims are confidential; the label on the diagram indicates the pending status.