Executive Summary
JIL Sovereign's post-quantum epoch registry is a signing-epoch authority that issues "hybrid receipts" binding an attested subject to two independent proofs: a classical Ed25519 signature over a canonical message, and a SHA3-512 hash commitment computed over that message concatenated with the classical signature bytes. The commitment is not itself a post-quantum signature - it is deliberately framed and implemented as a hash-commitment fallback, an interim hedge that keeps a receipt's integrity provable even after a future quantum adversary breaks Ed25519, pending a full migration to a lattice-based signature scheme (such as ML-DSA/Dilithium) once production-grade tooling for that scheme has stabilized.
Every receipt is anchored to a specific signing epoch in a rotating chain, where each epoch carries its own classical and post-quantum key hints and its own signature over the epoch's binding string. Rotation retires the prior epoch and activates a new one, so the registry's key material - and the receipts issued under a given epoch - form a verifiable, ordered chain rather than a single static keypair.
Problem Statement
Migrating live attestation infrastructure directly to a lattice-based post-quantum signature scheme today means adopting cryptographic libraries and toolchains that are still maturing industry-wide for production signing workloads. Doing nothing instead leaves every classical-only signed attestation permanently unable to prove its own authenticity once a cryptographically relevant quantum computer arrives - a "harvest now, decrypt or forge later" exposure window for anything signed today that needs to remain provable for years. Attestation systems need a way to hedge against that future break now, without waiting for PQ signature tooling to fully mature, and without misrepresenting an interim hedge as a finished PQ signature scheme.
Why Existing Solutions Are Insufficient
- Pure-classical Ed25519/ECDSA attestation registries: carry no post-quantum hedge at all - once the classical scheme is broken, every historical signature it produced becomes forgeable with no fallback integrity check.
- Early lattice-signature adopters: real ML-DSA/Dilithium libraries exist, but production-grade, audited implementations for high-throughput signing infrastructure are still stabilizing industry-wide - premature adoption risks shipping unvetted cryptographic code into a live attestation path.
- Hash-based signature schemes alone (SPHINCS+-style): genuinely post-quantum-secure, but stateless hash-signature sizes and verification latency are heavy for a per-transaction attestation registry issuing high volumes of receipts.
- No-epoch static-key registries: a single long-lived keypair with no rotation chain has no structured way to bound which signing period a given receipt belongs to, or to retire compromised key material in an auditable sequence.
Technical Architecture
Signing-Epoch Chain
| Field | Purpose |
|---|---|
epoch_id / epoch_number | Identifier and monotonically increasing sequence position |
algorithm | Hybrid scheme tag identifying the classical + hash-commitment construction in use |
| Classical key hint | SHA3-256-derived hint over the epoch id and the classical public key |
| PQ key hint | SHA3-256-derived hint reserved for the post-quantum key material slot |
| Content hash | SHA3-256 hash of the full epoch payload |
| Epoch signature | Classical detached signature over the epoch's canonical binding string |
Rotating to a new epoch retires the currently active epoch and activates the new one with an incremented epoch number, so exactly one epoch is authoritative at any moment and every prior epoch remains in the historical chain rather than being deleted.
Hybrid Receipt Issuance
For a given subject, the registry builds a canonical message binding the receipt id, subject id, active epoch id, a payload hash, and a timestamp. Two independent proofs are then computed over that canonical message: a classical detached signature, and the post-quantum hash-commitment fallback - a hash of the message bytes concatenated with the classical signature bytes. Binding the commitment to the classical signature itself (not just the message) means the commitment also certifies which specific signature accompanied the message, not merely that the message existed.
Independent Dual-Path Verification
Verifying a stored receipt reconstructs the canonical message, checks the classical signature independently, and separately recomputes the hash commitment to confirm it still matches - reporting both results distinctly rather than collapsing them into one pass/fail flag, so a caller can distinguish "the classical signature no longer validates" from "the commitment binding is broken" if the two ever diverge. Verification additionally requires the receipt's bound epoch to still be the currently active epoch, tying every receipt's validity to a specific, identifiable point in the rotation chain.
Why a Hash Commitment, Not a Placeholder Signature
The fallback is deliberately built as a hash commitment rather than a simulated or placeholder signature scheme: SHA3-512 preimage resistance is not meaningfully weakened by Shor's algorithm, only subject to the generic quadratic Grover speedup, which remains computationally infeasible at a 512-bit output width. That means the commitment continues to serve as a valid integrity proof of "this exact message was signed with this exact classical signature at this exact epoch" even in a future where the classical signature scheme itself has been broken by a quantum adversary - it just does not, on its own, prove authorship the way a genuine lattice-based signature would.
Prior Art Differentiation
| Approach | PQ Hedge At All? | Production-Ready Today? | Epoch-Rotated Key Material? | Per-Receipt Throughput Suitable? |
|---|---|---|---|---|
| Pure-classical registry (Ed25519/ECDSA only) | No | Yes | Implementation-dependent | Yes |
| Early lattice-signature adopters | Yes, genuine PQ | Still stabilizing industry-wide | Implementation-dependent | Implementation-dependent |
| Stateless hash-based signatures (SPHINCS+-style) | Yes, genuine PQ | Yes | Implementation-dependent | Heavy for high-volume per-transaction use |
| Static single-keypair registry | No | Yes | No | Yes |
| JIL Sovereign PQ Epoch Registry | Interim hash-commitment hedge | Yes, lightweight and deployable now | Yes, rotating chain | Yes, low per-receipt cost |