Portable end-to-end encryption for groups.
Asynk is a specification and reference CLI for group-oriented end-to-end encryption. It lets organizations create MLS groups offline, distribute Welcome bundles over any untrusted channel, and import protected group state into their own runtime environments.
Full sections — Specification, CLI, Download and Docs — are under development.
Make your applications talk to other organizations — with cryptographic guarantees, not integration overhead.
Imagine your organization needs its applications to exchange data end-to-end with org2 and org3 to integrate a set of services. You need forward secrecy, post-compromise security, and no shared secret sitting statically at rest.
Asynk lets you create the group offline, share Welcome bundles with the other organizations over any channel — including email — and from that moment on, the respective applications load the shared MLS state and communicate online with key rotation guaranteed by MLS RFC 9420.
According to your CISO directives, you can refresh the group state at any cadence and share handshakes offline as well — decoupling the agreement on the common cryptographic state from the online data plane. This avoids costly integration projects while keeping the cryptographic guarantees MLS provides.
Asynk defines a portability layer on top of MLS RFC 9420 for the cryptographic state: how it's serialized, protected at rest, imported into runtime applications, and rotated across organizational boundaries.
Control plane (offline, Asynk): organizations agree on group state and exchange Welcome bundles across boundaries. Data plane (online, MLS RFC 9420): each org's applications load the shared state and exchange end-to-end encrypted messages with continuous key rotation.
From offline group creation to first encrypted message.
The snippet below shows the minimal two-party flow: one member creates the group and encrypts, the other joins from the Welcome bundle and decrypts.
asynk keyring init \
--member-id org0 \
--output ./members/org0 \
--passphrase-env ASYNK_PASSPHRASEGenerates the member's private keyring and the corresponding KeyPackage ("keypackage.pem") used by others to add it to a group.
asynk bootstrap create \
--group gruppo-test \
--member-id org0 \
--keyring ./members/org0/org0.keyring.asynk \
--keypackage ./members/org0/org0.keypackage.pem \
--member org1=./members/org1/org1.keypackage.pem \
--passphrase-env ASYNK_PASSPHRASEOrg0 creates the MLS group offline and produces a Welcome bundle for org1 that can be sent over any untrusted channel.
asynk encrypt ./data.jpg \
--group gruppo-test \
--passphrase-env ASYNK_PASSPHRASEProduces the encrypted payload, metadata and sender data files under the current Asynk context.
asynk bootstrap join \
--welcome ./gruppo-test.org1.welcome.mls \
--member-id org1 \
--keyring ./members/org1/org1.keyring.asynk \
--keypackage ./members/org1/org1.keypackage.pem \
--passphrase-env ASYNK_PASSPHRASE
asynk decrypt ./data.jpg_encrypted \
--metadata ./data.jpg_encrypted_metadata \
--sender-data ./data.jpg_encrypted_sender_data \
--welcome ./gruppo-test.org1.welcome.mls \
--member-id org1 \
--keyring ./members/org1/org1.keyring.asynk \
--keypackage ./members/org1/org1.keypackage.pem \
--output-dir ./decrypted \
--passphrase-env ASYNK_PASSPHRASEOrg1 imports the Welcome bundle, loads the shared group state, and decrypts the payload. The original file can be verified with a SHA-256 checksum.
Deploy an Asynk gateway per organization — end-to-end security anchored to the trusted boundary.
Most enterprise workloads — trading platforms, settlement engines, custody systems — cannot embed an MLS stack natively. They run as many replicas, in mixed languages, behind load balancers, and their release cycle is dictated by regulation, not by cryptography.
The Asynk specification lets each organization deploy a crypto gateway as a service inside its own trusted boundary. Application replicas talk to their local gateway over mTLS in-VPC; the gateways form the MLS group between them and carry the end-to-end encrypted traffic across the public transport.
The trust boundary of the E2EE channel is the gateway, not each individual replica. Adding a new microservice inside an organization does not require a new MLS onboarding: it just calls its local gateway. This maps naturally to how financial organizations — banks, CCPs, custodians — need to establish regulated communication channels for settlement, reporting, or reconciliation.
Group creation, member rotation and epoch refresh still happen through the offline bootstrap flow between the gateways, so onboarding a new counterparty stays a governance decision, not an integration project.
Three financial organizations, each with its own trusted boundary. App replicas that cannot speak MLS natively delegate to a local Asynk gateway; the gateways form the MLS group and exchange end-to-end encrypted messages over any untrusted transport.
Protect service-to-service traffic inside your own perimeter — with keys the network never sees.
A financial platform can easily run dozens of microservices with different responsibilities — payments APIs, card vaults, KYC, ledger, risk engines, reporting — handling data covered by PCI DSS and GDPR. Assuming the internal network is trusted is exactly the assumption a zero-trust architecture rejects.
Asynk lets you treat the mesh as a single MLS group. Adding a new service to the group is an offline DevOps operation: the CI/CD pipeline generates the KeyPackage, opens a signed Welcome bundle, and the updated group state is rolled out with the next deployment. No online rendezvous service, no shared static secret baked into images.
Every pod loads the shared Asynk state at startup and derives short-lived keys from the current MLS epoch to protect each call — for example wrapping REST payloads as JWE (JOSE, RFC 7516) with Content-Type: application/jose. Rotating a member (a compromised pod, an offboarded service) is a single MLS commit, and every subsequent call uses fresh keys.
The result is an end-to-end encrypted mesh where PCI and GDPR payloads are never in cleartext on the wire, key rotation is continuous, and onboarding a new service stays a pull-request review — not a bespoke cryptographic integration.
Inside one organization: many Kubernetes pods with different regulatory scopes share a common Asynk group state, provisioned offline via DevOps, and derive JWE keys per call from the current MLS epoch.
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. It never sees plaintext keys leave the trust boundary of the KMS: the provider asks the KMS to encrypt/decrypt, and stores only the resulting ciphertext + key reference. 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.
Exchange terabyte-scale files between regulated entities — with end-to-end group encryption and chunk-level verifiability.
Imagine a payment gateway, an acquirer, a card network and a central-bank settlement operator — or an RTGS, a digital Euro (CBDC) platform, and a fiat custody service — that must exchange massive batch files while keeping every payload end-to-end encrypted across organizational boundaries.
Asynk implements streamMLS, 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 integrity before they decrypt, and the sender can prove the batch was delivered exactly once to the authorized group — 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.