A comprehensive technical overview of the first digital signature system engineered for Post-Compromise Security — combining post-quantum cryptography, deterministic state evolution, and hardware-anchored entropy injection.
Current digital signature schemes — including NIST post-quantum standards ML-DSA and SLH-DSA — operate under the assumption that private keys remain uncompromised throughout their lifetime. When this assumption fails, the consequences are catastrophic: all signatures become suspect, and recovery requires out-of-band certificate revocation that can take hours or days.
PhoenixSig introduces a fundamentally different approach. Rather than treating compromise as a terminal event, PhoenixSig treats it as an operational certainty that the system must survive. The system achieves this through three interlocking mechanisms: a post-quantum signing engine (ML-DSA / SLH-DSA), a deterministic state evolution core based on Dynamic Learning With Rounding (DyLWE), and a hardware-anchored entropy injection system called Phoenix Injection.
Together, these components deliver Post-Compromise Security (PCS) — the guarantee that even after full state compromise, the system autonomously recovers and locks out the attacker without human intervention.
Every deployed digital signature system today relies on a single, long-lived private key. This creates a single point of failure that, once breached, invalidates the entire trust model. The private key is typically stored for months or years, creating an extended attack window.
Standard mitigations — Hardware Security Modules (HSMs), secure enclaves, key rotation policies — reduce the probability of compromise but do not address what happens when compromise inevitably occurs.
When a key is known to be compromised, the only recourse is certificate revocation. This process is fundamentally broken for high-stakes environments:
Harvest-now-decrypt-later (HNDL) attacks compound the problem. An adversary who captures encrypted communications today can decrypt them when quantum computers become available. For signatures, this means current key compromises become exponentially more dangerous.
The fundamental problem is not that keys might be compromised — it's that current systems have no recovery path when they are. PhoenixSig is designed for environments where compromise is an operational certainty.
PhoenixSig reframes digital signatures from a static cryptographic primitive to a dynamic, evolving process:
A signature is not an algorithm. It is a temporal process — each signature is a transient slice of an evolving state, expendable by design, but the system as a whole is engineered to always recover.
Every signing key is ephemeral, bound to a specific epoch, and destroyed after use. There is no "master key" whose compromise destroys the system.
The system state advances irreversibly with each operation. An attacker who captures a state snapshot cannot roll back to a previous state or replay past operations.
Post-Compromise Security requires entropy that the attacker cannot access or predict. This entropy is anchored in Trusted Execution Environment (TEE) hardware — a non-exportable secret that only the legitimate device can use for recovery.
PhoenixSig consists of three tightly-coupled layers. Each layer serves a distinct purpose, but they are inseparable — removing any one layer destroys the PCS guarantee.
The bottom layer is a pluggable post-quantum signature algorithm. PhoenixSig currently supports ML-DSA-65 (formerly CRYSTALS-Dilithium) as the primary signer and SLH-DSA (formerly SPHINCS+) as a conservative fallback.
PhoenixSig does not modify these algorithms. They are used as standardized, NIST-approved primitives. Phoenix manages everything above the cryptographic operation.
The middle layer manages deterministic, forward-only state evolution. It derives epoch-specific signing keys from the current state without external randomness. Detailed in Section 4.
The top layer provides hardware-anchored entropy that makes PCS possible. A VaultKey stored in a TEE injects fresh entropy into every derivation. Detailed in Section 5.
A naive approach to ephemeral keys would call the OS random number generator for each epoch. This fails in several ways: the output cannot be audited or reproduced, it's vulnerable to RNG manipulation, and provides no formal structure for security proofs.
DyLWE provides a deterministic state machine whose evolution is mathematically structured, auditable, and provably forward-secure.
The core uses Learning With Rounding (LWR) rather than Learning With Errors (LWE), eliminating noise sampling and making evolution fully deterministic.
DeviceState {
state_seed // Internal evolution seed
epoch // Monotonic epoch identifier
counter // Per-epoch operation counter
quarantine_flag // Security state indicator
}sigma' = StateEvolve(VaultKey, sigma, ctx)
ctx = ContextDerive(epoch, counter, message, policy)Critical property: the old sigma is immediately erased. There is no path from sigma' back to sigma.
Every hash, KDF, PRF, and state evolution in PhoenixSig must depend on the current VaultKey. If any derivation bypasses VaultKey, PCS is broken.
Each device contains a VaultKey stored inside a Trusted Execution Environment. The VaultKey is non-exportable (cannot leave the TEE), attestable (TEE can prove integrity), and mutable (can be refreshed with new entropy).
VaultKey ← Refresh(VaultKey, new_entropy)After refresh: all future derivations change completely, pre-refresh state snapshots become useless, and the system has risen from the ashes.
DyLWE provides forward security — past states cannot be recovered. But if an attacker captures the full state at time t₀, they can compute all future states deterministically. Only VaultKey refresh breaks this chain.
Given an adversary with a complete state snapshot at t₁, after Phoenix refresh at t₂ > t₁, the adversary cannot: forge any signature for epoch e > e(t₂), predict any signing key for future epochs, or distinguish future signing keys from random.
PCS does not cover persistent physical device capture with ongoing TEE access. PhoenixSig is designed for scenarios where compromise is temporary or detectable — the overwhelming majority of real-world breach scenarios.
seed_epoch = DeriveEpochSeed(VaultKey, sigma, ctx)
(sk_epoch, pk_epoch) = PQC.KeyGen(seed_epoch)All epoch public keys are committed to a Merkle tree. The root hash RootPK serves as the device's long-term identity. Each signature includes the PQC signature, the epoch public key, and a Merkle authentication path.
A verifier needs only RootPK (published once) to verify any signature from the device, regardless of which epoch produced it.
| Property | Traditional PKI | Standalone PQC | PhoenixSig |
|---|---|---|---|
| Quantum Resistant | ✗ | ✓ | ✓ |
| Forward Security | ✗ | ✗ | ✓ |
| Post-Compromise Security | ✗ | ✗ | ✓ |
| No Long-Lived Keys | ✗ | ✗ | ✓ |
| Automatic Recovery | ✗ | ✗ | ✓ |
| Hardware-Anchored Entropy | Optional | Optional | Required |
Foundational architecture with state evolution, epoch-based signing, entropy injection, and security property verification.
Full NIST PQC backend integration with production-grade implementations and invariant verification.
Trusted Execution Environment integration, remote attestation, and deployment hardening.
Multi-platform SDK, partner integrations, and compliance certification processes.