Skip to main content

Zeq Vault

Secrets are encrypted with AES-256-GCM before they touch the database, the plaintext is never returned by any API, and every set / read / rotate appends a hash-linked row to a tamper-evident audit chain.

  • Live app → /apps/zeq-vault/
  • Source → shared/api-core/src/lib/zsc/, shared/api-core/src/routes/zsc.ts, shared/api-core/src/lib/zeqField.ts
  • Construction → AES-256-GCM at rest · PBKDF2-SHA256 (200k) key derivation · per-secret audit chain
  • Master key → ZEQ_FIELD_KEY (32-byte hex), required in production

What it actually does​

Zeq Vault is the framework's Zeq Secure Context (ZSC) — a server-side secret store, not a client-side keychain. The construction:

  1. Encryption at rest — every secret value is encrypted with AES-256-GCM and a fresh random 96-bit IV before it's written. The 16-byte GCM tag is stored with the ciphertext, so any tampering fails the auth-tag check on read.
  2. Key derivation — the AES key is derived with PBKDF2-SHA256 (200,000 iterations) from the 32-byte master key ZEQ_FIELD_KEY, salted with the frozen HULYAS-constant string. The master key lives outside the vault (it bootstraps the vault — see the ZSC bootstrap allow-list), so the vault never has to decrypt itself.
  3. Audit-chained reads — every set, read, and rotate appends a hash-linked row to that secret's audit chain (the entangled state), stamped with the Zeqond it happened at. The chain is SHA-256-linked, so history can't be silently rewritten.
  4. Rotation — re-encrypts a secret under a fresh IV (and, at the field level, supports decrypting under a previous master key via ZEQ_FIELD_KEY_PREV while encrypting under the new one) for zero-downtime master-key rotation.

The plaintext is never echoed back by the API — reads return metadata only. Confidentiality is AES-256-GCM; tamper-evidence is the SHA-256 audit chain. The Zeqond stamp records when, it is not part of the cipher.

The construction, step by step​

StageMechanismStandard
EncryptionAES-256-GCM, fresh 96-bit IV per writeNIST SP 800-38D
Key derivationPBKDF2-SHA256, 200,000 iterations, from ZEQ_FIELD_KEYNIST SP 800-132
Integrity16-byte GCM tag verified on every readNIST SP 800-38D
Auditper-secret hash-linked chain, Zeqond-stampedSHA-256 (FIPS 180-4)
Rotationfresh IV + optional previous-key fallback (ZEQ_FIELD_KEY_PREV)—

Runnable worked example — store + rotate​

Zeq Vault is the framework's Zeq Secure Context (ZSC) — zsc_secrets, AES-256-GCM at rest, audit-chained reads. It's exposed under /api/zsc/* (admin-gated) and mirrored by the pulse > context CLI.

# 1. Store (or replace) a secret
curl -s -X POST https://zeqsdk.com/api/zsc/set \
  -H "Authorization: Bearer $ZEQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "STRIPE_SECRET_KEY", "value": "sk_live_…" }'

# 2. Rotate — re-encrypt under a fresh IV
curl -s -X POST https://zeqsdk.com/api/zsc/rotate/STRIPE_SECRET_KEY \
  -H "Authorization: Bearer $ZEQ_API_KEY"

# 3. Read the audit chain for that secret (--verify re-derives every proof)
curl -s https://zeqsdk.com/api/zsc/audit/STRIPE_SECRET_KEY \
  -H "Authorization: Bearer $ZEQ_API_KEY"

Every set / read / rotate appends a row to the secret's audit chain, stamped with the zeqond it ran at. The plaintext is never echoed back — only metadata. You can force a rotation manually as above. See pulse > context for the full CLI surface.

Extend it​

  • Threshold vault: split a secret across holders with Shamir's Secret Sharing before storing each share — standard k-of-n recovery, no special operator required.
  • Audit export: the per-secret hash chain is verifiable offline — replay the SHA-256 links to prove no row was altered or removed.
  • Master-key rotation: set ZEQ_FIELD_KEY_PREV to the old key and ZEQ_FIELD_KEY to the new one, re-encrypt on read, then drop PREV after the retention window — zero-downtime rotation.

Seeds​

  • Post-quantum at rest — AES-256-GCM is already considered post-quantum-safe for confidentiality (Grover only halves the effective key strength); the KDF and audit chain are unchanged.
  • HSM-backed master key — keep ZEQ_FIELD_KEY in an HSM or platform keystore so the master key never lands in process memory in cleartext beyond derivation.
  • Per-tenant fields — domain-separate the KDF salt per tenant so a tenant's vault key is cryptographically distinct.

Papers​

Middleware active. Kernel on the 1.287 Hz HulyaPulse. Awaiting next Zeqond.