Zero-Knowledge Architecture

SyVault is built on a zero-knowledge architecture. This means the server never has access to your plaintext data, your master password, or the cryptographic keys needed to decrypt your vault. The server stores only ciphertext and the parameters needed to verify your identity -- nothing more.

What "Zero-Knowledge" Means in Practice

1. Your master password never leaves your device. When you log in, SyVault derives a Master Key locally using Argon2id (64 MiB memory, 3 iterations, 4 parallel lanes), then uses HKDF-SHA256 with domain separation to produce two independent outputs: an Auth Hash (sent to the server for authentication) and an Encryption Key (never sent anywhere). The server receives and stores a second hash of the Auth Hash -- it never sees the password or the Encryption Key.

2. All encryption and decryption happens client-side. Records are encrypted with AES-256-GCM using per-record Data Encryption Keys (DEKs) before they are transmitted to the server. The server receives ciphertext blobs and has no mechanism to decrypt them.

3. The server cannot read your data under any circumstance. Even if the server is compromised, subpoenaed, or physically seized, the attacker obtains only encrypted blobs, wrapped keys, and Argon2id-hashed auth hashes. Without your master password (which exists only in your memory and on your device during an active session), there is no path to plaintext.

danger

Because SyVault cannot access your encryption keys, there is no "forgot password" recovery. If you lose your master password and do not have an organization recovery key, your data is permanently inaccessible. This is a feature, not a limitation -- it is what makes zero-knowledge trustworthy.

How SyVault Compares

Property	SyVault	Traditional Password Managers	Cloud-Synced Notes
Server sees plaintext	Never	Never (if zero-knowledge)	Often
Key derivation	Argon2id (64 MiB, 3 iter)	Varies (PBKDF2 common)	N/A or weak
Per-record encryption	Yes (unique DEK per record)	No (vault-level key)	No
Domain-separated key hierarchy	Yes (HKDF with AAD strings)	Partially	No
Server can reset password	No	Sometimes	Yes
Open-source crypto core	Yes (Rust)	Varies	Rarely

Many password managers claim zero-knowledge but use a single vault-level key -- meaning that compromising one key decrypts everything. SyVault goes further with per-record DEKs and domain separation at every layer, limiting the blast radius of any single key compromise.

The Trust Boundary

The trust boundary in SyVault lies at the client. You trust:

• Your device -- the client application runs on your hardware and handles plaintext.
• The cryptographic primitives -- AES-256-GCM, Argon2id, HKDF-SHA256, ECDH P-256 (implemented via the ring and aes-gcm Rust crates, audited and widely deployed).
• The SyVault client code -- which is open-source and auditable.

You do not need to trust:

• The SyVault server -- it only sees ciphertext.
• The database -- PostgreSQL stores encrypted blobs.
• The network -- all data is encrypted before transmission (and additionally protected by TLS in transit).
• SyVault employees -- we have no ability to decrypt your data even if we wanted to.

info

Zero-knowledge is not about trusting SyVault less. It is about making trust unnecessary. The architecture ensures that even a fully compromised server, malicious insider, or state-level adversary with database access gains nothing useful.