The V3 key model
Passary generates a random 256-bit root key when it creates a V3 vault. That key is independent of your master password. Your password and optional keyfile derive a separate AES-256-GCM credential-wrap key, which encrypts the root key. After unlock, keys derived from the root key protect the vault's records, attachments, and manifest.
Primitives and current defaults
These are the V3 web implementation's current choices. Stored KDF parameters are read from and validated against the vault header, rather than assumed to be universal across all vault generations.
| Purpose | Algorithm | How it is used |
|---|---|---|
| Password work factor | Argon2id | V3 defaults: 256 MiB, 3 passes, 2 lanes; a fresh 32-byte password salt is stored with the credential wrap. |
| Key binding and separation | HKDF-SHA256 | Derives the credential-wrap key from password output, optional keyfile digest, salts, and vault identity; also derives keys from the random root key. |
| Authenticated encryption | AES-256-GCM | Protects the credential wrap, device grants, records, attachment chunks, and manifest with 256-bit keys and 96-bit nonces. |
| Keyfile digest | SHA-256 | Hashes an optional keyfile before its digest is included in credential-wrap derivation. |
| Device identity | P-256 ECDH and ECDSA | Supports encrypted root-key grants to authorized devices and signatures on record revisions. |
Password and keyfile derivation
Password input
Argon2id processes the password with a per-wrap random salt and the stored work parameters. V3 defaults to 262,144 KiB of memory, three passes, and parallelism of two.
Optional keyfile
SHA-256 hashes the keyfile bytes. Without a keyfile, the implementation uses a fixed zero input. With one, those exact bytes are required to derive the same wrap key; the keyfile itself is not embedded in the vault.
The two 32-byte inputs are combined as HKDF-SHA256 input keying material. HKDF uses a separate random salt and vault-specific context to derive the wrap key. The password is not checked against a stored password hash; an incorrect input fails when the wrapped root key cannot be authenticated and decrypted.
What is in a V3 vault file
A .passaryvault file is a JSON envelope, not an entirely opaque byte string. It has a readable header plus encrypted records, attachment chunks, and a manifest.
{
"header": {
"fileFormatVersion": 3,
"schemaVersion": 3,
"vaultId": "<16-byte base64url>",
"cipherSuite": "P3-P256-HKDF-SHA256-AES256GCM",
"credentialWrap": { "...": "..." },
"devices": []
},
"records": [],
"attachments": [],
"manifest": { "nonce": "...", "ciphertext": "..." }
}Record payloads and attachment bytes are encrypted, but the envelope still reveals counts and structural metadata. Private device keys and the plaintext root key are not stored inside this vault file.
Authentication and device revisions
AES-GCM checks each protected ciphertext against its authentication tag. Separate additional-authenticated-data contracts bind relevant fields such as vault identity, KDF parameters, record and revision identity, attachment ownership, and nonces. The encrypted manifest is checked against the current device registry, record revisions, and attachment chunk digests.
V3 generates P-256 ECDH and ECDSA device keys. Device grants can wrap the root key for an authorized device, while signed record revisions identify the device that produced them. Revoking a grant changes which device may participate in subsequent shared generations; it does not erase copies or secrets a previously authorized device already obtained.
Encryption operations generate fresh random 96-bit nonces. The design depends on avoiding reuse of a key-and-nonce pair; a random nonce strategy reduces collision risk but is not an absolute mathematical guarantee of uniqueness. Authentication detects changes to a protected generation, not whether a provider withheld a newer one.
Storage and optional sync
The Windows app can save an encrypted vault file where you choose. The web app can work with a local file or encrypted browser storage. A configured selected folder, WebDAV endpoint, S3-compatible service, or relay may hold another encrypted generation. Core local encryption, unlock, edit, and save do not require a Passary account or sync service.
A network destination still has its own availability and transport-security requirements. It can observe access patterns and may retain old copies. Vault encryption does not make every network request private, and optional integrations such as a consented breach check have separate data flows.
Security boundaries
An encrypted copy is not plaintext
A sync destination or backup holder is not given the master password, optional keyfile, root key, or readable records. Authentication detects modification of protected ciphertext.
Metadata remains visible
The JSON envelope exposes format and KDF parameters, vault and device identifiers, public keys, timestamps, revision structure, and ciphertext sizes. A network destination can also observe connection and object metadata.
An unlocked device must be trusted
Malware, a compromised browser or extension, or malicious app or web code can observe data while the vault is open. Cryptography at rest does not protect an active compromised session.
Availability is separate from integrity
A storage provider can withhold, delete, or serve an older encrypted copy. Authentication alone cannot prove that a retrieved copy is the newest or replace an independent backup.
Recovery and verification
Passary has no provider-held key that can reset a lost master password or replace a missing required keyfile. Keep a separate encrypted vault backup or recovery kit, preserve its unlock credentials, and test a restore. A local snapshot on the same device does not by itself cover device loss.
The V3 parser validates file structure and bounds before decrypting, and authenticated content is verified during unlock. These checks cannot prove that your operating system, browser, installed application, or delivered web code is uncompromised. For the broader model, read Security and Zero-Knowledge Architecture.