Encryption at Rest

Fystack implements comprehensive encryption at rest using a KEK/DEK (Key Encryption Key / Data Encryption Key) architecture. Every sensitive payload is encrypted before it ever touches disk. Data Encryption Keys (DEKs) are used to encrypt individual records or blobs, while the Key Encryption Key (KEK), securely stored in a vault such as AWS Secrets Manager is used to wrap and protect the DEKs. This ensures that even in the event of full database or backup exfiltration, only ciphertext is exposed, preserving confidentiality end-to-end.

The flow mirrors industry security standards, meeting FIPS 197 and NIST SP 800-38D requirements for AES-GCM and satisfying PCI DSS and GDPR Article 32 mandates for protecting sensitive data at rest.

New to KEK/DEK layering? Read our blog primer: DEK/KEK: The industry standard to protect highly sensitive data (Part 1).

1. Overview

Every sensitive value is encrypted using AES-256-GCM and stored inside a versioned envelope that tracks algorithm choices and key versions. Workspace isolation, per-chain derivation, and vault-backed master keys combine to keep data sealed even if infrastructure is breached.

Why AES-256-GCM?

1. NIST Approved: Federal encryption standard (FIPS 197).
2. Authenticated Encryption: Simultaneous confidentiality and integrity.
3. Performance: Hardware acceleration via AES-NI on modern CPUs.
4. Industry Standard: Used by AWS, Google Cloud, Azure for data-at-rest.

2. What Data Is Encrypted

• Private keys and seeds: All wallet material for Hyper wallets is encrypted before storage using workspace-specific DEKs.

• User credentials: TOTP secrets and other authentication artifacts ride the same DEK/KEK architecture to remain sealed at rest.

Envelope Format

Each ciphertext includes the algorithm identifier, version metadata, derivation context, and payload. This enables algorithm agility, backward compatibility, and full provenance for every encrypted record.