Zelfire / ZelC Ecosystem · NIST PQC FIPS 203 • 204 • 205

Zelen Quantum Encryption

Quantum-safe object encryption for the Zelfire ecosystem.

PQC Provider liboqs
Provider Status ✓ Available
AES-256-GCM ✓ Available
Security Mode Production
PQC Provider liboqs
Default Profile ZELEN-PQ5
KEM Algorithm ML-KEM-1024
Signature Algorithm ML-DSA-87
AEAD Cipher ✓ AES-256-GCM
ZelEn armored protocol powered by ML-KEM and ML-DSA NIST engines

Capabilities

Full post-quantum object security with native key file formats

ML-KEM Key Encapsulation

NIST FIPS 203 — ML-KEM-768 (Level 3) and ML-KEM-1024 (Level 5). IND-CCA2 secure against quantum adversaries.

ML-DSA Digital Signatures

NIST FIPS 204 — ML-DSA-65 and ML-DSA-87. EUF-CMA secure lattice-based signatures. Optional SLH-DSA secondary layer.
🔒

AES-256-GCM Encryption

96-bit nonce, 128-bit authentication tag. AAD binds ciphertext to the full ZelEn header. Fail-closed on auth failure.
🔑

Native Key Formats

.zkey (passphrase-protected private key), .zpub (public key bundle), .zcert (quantum-safe certificate). Argon2id key protection.
📦

.zelen Containers

Self-describing encrypted objects. Binary header with ZELEN magic and ZELC brand marker at offset 0x7D. Suite-agile, forward-compatible.
🧬

HKDF Key Schedule

Domain-separated HKDF-SHA256. Length-prefixed canonical encoding prevents concatenation ambiguity. Separate keys for payload, header auth, and signature binding.
🛡

Security Suite Profiles

ZELEN-PQ3 (Suite 0x0100), ZELEN-PQ5 (0x0101, default), ZELEN-PQ5-SLH (0x0102 with SLH-DSA). Suite negotiation in header.
📋

Audit Logging

Structured audit events for key gen, encrypt, decrypt. Zero-secret logging policy — keys, passphrases, and plaintext are never logged.
ZelEn shield protecting harvest-resistant encrypted archives
Encrypted today, safe tomorrow: harvest-resistant .zelen archives.
ZelEn lifecycle from key generation through encryption, signing, verification, decryption, and tamper test
A complete lifecycle from keys to tamper rejection.

Cryptographic Foundations

The mathematical structures underpinning quantum-safe security

ZelEn PQ5 bridge carrying protected data past RSA and ECC quantum risk
Module Learning With Errors — ML-KEM hardness assumption
Given and , recovering is computationally infeasible. Resistant to quantum attacks via Grover and Shor algorithms.
Key Encapsulation — IND-CCA2 security
Encapsulation produces a shared secret and ciphertext . Only the holder of the secret key can decapsulate.
Fiat-Shamir with Aborts — ML-DSA signature
Signature validity requires . The abort mechanism prevents secret key leakage through side channels.
HKDF-SHA256 — Domain-separated key schedule
Each derived key uses a unique label, preventing cross-context key reuse across payload encryption, header authentication, and signature binding.
AES-256-GCM — Authenticated encryption
96-bit nonce, 128-bit authentication tag. Additional authenticated data binds the ciphertext to the full ZelEn container header.
Security advantage bound
Adversarial advantage is negligible. Classical security ≥ 256-bit, quantum security ≥ 128-bit (NIST Level 5).

Security Invariants

Hard guarantees enforced by the protocol

ZELC anchor at offset 0x7D making ZelEn objects visible to SIEM and DLP tooling
The ZELC marker anchors object identity at offset 0x7D.
ZelEn fail-closed validation rejecting unauthenticated objects before plaintext release
Authentication must pass before plaintext can be released.
  • ZELEN magic verified at offset 0x00 before any processing
  • ZELC brand marker verified at exact offset 0x7D — any deviation rejects the container
  • KEM ciphertext integrity verified against digest in header before decapsulation
  • Header authentication tag verified constant-time before AES-GCM decryption
  • AES-256-GCM authentication tag verified — plaintext released only on success
  • No plaintext oracle — production errors are generic, reveal no oracle information
  • Nonces never reused — fresh random 96-bit nonce per encryption
  • Private keys never stored on server — returned as download only
  • Canonical encoding on all multi-field KDF inputs — no ambiguous concatenation
  • CSRF protection on all forms — constant-time token comparisons
  • Mock provider disabled in production environments
  • Upload extension whitelist — only .zpub, .zkey, .zcert, .zelen accepted
  • Rate limiting on all crypto operations
  • Temporary files use unpredictable names and are securely deleted after use