Skip to main content

Encryption Settings

The Document Vault's encryption uses secure defaults designed to provide strong security without requiring manual configuration. This guide documents the encryption approach and key management model.

Encryption Approach​

The vault uses AES-256-GCM as its sole encryption algorithm. There is no algorithm negotiation or selection -- all documents are encrypted with the same algorithm and key size.

Why a Single Algorithm?​

The vault intentionally does not support multiple encryption algorithms. Supporting a single, well-audited algorithm:

  • Reduces attack surface: No algorithm negotiation means no downgrade attacks.
  • Simplifies auditing: One algorithm to verify, test, and maintain.
  • Ensures consistency: All documents in the vault have the same security level.

Key Derivation​

Encryption keys are derived from the user's wallet-derived secret and a per-document salt. The key derivation function is designed to be computationally expensive to resist brute-force attacks while remaining fast enough for acceptable user experience.

Key derivation parameters are set to secure defaults and should not need adjustment in most deployments.

Key Management​

Key Lifecycle​

Encryption keys in the vault follow a strict lifecycle:

Wallet Signature ──> TEE Receives ──> Key Derivation ──> Encryption/Decryption ──> Key Zeroed

Key Zeroing​

After every cryptographic operation, the vault zeroes out sensitive material from TEE memory:

  • Wallet-derived secret
  • Encryption key
  • Plaintext document
  • Intermediate key derivation values

No Key Storage​

The vault does not store encryption keys anywhere:

  • No key database
  • No key escrow
  • No key backup

Keys are derived on demand from the user's wallet signature and the per-document salt. This means:

  • Key recovery is impossible: If a user loses their wallet, their documents are permanently lost.
  • Key rotation is not applicable: Each document has a unique key derived from a unique salt.
  • Key compromise scope: Even if one document's key were somehow compromised, other documents remain secure because they use different salts.

TEE Attestation​

The TEE attestor supports remote attestation, which allows clients to verify that the TEE is running the expected code before submitting documents. The attestation proves:

  • The TEE is a genuine hardware enclave (not emulated).
  • The code running inside the TEE matches the expected hash.
  • The TEE has not been tampered with.

Security Recommendations​

  1. Do not weaken key derivation parameters. Lower values significantly weaken brute-force resistance.
  2. Always enable TEE attestation in production. Disabling attestation removes the hardware trust guarantee.
  3. Always enable key zeroing. Disabling it leaves sensitive material in TEE memory longer than necessary.