Encrypted Vault

Every document stored in VaultCrux is encrypted before it touches persistent storage. The encryption layer uses HashiCorp Vault Transit with AES-256-GCM - a hardware-backed encryption service that manages key material separately from the application layer. VaultCrux never holds encryption keys in memory. Every encrypt and decrypt operation is a remote call to Vault Transit, which means the application servers are stateless with respect to key material.

The encryption architecture uses envelope encryption with per-tenant keys. Each tenant gets a dedicated encryption key in Vault Transit. When a document is ingested, VaultCrux generates a random data encryption key (DEK), encrypts the document content with the DEK, then encrypts the DEK itself using the tenant's key via Vault Transit. The encrypted DEK is stored alongside the encrypted document. To decrypt, the process reverses: Vault Transit decrypts the DEK, and the DEK decrypts the document content. This two-layer approach means that rotating the tenant key does not require re-encrypting every document - only the DEKs need to be re-wrapped.

Key rotation is automatic. Vault Transit supports key versioning, and VaultCrux uses the latest key version for all new encryptions while maintaining the ability to decrypt documents encrypted with older key versions. When you trigger a key rotation (or it happens on schedule), new documents use the new key version immediately. Existing documents continue to decrypt with their original key version until they're re-ingested or explicitly re-encrypted during a rotation sweep.

Private content fields receive special treatment. Document metadata (title, source URL, MIME type, ingestion timestamp) is stored in plaintext to support filtering and indexing. But content fields - the actual text of the document - use the full envelope encryption path. This means database administrators, infrastructure operators, and anyone with direct database access can see that a document exists and when it was ingested, but cannot read what it says. The same applies to database backups: a stolen backup contains encrypted blobs, not readable documents.

The cryptographic receipts produced by the proof system tie into this encryption architecture. A receipt attests that an answer was generated from specific encrypted documents, using a specific retrieval path, at a specific time. The receipt does not contain the decrypted content - it contains hashes of the content, signed by Vault Transit. This means receipts can be shared externally without risk of content disclosure, because the verification path is hash-based, not content-based.

Ed25519 signing (used for proof receipts and COSE_Sign1 envelopes) operates through the same Vault Transit backend. VaultCrux uses pure Ed25519 signing - not prehashed - because Vault Transit does not support the prehashed variant for Ed25519 keys. All signing operations are audited by Vault's own audit log, providing a second independent record of every cryptographic operation alongside VaultCrux's own audit trail.