Vault Architecture and Storage

TitaniumGuard Vault is split into four crates with clear boundaries:

• vault-core: stateless crypto and record operations.
• vault-platforms: platform persistence and adapter interfaces.
• vault-sync: sync domain model and conflict scaffolding.
• vault-cli: orchestration layer for init, unlock checks, create/list/delete/export.

Stateless Core Model

vault-core does not own in-memory session state as the primary runtime model. Instead, it exposes request/response operations:

• init_vault
• verify_master_password
• encrypt_record
• decrypt_record

This keeps cryptographic behavior portable across CLI, desktop, and mobile wrappers.

Password Verifier Persistence

Vault persistence stores a versioned password verifier blob, not a raw derived master key.

• Verifier contains metadata needed for password proof (vault_id, KDF params, salt, verifier material).
• Platform storage treats the verifier as opaque bytes.
• Unlock flow validates a provided master password against the persisted verifier material.

Record Persistence

Records are persisted as per-record encrypted blobs.

• Each record is stored independently by record_id.
• CLI filesystem adapter stores blobs under a vault-specific records directory.
• Decryption is performed through core APIs after password verification.

Cryptography Baseline (Phase 1)

• KDF: Argon2id
• AEAD: XChaCha20-Poly1305
• Associated data binds vault_id, record_id, schema version, and logical type.
• Current behavior encrypts all fields uniformly.

Storage Notes for CLI

The CLI uses vault-platforms file-backed implementations:

• Secure-store fallback for verifier and active vault metadata.
• Filesystem-backed per-record encrypted blobs.
• Default root can be configured with TITANIUMGUARD_VAULT_DIR.

For command examples, see Vault CLI Usage.