A bounded time period during which a single ephemeral key pair is valid for signing. When the epoch ends (by time, by operation count, or by policy), the epoch key is destroyed and a new one is derived. Epochs are identified by a monotonically increasing counter that never resets.
A secret key stored inside a Trusted Execution Environment (TEE). The VaultKey is non-exportable — it can be used for cryptographic operations inside the TEE but cannot be read out to main memory. It is the critical ingredient for Post-Compromise Security: because the attacker cannot access the VaultKey, they cannot predict future states after a Phoenix refresh.
The process of rotating the VaultKey with fresh entropy generated inside the TEE. After a refresh, all future key derivations change unpredictably. This is the mechanism that provides PCS: it “heals” the system after compromise by introducing entropy the attacker cannot control.
The deterministic state evolution function at PhoenixSig’s core. It advances the internal state with each signing operation using lattice-based mathematics. DyLWE provides forward secrecy (past states cannot be recovered) and eliminates dependency on external random number generators.
The internal seed value that represents the current state of the DyLWE core. It evolves irreversibly with each operation. Combined with VaultKey, it determines all ephemeral signing keys.
The root of the Merkle tree that commits to all epoch public keys. This is the only value a verifier needs to validate any signature produced by the device. It’s the public identity of the PhoenixSig instance.
A proof that a specific epoch public key belongs to the Merkle tree with root RootPK. Each signature includes this path so verifiers can confirm the signing key is legitimate without knowing all epoch keys in advance.
A defensive state entered after reboot, suspected compromise, or loss of sync. While quarantined, the device will not sign real payloads — it only produces diagnostic/ping signatures. The device exits quarantine after a successful Phoenix refresh confirms the VaultKey is intact.
The guarantee that epoch and counter values only increase. The system rejects any attempt to use a state from a previous epoch or counter. If hardware supports it, a TEE-backed monotonic counter enforces this at the hardware level.
The architectural invariant that every cryptographic operation — key derivation, state evolution, context hashing — must include the current VaultKey as an input. Violating this rule breaks PCS. It is the single most important design constraint in PhoenixSig.
| Property | Mechanism | What It Protects |
|---|---|---|
| Forward Secrecy | DyLWE one-way evolution | Past signatures & keys |
| Post-Compromise Security | Phoenix refresh (VaultKey rotation) | Future signatures after breach |
| Quantum Resistance | ML-DSA / SLH-DSA + lattice-based hardness | Against quantum adversaries |
| Ephemeral Keys | Epoch-based key derivation | Limits scope of any compromise |
| Anti-Rollback | Monotonic counters + state rejection | Against state replay attacks |
| Verifier Simplicity | Merkle tree commitment | One root key verifies all epochs |