Security design

Sphragis encrypts your vault on your devices. Its servers store ciphertext and cannot decrypt it. This page summarises how that works. The full cryptographic specification covers every key, label and byte layout.

Two secrets make your key

Your vault key comes from two secrets: your master password and your Secret Key.

• Your master password stays in your head.
• Your Secret Key is 128 random bits that your device creates. It lives on your devices and in your Emergency Kit. Sphragis never receives it.

Your device runs Argon2id on the master password, with 128 MiB of memory and 3 passes by default. It combines the result with the Secret Key through HKDF-SHA256 to make your Account Unlock Key. Clients refuse settings below 64 MiB, so a server cannot weaken them.

Guessing your master password offline would need your Secret Key as well. Someone who steals a Secret Key from a device still has to run Argon2id for every guess.

Signing in never sends your password

Sphragis checks that you know your master password with OPAQUE (RFC 9807), a password-authenticated key exchange. Your device proves knowledge of a key derived from both secrets. The server stores an OPAQUE record and never sees the master password, the Secret Key or anything derived from them.

You also sign in with your SiliconBlast account. That account controls access to the service. It cannot open your vault.

Every item has its own key

Your device encrypts each item with its own key, using XChaCha20-Poly1305. Each ciphertext is bound to its account, vault, item, field and revision. A server that moves ciphertext to another place, or replays an old copy, makes decryption fail. Clients also notice a vault that goes back to a revision older than one they have seen.

Titles, URLs, usernames, notes and one-time code seeds are encrypted along with passwords. Attachments are encrypted in chunks before upload.

Sharing seals a copy of the key

When you share a vault, your device seals a copy of the vault key to each person's public key. Sealing uses X-Wing, which combines X25519 with ML-KEM-768, so recorded traffic stays protected against a future quantum computer. Grants are signed with Ed25519.

When an organisation invites someone, the admin and the invited person compare a six-word code before the first vault key is sealed. A changed key for a known contact blocks new grants until it is checked again.

Secrets for applications

A Zero-knowledge secrets project keeps its key in your vault. Only people and machine identities you grant can read its values. A Managed project keeps its key in Sphragis, encrypted under keys that live in a separate key service. Managed projects let workloads sign in with OIDC, and Sphragis can read their values.

A tamper-evident audit log

Every privileged action writes an audit event in the same database transaction. Events form a hash chain, and the key service signs checkpoints of the chain with Ed25519. sphragis audit verify recomputes the chain and checks the signatures on your own computer.

What Sphragis can see

The service needs some information to run. Sphragis can see your account email, how many items each vault holds, their sizes and timestamps, who shares with whom, IP addresses, project and environment names, and secret names in Managed projects.

Limits

Encryption protects your vault at rest, in transit and on Sphragis servers. It cannot protect a device that is unlocked and controlled by malware.

Report a security issue

Email security@siliconblast.com.