The Anatomy of a Project Invite: How We Share Secrets Without Seeing Them

Inviting a teammate to a shared vault is the most dangerous moment in any password manager's lifecycle. It's the point where a single secret has to leave one person's brain and arrive — intact, unread, and untampered with — inside another person's encrypted storage. Most products solve this by quietly handing the secret to the server for a moment. We don't. Here's how a Pwdly project invite actually works, step by step.

The problem with "just share it"

When traditional managers "share" a vault, they typically re-encrypt the contents on the server using the recipient's public key. That sounds fine until you ask the obvious question: how did the server get the plaintext to re-encrypt in the first place? In most architectures, it didn't — but it did get the symmetric vault key, which is functionally identical. If the server ever holds the key, the server can read everything. We refused to ship that.

Step 1: Every account is a keypair

When you create a Pwdly account, your client generates an X25519 keypair entirely in your browser. The public key is uploaded to our servers and signed by your account. The private key is encrypted with the symmetric key derived from your master mnemonic (via Argon2id) and stored alongside your encrypted vault. We store the ciphertext. You hold the only key that can decrypt it.

Step 2: A project is a sealed envelope

Each project (a shared vault — say, "Acme Marketing Team") has its own randomly generated symmetric key, which we call the project key. Every secret inside the project is encrypted with this key using XChaCha20-Poly1305. The project key itself never travels in the clear — it lives in your client's memory only after it's been unsealed.

Step 3: The invite — a NaCl sealed box

When you invite a teammate, your client fetches their signed public key from our server, verifies the signature, and then uses libsodium's crypto_box_seal primitive to encrypt the project key directly to that public key. The result is a sealed envelope: only the holder of the matching private key can open it. We upload that ciphertext blob to the server as the invite payload.

Crucially, sealed boxes are anonymous on the cryptographic layer — but we attach a signed header so the recipient can verify exactly who invited them and to which project. Authenticity without exposure.

Step 4: Acceptance

The next time your teammate signs in, their client downloads the sealed envelope, derives their private key from their mnemonic, and unseals the project key locally. From that moment on, their browser can decrypt every secret in the project — and our servers still cannot. We've never seen the project key, the items inside it, or the contents of the invite envelope.

What the server actually sees

From our database's point of view, an invite is three things: an opaque ciphertext blob, a recipient user ID, and a signature from the inviter. That's it. There is no decryption key on disk, no in-memory copy of the project key, no hook that lets an admin "impersonate" a user. If we got hacked tomorrow, the attacker would walk away with a pile of envelopes they cannot open.

Why this design wins

End-to-end sharing isn't a marketing flourish — it's the difference between trusting math and trusting a vendor. The math doesn't have a bad day. The math doesn't get phished. The math doesn't get a subpoena. By making the project invite a sealed box between two users' devices, we removed ourselves from the trust equation entirely. The only people who can read your team's secrets are the people you invited. That's the only honest answer to "who has access to my data?"