Skip to content

Encryption & Key Management

MazeVault Cryptographic Standards and Key Lifecycle

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

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
Zero-Knowledge Data 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 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 Custom
AWS CloudHSM FIPS 140-2 Level 3 certified Custom
Google Cloud HSM FIPS 140-2 Level 3 certified Custom
PKCS#11 (on-premise HSM) Thales Luna, Utimaco, nCipher Custom

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. Zero-Knowledge Architecture

In zero-knowledge mode, secrets are encrypted client-side before transmission:

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 (cannot decrypt)
    end

    Note over S: ⚠️ Server never has access<br/>to plaintext or derived key

    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

Zero-Knowledge Limitation

In zero-knowledge mode, server-side features such as secret rotation, search, and sharing are unavailable since the server cannot access plaintext data. 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.