The Aplexica zero-knowledge architecture

When we say zero-knowledge cloud, we mean a specific thing. We mean that Aplexica’s servers cannot decrypt your content, even on Aplexica’s own infrastructure, even with the cooperation of Aplexica employees, even with a valid legal order compelling us to try.

This post is the honest description of how that is achieved — what we encrypt, what we don’t, what an attacker would have to do to break it, and which trade-offs we chose along the way.

The cryptographic invariant

Two sentences. The rest of this post explains them.

Aplexica’s servers see ciphertext and routing metadata. They never see plaintext content or the keys required to decrypt it.

The keys live on your devices. They are derived from a high-entropy namespace secret that you generate the first time you turn Cloud on. They never leave your machine in plaintext. The server cannot ask for them and cannot recover them.

What gets encrypted

Three categories of data flow between your devices and Aplexica Cloud.

Artifact bodies. Memories, skills, conversation history, and the canonical agent state itself. Every artifact body is encrypted on the client before it is uploaded. The cipher is XChaCha20-Poly1305 with a per-namespace 256-bit symmetric key. The nonce is random, the AAD is the routing envelope (so it cannot be replayed under a different envelope), and the authenticated tag means tampering is detectable on read.

Routing metadata. A small opaque envelope around each artifact: which namespace it belongs to, what kind of artifact it is, when it was created, the chain of authorship. This is not encrypted — the server needs to route it. It is signed by the device with Ed25519, which gives us tamper-evident audit trails without giving up confidentiality.

Transport. All client–server communication runs over TLS 1.3 with modern cipher suites. Underneath that, the MQTT protocol carries the encrypted artifact bodies and signed envelopes.

The flow, end to end

flowchart LR
    A[Device A<br/>agent state] -- encrypt --> B[Ciphertext +<br/>signed envelope]
    B -- TLS 1.3 --> C[(Aplexica<br/>Relay)]
    C -- TLS 1.3 --> D[Ciphertext +<br/>signed envelope]
    D -- decrypt --> E[Device B<br/>agent state]
    style C fill:#1c1e1b,stroke:#484d47,color:#efefe7

The relay is a deliberately simple component. It accepts encrypted payloads from one device, routes them based on the signed envelope, and delivers them to other devices in the same namespace. It does not parse the artifact body. It cannot.

What we did not encrypt — and why

Two pieces of metadata are visible to the server. We could have encrypted both, but the operational cost was high and the privacy gain was marginal. We chose visibility and documented the choice.

• Artifact size. Encrypted artifacts have the size of the plaintext plus a fixed overhead. Padding to a uniform size would triple our storage costs and make sync latency worse. We accept that an adversary watching ciphertext flow could distinguish “small message” from “large file.”
• Sync timing. Sync events are visible as they occur. An adversary with full network observation could tell that some sync activity happened at a given time. They cannot tell what.

If you have a threat model where size or timing reveal too much, self-hosted relay is the answer. Enterprise customers run the relay in their own VPC; the metadata never leaves their network.

Keys, in detail

The chain is:

1. On first Cloud setup, the client generates a 256-bit namespace secret using the platform CSPRNG.
2. Namespace keys for encryption (XChaCha20-Poly1305) and signing (Ed25519) are derived from the namespace secret using HKDF-SHA-256.
3. The namespace secret is wrapped with a passphrase-derived key (Argon2id, m=64 MiB, t=4, p=4) and stored locally and in our encrypted vault as a backup blob. Aplexica’s servers cannot recover the passphrase.
4. Cross-device pairing uses an X25519 ECDH handshake authenticated by a short, human-readable phrase shown on both screens. The namespace secret is wrapped to the peer’s ephemeral public key for delivery.

If you lose every paired device and forget your passphrase, your content is unrecoverable. We cannot reset it for you. That is the trade-off you accept in exchange for a server that cannot read your data.

The threat model, briefly

What does Aplexica’s design protect against?

• A breach of Aplexica’s infrastructure. Attackers exfiltrate ciphertext and routing envelopes. Without device-resident keys, the ciphertext is opaque.
• A subpoena to Aplexica. We can produce ciphertext and envelopes. We cannot produce plaintext, because we do not have it.
• A malicious or coerced Aplexica employee. Same outcome: no access to keys.

What does it not protect against?

• A compromise of your device. If an attacker has root on a paired machine, they have your keys. Aplexica does not change the security model of your endpoint.
• A side-channel against the daemon. We follow standard crypto hygiene (constant-time primitives, audited libraries, secret-zeroing at end of life), but the daemon runs in your user-space. Treat it the way you treat your other endpoint software.
• Loss of all paired devices and passphrase. Unrecoverable. The honest answer is that you should write your passphrase down and store it somewhere you would trust to keep a paper backup of your master password.

Why we built it this way

There is a simpler model that many SaaS products use: keep the keys server-side, decrypt for the user on every request, treat the encryption as a deployment detail. That model is easier to operate and lets you recover users who forget their passwords. It also means that a breach of the server breaches every user.

We took the other path. Aplexica’s value is portability of your agent state. If you cannot trust us with your portability layer, the product does not work. The architecture is the trust. We could not in good conscience ship something we ourselves would not use to sync our own agents — and we wanted server-side observability of our content to be impossible, not merely policy-restricted.

So that is the design.

See it for yourself

The daemon source code is on GitHub. The cryptographic primitives are named above, implemented with audited libraries, and called from a small surface that you can read in an afternoon. If you find a problem, our security disclosure policy is written down and we honour it.

We will publish a longer threat-model document with the Cloud GA release. This post is the headline; the details follow.