Cryptographic Architecture

Sovereign Vault treats memory confidentiality and storage authenticity as twin imperatives. Here is how the inner enclave operates.

1. RAM Pinning via mlock()

Standard userland applications rely on the operating system virtual memory manager to page memory to disk when RAM is constrained. Sovereign Vault allocates the 256-bit Master Key in a dedicated structure and invokes the Linux libc::mlock() syscall. The kernel pins the physical pages in DRAM, rendering it impossible for unsealed keys to leak into unencrypted swapfiles.

2. Hardware Scrubbing with Zeroize

When secrets or temporary buffers go out of scope, standard programming languages merely mark the pointers as freed in heap tables. The electrical states remain intact on physical memory chips. Sovereign Vault implements Rust's ZeroizeOnDrop trait. The compiler is forced to issue volatile hardware memory writes that overwrite the memory buffer with zeroes immediately upon deallocation.

3. Storage Layer: Single-Blob SQLite WAL with AES-256-GCM

Unlike filesystem-level encryption tools that encrypt files individually (leaking directory trees, access timestamps, and file counts), Sovereign Vault persists all data to an embedded SQLite database in WAL (Write-Ahead Logging) mode. Every secret payload is encrypted with authenticated AES-256-GCM AEAD:

• Ciphertext: 256-bit symmetric block encryption.
• Nonce: Cryptographically secure 12-byte random initialization vector per secret.
• Tag: 16-byte Poly1305 / GCM authentication tag preventing bit-flipping attacks.