Skip to content
Palladin.ioDocumentation
PL
Docs/Security whitepaper

Data and keys

Separate keys for vaults, entries, and Agent access.

Why use several keys?

Palladin uses separate keys for a user, a vault, and an entry. Sharing one entry therefore does not have to mean sharing the key to the entire vault.

MK — Master Key — is derived from the master password using Argon2id, an algorithm that makes large-scale password guessing more expensive. MK protects the user’s private key.

VK — Vault Key — opens the entry keys in a vault. Each authorized member receives their own encrypted copy of VK, which they can open with their private key. We call this protected copy a key envelope.

  1. Master password
    derives MK
  2. User private key
  3. Vault key
    VK
  4. Entry key
    decrypts content
Unlocking takes place on the user's device. The server does not perform these steps.

Other keys

Protocol name What it protects
EntryDEK — entry encryption key Entry content and descriptions for vault members. DEK stands for Data Encryption Key.
GrantDEK — access-grant key A copy of data prepared for a particular approval to access an entry.
VDK — vault discovery key Metadata an agent can search without receiving the secret’s value.
Agent X25519 and Ed25519 keys Receiving encrypted data and signing agent requests, respectively.

What can the server see?

The server stores encrypted data and key envelopes. It knows organization, vault, entry, and agent identifiers, along with permissions, versions, and audit events. Encryption does not hide every fact about service usage.

Search data is encrypted separately from secrets. An agent can find an entry without receiving its password or API key.

Preventing substitution

Before decrypting, the application checks that data belongs to the correct vault, recipient, and access grant, and has the correct version. It compares these with trusted connection and authorization state, not just the description attached to the received package.

Where are keys stored?

The web app keeps decrypted keys in the unlocked session’s memory. Locking clears them from that session. Locally saved encrypted data still requires a key to read it.

The mobile app is not yet released to stores. Its quick-unlock implementation can persist the master key under system protection. This behavior is under security review and blocks the mobile release; it is not an approved exception to the in-memory key model.

Agent identity keys are held in system key storage or by a separate protective service called a broker. The installation guide explains Hardened and Convenience.