Zero-Knowledge by Design: How Plum Connects You Without Knowing You

Most so-called private clouds and NAS products still sit a central server in your trust path. Even when files are encrypted, the provider usually knows who you are, which device is yours, and how to reach it. That metadata is often more revealing than the files themselves, and it is a single point that can be compromised, subpoenaed, or sold.

Plum Box is built so the box itself is the root of trust, and the Plum relay that connects you to it is zero-knowledge: it routes encrypted traffic to your box without ever learning your email, your password, your account, or your data. This is not a policy we ask you to believe. It is a property of the cryptography, and this post explains how it works, including the things we deliberately do not claim.

A traditional cloud account works like this: you hand your email and password to a central server; that server holds your identity, decides what you can access, and stores or can access your data. You are asked to trust that the operator is honest, competent, and uncoerced, forever.

End-to-end encrypted products improve the data layer but often leave the identity and routing layer centralized. The provider still maintains the directory that maps you to your device, still terminates your connection, and still sees the metadata of every session.

Our position is that a personal server should require zero standing trust in Plum. We should be able to connect you to your box without being able to know who you are or what you store, so that there is nothing for us to leak, sell, or be forced to hand over.

Everything below follows from four commitments:

• The box is the authority. Your account is created and verified on your box, not on a Plum server. Plum operates no account database that could be breached.
• Zero-knowledge routing. The relay learns where to send bytes without learning who is connecting. Its directory holds only pseudorandom tokens, not identities.
• Key custody belongs to the device. The box generates and holds its own transport keys and disk-encryption keys. Plum never holds a key that decrypts your data or impersonates your box.
• Honest guarantees. We claim exactly what the math gives, and we state the limits plainly.

Three parties, three sharply bounded roles.

• Your box holds everything that matters: the account database, the encrypted data, and the cryptographic keys.
• The relay is a dumb pipe with a zero-knowledge address book. It forwards encrypted traffic to the right box and nothing more.
• The app or browser authenticates directly to the box, end to end, with the relay unable to read the contents.

When you set up a Plum Box, your owner account (email, password hash, roles, sessions) is created on the box's internal storage. There is no corresponding account record on any Plum server. Email verification during onboarding uses Plum infrastructure purely as a mail relay to deliver a one-time code; Plum is never the authority on whether you exist or what you can access.

The consequence is simple: Plum has no account database. There is no central table of users to breach, and no central login that, if compromised, exposes every customer.

The hard problem in a decentralized design is the directory. When you open the app and type your email, how does the relay know which box to connect you to without learning your email?

Plum solves this with an Oblivious Pseudo-Random Function, or OPRF: a 2HashDH construction over the prime-order group ristretto255, with a memory-hard Argon2id pre-hash that binds the lookup to your credentials. Informally, an OPRF lets the client compute a deterministic token from a secret input derived from your credentials and a key held by the relay, so that:

• the relay learns nothing about your input (it only ever sees a blinded value), and
• the client learns nothing about the relay's key.

The resulting token is what the relay stores in its directory, mapping a token to a box. Because the token is the output of a pseudo-random function, the directory is just a table of random-looking strings: the relay cannot run it backwards to recover an email, a password, or any identity. When your box comes online it registers its own token; when you log in, the app reproduces the token and the relay matches it, connecting you to your box while staying blind to who you are. Correct delivery without identification.

In a typical hosted model, the provider can terminate your TLS connection and therefore see your plaintext. Plum inverts this.

• The box generates and holds its own TLS private key. The relay performs SNI passthrough: it forwards the encrypted TLS stream to your box, which terminates it. The relay never holds a key that can decrypt the session.
• The box's device identity, the keypair that proves it is this specific box, is sealed by the device's hardware secure element and never leaves it.
• Your disk is encrypted under keys the box controls. Data on the SSD is protected with LUKS2; the box holds a local key, and you hold a passphrase and a recovery code. Plum holds none of these.

Self-custody is only real if you can recover. Plum issues a single standing recovery code at the end of onboarding that serves as both your account recovery and your disk-encryption recovery key. You save one code, once. Plum never sees its plaintext and cannot regenerate it, which is exactly why losing it cannot be reset by us, and why no one at Plum can use it against you.

To make the trust boundaries concrete:

• The relay never sees: your email or username, your password, which identity owns which box, your file contents, your disk-encryption keys, or your box's TLS private key.
• The relay only sees: that some box is online at a pseudorandom token, plus the connection-level metadata needed to move bytes.
• Your box holds: your account (with the password as a bcrypt hash), your files, and every encryption key.
• You hold: your password, your passphrase, and your recovery code.

• No central identity store: there is no Plum-side account database to compromise.
• A zero-knowledge directory: the routing table holds OPRF outputs, not identities, and cannot be reversed into a customer list.
• No key escrow: Plum holds no key that decrypts your data, terminates your sessions, or impersonates your box.
• Compromise containment: breaching the relay yields ciphertext and pseudorandom tokens, not credentials, not data, not a way in.
• Verifiable by construction: the primitives (OPRF/2HashDH, ristretto255, Argon2id, bcrypt, LUKS2) are public and standard, so trust rests on math you can check.

Honesty is a security feature. Plum does not claim:

• Metadata invisibility. The relay necessarily observes connection-level metadata such as IP addresses and timing to move bytes. We minimize what is retained, but we do not claim to hide that a connection is happening.
• Protection against a fully compromised box. The box is the root of trust by design; if an attacker gains privileged control of your box, the box's protections do not defend you against it.
• Protection against a lost recovery code. Because we cannot see or regenerate it, an unrecoverable code is unrecoverable. That is the cost, and the point, of self-custody.
• Unbreakable anything. No system is. We claim specific, bounded properties backed by specific, named primitives, and nothing more.

Centralized clouds ask you to trust an operator indefinitely. Most private alternatives still keep the identity and routing layer centralized, leaving the most revealing metadata, and a single high-value target, in the provider's hands.

Plum's design removes Plum from your trust path. We connect you to your box because the cryptography lets us do it blindly, and what we cannot see, we cannot lose, sell, or be compelled to reveal. That is the difference between a privacy promise and a privacy property.