Skip to content

Encryption & Key Management

MazeVault Cryptographic Standards and Key Lifecycle

Document Version: 1.0.0
Last Updated: 2026-10-28

1. Cryptographic Standards

Encryption at Rest

Purpose Algorithm Key Size Mode Standard
Secret Values AES-256-GCM 256-bit Authenticated Encryption NIST SP 800-38D
Client-Side Encrypted Data (v2) AES-256-GCM 256-bit Client-side Encryption NIST SP 800-38D
Database Fields AES-256-GCM 256-bit Application-level NIST SP 800-38D
Backup Archives AES-256-GCM 256-bit Symmetric NIST SP 800-38D

Key Exchange

Purpose Algorithm Parameters Standard
Agent ↔ Server ECDH P-256 curve NIST SP 800-56A
mTLS RSA-OAEP SHA-256, 2048+ bit PKCS#1 v2.2
Session Keys HKDF SHA-256 RFC 5869
Password Auth (API; the web interface signs in with the password over TLS) SRP-6a 2048-bit group RFC 5054

Digital Signatures

Purpose Algorithm Key Size Standard
JWT Signing RS256 2048-bit RSA RFC 7518
Certificate Signing RSA/ECDSA 2048/4096 RSA, P-256/P-384 ECDSA RFC 5280
OCSP Response Signing RSA/ECDSA 2048+ bit RFC 6960
Code Signing RSA 2048+ bit RFC 5652

Hashing

Purpose Algorithm Standard
Password Storage bcrypt / Argon2id — / RFC 9106
Data Integrity SHA-256 FIPS 180-4
Certificate Fingerprints SHA-256 RFC 5280

2. Key Rotation Policy

Key Type Rotation Interval Automatic Notes
Master Encryption Key Annual No Requires planned maintenance window
Secret Cipher Keys 90 days Yes Transparent re-encryption
JWT Signing Keys On demand Yes Seamless key rollover
TLS Certificates Before expiry Configurable Automated renewal supported
Agent Certificates Annual Yes Automatic renewal via bootstrap
API Keys Organization policy No Manual rotation recommended every 90 days

Key Rotation Process

graph LR
    A["🔑 Generate<br/>New Key"] --> B["🏦 Store in<br/>HSM / Vault"]
    B --> C["🔄 Update Active<br/>Key Reference"]
    C --> D["🔐 Re-encrypt Data<br/>(background)"]
    D --> E["✅ Verify<br/>Integrity"]
    E --> F["📦 Archive<br/>Old Key"]
    F --> G["🗑️ Delete Old Key<br/>(after retention)"]

    classDef generate fill:#EBF5FB,stroke:#2196F3,stroke-width:2px,color:#1565C0
    classDef store fill:#E8EAF6,stroke:#3F51B5,stroke-width:2px,color:#283593
    classDef process fill:#FFF8E1,stroke:#FF9800,stroke-width:2px,color:#E65100
    classDef verify fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,color:#2E7D32
    classDef archive fill:#F5F5F5,stroke:#9E9E9E,stroke-width:2px,color:#424242
    classDef delete fill:#FFEBEE,stroke:#F44336,stroke-width:2px,color:#C62828

    class A generate
    class B store
    class C,D process
    class E verify
    class F archive
    class G delete

Master Key Rotation

Master encryption key rotation requires a planned maintenance window. All encrypted data must be re-encrypted with the new key. Contact MazeVault support for rotation procedures.

3. Key Storage

Supported Key Storage Backends

Backend Description License Tier
Software (local) Encrypted key file on disk All
Azure Key Vault Azure-managed HSM or software keys Enterprise
Azure Managed HSM FIPS 140-2 Level 3 certified Enterprise
AWS CloudHSM FIPS 140-2 Level 3 certified Enterprise
Google Cloud HSM FIPS 140-2 Level 3 certified Enterprise
PKCS#11 (on-premise HSM) Thales Luna, Utimaco, nCipher Enterprise

Key Hierarchy

graph TB
    MK["🏦 Master Key<br/>(HSM / Key Vault)"]
    DEK1["🔐 DEK 1<br/>Secrets"]
    DEK2["📜 DEK 2<br/>Certificates"]
    DEK3["🔗 DEK 3<br/>Sessions"]
    SK["✍️ Signing Key<br/>JWT / OCSP"]

    MK --> DEK1
    MK --> DEK2
    MK --> DEK3
    MK --> SK

    classDef master fill:#E8EAF6,stroke:#3F51B5,stroke-width:3px,color:#1A237E
    classDef dek fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,color:#2E7D32
    classDef signing fill:#FFF8E1,stroke:#FF9800,stroke-width:2px,color:#E65100

    class MK master
    class DEK1,DEK2,DEK3 dek
    class SK signing

The key hierarchy follows the envelope encryption pattern:

  1. Master Key — Stored in HSM or Key Vault; never leaves the secure boundary
  2. Data Encryption Keys (DEKs) — Generated per purpose; encrypted by the Master Key
  3. Per-Record Keys — Optionally generated per secret for maximum isolation

4. Client-Side Encryption (v2 Data)

The web interface can encrypt secret names and values for v2 data in the browser, with a key derived from the user's local login password. This is client-side encryption; it is not yet a zero-knowledge design. What holds today:

  • The web interface signs in with the password (not SRP), so the server sees the password during sign-in and could derive the same key. The platform therefore does not guarantee that it never accesses plaintext, and the server is not unable to decrypt.
  • Only a local password sign-in derives the key. LDAP, Kerberos and SSO users never get one.
  • The key is held in a browser service worker that the browser may terminate (absolute lifetime 2 hours). There is no unlock prompt afterwards: the key is restored only by the next local password sign-in, and a reload that lands on the password change or setup page does not restore it.
  • The key check value is not a real check, so a wrong key is not detected.
  • A password change derives a different key, so earlier v2 data no longer decrypts, and there is no re-unlock after a forced password change.
  • The web interface does not create or read secrets through /api/v2. It decrypts only secret names on the dashboard and reads the project secrets matrix (/api/v2/projects/{id}/secrets/matrix).
  • Gateways, agents and rotation need plaintext secrets, so they cannot work on client-side encrypted data. A later release will define which data is zero-knowledge.

The intended flow of client-side encryption:

sequenceDiagram
    participant U as 🧑‍💻 User (Browser)
    participant S as 🖥️ MazeVault API
    participant DB as 🗄️ Database

    rect rgb(235, 245, 251)
    Note over U: Client-Side Encryption
    U->>U: Generate symmetric key (PBKDF2)
    U->>U: Encrypt secret (AES-256-GCM)
    end

    rect rgb(232, 245, 233)
    Note over U,DB: Secure Transport & Storage
    U->>S: Send encrypted ciphertext
    S->>DB: Store ciphertext
    end

    Note over S: ⚠️ Stores only ciphertext<br/>(see the limits above)

    rect rgb(255, 248, 225)
    Note over U,DB: Decryption (Client-Side Only)
    U->>S: Request secret
    S->>DB: Retrieve ciphertext
    S-->>U: Return ciphertext
    U->>U: Decrypt with derived key
    end

Client-Side Encryption Limitation

For client-side encrypted v2 data, server-side features such as secret rotation, search, and sharing are unavailable because the server does not hold the key. Rotation, search and sharing remain available for all other secrets. This mode is intended for personal vault use cases.

5. TLS Configuration

Supported Cipher Suites (TLS 1.3)

Cipher Suite Key Exchange Encryption Hash
TLS_AES_256_GCM_SHA384 ECDHE AES-256-GCM SHA-384
TLS_AES_128_GCM_SHA256 ECDHE AES-128-GCM SHA-256
TLS_CHACHA20_POLY1305_SHA256 ECDHE ChaCha20-Poly1305 SHA-256

Supported Cipher Suites (TLS 1.2 — Backward Compatibility)

Cipher Suite Key Exchange Encryption Hash
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA AES-256-GCM SHA-384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA AES-128-GCM SHA-256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA AES-256-GCM SHA-384

Deprecated Protocols

SSL 3.0, TLS 1.0, and TLS 1.1 are not supported. CBC-mode cipher suites are disabled.