Cryptographic Architecture
How Abundera protects data at rest and in transit — platform-native cryptography with zero third-party dependencies.
Encryption at Rest
AES-GCM 256-bit
Authenticated encryption for sensitive fields (financial tokens, TOTP secrets, health-related data). 12-byte random IV generated per operation — no IV reuse. Ciphertext integrity verified on every decryption.
Wire Format
IV prepended to ciphertext, Base64-encoded for storage. Self-describing format enables transparent decryption without metadata lookups.
Encryption Scope
Application-layer encryption applied selectively to Restricted-classification fields. Infrastructure-layer encryption (at-rest) covers all data stores as baseline.
Hashing & Integrity
SHA-256 with Random Salt
Backup codes and API keys hashed with 16-byte random salt before storage. One-way — original values cannot be recovered.
Constant-Time Comparison
Verification uses XOR-based constant-time comparison to prevent timing side-channel attacks. Execution time is independent of input similarity.
Session & Token Security
JWT Signing
EdDSA (Ed25519) via Web Crypto API. Deterministic signatures with no nonce-reuse risk. Public key verification without exposing private key material. Public key published at
/v1/auth/jwks in standard JWKS format.Token Lifecycle
Configurable expiry with server-side revocation via blocklist. Immediate invalidation — tokens are rejected in real time, not on natural expiry.
Key Management
Key Storage
All cryptographic keys stored in platform-managed secrets. Keys are never embedded in source code, environment files, or application configuration.
Key Isolation
Encryption keys are stored separately from encrypted data. Database access alone is insufficient to decrypt protected fields.
Key Ceremony
Formal key generation, rotation, and revocation procedures documented in a Key Ceremony protocol. 16 secrets with dual-approval requirements for production changes.
Split-Key Derivation
Two independent secrets are combined via HKDF-SHA256 — one as Input Keying Material, the other as salt — to derive the master key (RFC 5869). Compromise of either secret alone is insufficient to derive user keys. Both stored as separate Cloudflare Workers Secrets.
Per-User Key Derivation
Per-user Data Encryption Keys derived via HKDF-SHA256 from the combined master key using the user ID as context. Keys are derived at runtime and never stored. Compromise of one user's derived key does not affect other users.
Platform-Native Cryptography
Web Crypto API
All cryptographic operations use the runtime-native Web Crypto API. Zero third-party cryptography libraries in the dependency tree.
Supply Chain Benefit
No npm packages for encryption, hashing, or signing. Eliminates entire categories of supply chain risk for cryptographic operations.
Algorithm Compliance
Web Crypto implementations are FIPS-validated in major runtimes. Algorithm selection (AES-GCM, SHA-256, EdDSA/Ed25519, HKDF-SHA256) follows NIST recommendations (FIPS 186-5, SP 800-186).
Planned Improvements
- Per-user key derivation to reduce blast radius — Implemented (HKDF-SHA256)
- Split-key derivation model — Implemented (HKDF-SHA256 with IKM/salt separation)
- Audit log R2 anchoring — Implemented (hourly immutable checkpoints to R2 + GitHub dual-platform)
- Envelope encryption via AWS KMS — Implemented (DEK wrapped by KMS KEK, cross-provider trust boundary)
- JWT key rotation — Implemented (90-day automated rotation with 14-day multi-key grace period)
- Ciphertext versioning — Implemented (version-tagged format for future algorithm migration)
- AAD context binding — Implemented (all encrypted fields bound to entity-specific context strings)