Summary
I’m proposing a new ERC that defines a standard interface for on-chain registration, rotation, revocation, and migration of post-quantum cryptographic keys — specifically NIST-standardized algorithms: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
This is not a proposal to replace secp256k1 at the protocol level. It’s a parallel post-quantum identity layer that any contract can opt into today, without waiting for a consensus hard fork.
Repository: https://github.com/Valisthea/styx-erc-pq-key-registry Author: Valisthea (@Valisthea) Related: ERC: Encrypted Token Standard, ERC: Cryptographic Amnesia Interface, ERC: FHE Computation Verification (submitted separately)
The Problem
Every cryptographic primitive Ethereum relies on is broken by a sufficiently powerful quantum computer running Shor’s algorithm: secp256k1 (transaction signatures), ECDH (key exchange), BN254 and BLS12-381 (ZK proof pairings).
This isn’t theoretical anxiety. Three concrete threats exist today:
-
Harvest-now-decrypt-later. Nation-state adversaries are recording encrypted traffic and signed transactions right now. When quantum computers arrive, they retroactively break everything. Every public key ever exposed on-chain reveals its private key. Every signed transaction is forgeable. Data encrypted today with classical schemes is already compromised against a future quantum attacker.
-
No standard PQ key infrastructure. Several projects have experimented with post-quantum signatures on Ethereum (XMSS in EF research, Dilithium in experimental wallets, hybrid signature schemes in academic papers). But there is no standard way to register, discover, rotate, or verify a PQ key on-chain. Each project invents its own registry. Wallets can’t interoperate. Protocols can’t query PQ keys for an arbitrary address.
-
FHE key exchange is quantum-vulnerable. FHE schemes (TFHE, BFV) use lattice-based encryption that is believed quantum-resistant. But establishing the shared FHE key often relies on classical ECDH — a quantum-vulnerable step. You can have the most quantum-safe encryption in the world, and still lose everything at the key exchange. Kyber (ML-KEM) solves this, but nobody has standardized where Kyber keys live on-chain.
-
Regulatory pressure. NIST finalized PQ standards in 2024. NSA CNSA 2.0 mandates PQ transition for national security systems. EU ENISA published PQ migration guidelines. Financial institutions on blockchain will need auditable proof of PQ key deployment. There’s no standard to point to.
What This Standard Does
A registry where any Ethereum address can register PQ key pairs with a full lifecycle:
REGISTERED → ACTIVE → ROTATED → REVOKED
REGISTERED — key is on-chain but not yet the active key for its owner/algorithm pair. Useful for pre-staging backup keys before a key ceremony.
ACTIVE — the current key for this owner, algorithm, and purpose (signature or encapsulation). Only one active key per (owner, algorithm, purpose) tuple.
ROTATED — replaced by a newer key. Still valid for verifying historical signatures. A Dilithium signature made on Monday should still verify on Friday, even if the key was rotated on Wednesday.
REVOKED — permanently invalidated. May indicate compromise. Historical signatures under a revoked key should be treated as suspect.
Core Interface
solidity
interface IERCWWWW {
// Registration with proof-of-possession
function registerPQKeyWithProof(
address owner, bytes4 algorithm, KeyPurpose purpose,
bytes calldata publicKey, bytes calldata proofOfPossession,
uint256 validityPeriod
) external returns (bytes32 keyId);
// Lifecycle
function activateKey(bytes32 keyId) external;
function rotateKey(bytes32 oldKeyId, bytes32 newKeyId) external;
function revokeKey(bytes32 keyId, RevocationReason reason) external;
// Queries
function activeKeyFor(address owner, bytes4 algorithm, KeyPurpose purpose) external view returns (bytes32);
function publicKeyOf(bytes32 keyId) external view returns (bytes memory);
function isKeyUsable(bytes32 keyId) external view returns (bool);
function rotationChain(bytes32 keyId) external view returns (bytes32[] memory);
// Algorithm support
function isAlgorithmSupported(bytes4 algorithm) external view returns (bool);
function expectedKeySize(bytes4 algorithm) external view returns (uint256);
}
Algorithm Identifiers
solidity
// Key Encapsulation — FIPS 203 (ML-KEM / Kyber)
bytes4 ALG_ML_KEM_512 = 0x4B454D31; // NIST Level 1
bytes4 ALG_ML_KEM_768 = 0x4B454D33; // NIST Level 3
bytes4 ALG_ML_KEM_1024 = 0x4B454D35; // NIST Level 5
// Digital Signatures — FIPS 204 (ML-DSA / Dilithium)
bytes4 ALG_ML_DSA_44 = 0x44534132; // NIST Level 2
bytes4 ALG_ML_DSA_65 = 0x44534133; // NIST Level 3
bytes4 ALG_ML_DSA_87 = 0x44534135; // NIST Level 5
// Hash-Based Signatures — FIPS 205 (SLH-DSA / SPHINCS+)
bytes4 ALG_SLH_DSA_128 = 0x534C4831; // NIST Level 1
bytes4 ALG_SLH_DSA_192 = 0x534C4833; // NIST Level 3
bytes4 ALG_SLH_DSA_256 = 0x534C4835; // NIST Level 5
Extensions
Dual-Signing — verifyDualSignature() verifies both a classical secp256k1 signature AND a PQ signature on the same EIP-712 digest. Defense-in-depth for the transition period: even if one scheme is broken, the other still protects. isDualSignReady(address) checks if an account has both key types active.
Key Attestation — third-party attestations about key quality. An HSM manufacturer attests “this key was generated inside a FIPS 140-3 validated module.” An auditor attests “this key was generated with proper entropy.” On-chain attestation types: HSM_GENERATED, FIPS_VALIDATED, AUDITED, ENTROPY_PROOF.
Key Design Decisions
Proof-of-possession on registration. The registrant must sign a canonical message with the PQ private key being registered. This proves: (a) they own the corresponding private key, (b) the key is functional, (c) the public key bytes are well-formed. Without this, the registry could be polluted with invalid or malicious keys.
Key ID computed on-chain. keyId = keccak256(chainId, contractAddress, owner, algorithm, keccak256(publicKey)). Non-predictable, non-spoofable, no front-running. Lesson applied from our other ERC submissions.
Key expiration. Optional validityPeriod on registration. A key registered in 2026 with ML-DSA-44 (NIST Level 2) may not be sufficient in 2036. Expiration forces periodic rotation, which is standard practice in PKI (X.509 certificates have validity periods).
Revocation reason enum, not string. KEY_COMPROMISED, ALGORITHM_DEPRECATED, OWNER_REQUEST, GOVERNANCE_ACTION, SUPERSEDED. Gas-efficient, indexable, machine-readable.
On-chain PQ signature verification is optional. Dilithium-3 verification costs ~1.5M gas. SLH-DSA-256f costs 10M+. For most use cases, you query the public key on-chain and verify off-chain. On-chain verification is a separate extension for the rare case where trustless on-chain verification is required (e.g., releasing funds based on a PQ signature).
Multiple algorithms, not just one. Kyber for key exchange (FHE key distribution, encrypted messaging). Dilithium for fast general-purpose signatures. SLH-DSA for maximum conservative security — hash-based, no lattice assumptions, survives even if lattice problems are broken. Different use cases need different tools.
Interaction with Other Standards
This is the key infrastructure layer (Fortress / L0) of the STYX Protocol stack:
With the Encrypted Token Standard: FHE key exchange uses Kyber. Users register ML-KEM-1024 keys in this registry. The FHE co-processor looks up the key via activeKeyFor(), performs Kyber encapsulation to establish a shared secret, and uses it for re-encryption of FHE outputs.
With the Cryptographic Amnesia Interface: Custodians in the amnesia ceremony register Dilithium keys here. Destruction proofs are signed with PQ signatures instead of secp256k1. This ensures the ceremony remains valid against quantum adversaries.
With the FHE Computation Verification Standard: ZK proof systems used in the verification standard (Nova, Halo2) rely on elliptic curve pairings (BN254, BLS12-381) which are quantum-vulnerable. When PQ-safe proof systems mature, the verification standard can reference PQ keys from this registry for prover authentication.
Prior Art
-
EIP-7212 — precompile for secp256r1 (P-256) signature verification. Classical curve, not PQ. But the pattern (on-chain verification of non-native signatures) is relevant.
-
EIP-7560 research — Ethereum protocol-level PQ signature research. Years from deployment. This standard provides application-level PQ keys today.
-
ERC-6492 — signature validation for pre-deployed contracts. Addresses the “which key signed this?” question but for classical ECDSA only.
-
Account Abstraction (ERC-4337) — enables smart wallets with custom signature verification. PQ signatures could be verified in a 4337 wallet’s
validateUserOp. This registry provides the key lookup that such a wallet would need. -
NIST PQC standardization — FIPS 203/204/205 finalized August 2024. No existing ERC references these standards.
No ERC currently addresses post-quantum key management. This is the first.
Questions for the Community
-
Minimum NIST level — should the standard enforce a minimum security level? Level 3 is the sweet spot (security vs. performance). Level 1 is faster but potentially insufficient long-term. Level 5 is maximum security but expensive. What should the RECOMMENDED minimum be?
-
FALCON support — NIST is expected to standardize FALCON as an additional signature algorithm (smaller signatures than Dilithium: 666 bytes vs 3,309 bytes). Should we reserve an algorithm ID for it now, or wait for official standardization?
-
Key storage vs. key hash — PQ public keys are large (up to 2,592 bytes for ML-DSA-87). Full on-chain storage costs ~100K gas per registration. Alternative: store only the hash, require the full key at verification time. The full-storage approach enables on-chain verification without the caller providing the key. Which model does the community prefer?
-
Cross-chain key portability — should a PQ key registered on Ethereum mainnet be automatically recognized on L2s? Or should each chain maintain an independent registry? A cross-chain relay mechanism adds complexity but improves UX.
-
Protocol-level PQ readiness — when Ethereum eventually migrates to PQ signatures at the protocol level, this registry could serve as the existing key infrastructure. Should the standard be designed with this future migration in mind? Specifically, should there be a
migrateToProtocol()function that locks the registry key and signals readiness for protocol-level adoption? -
ERC-4337 integration — smart wallets using Account Abstraction could use this registry for PQ signature verification in
validateUserOp. Should the standard include a reference implementation showing this integration, or keep it out of scope? -
Quantum timeline — this is less of a technical question and more of a practical one. The standard is designed for gradual adoption. But how urgently should projects be registering PQ keys? For those tracking the quantum computing landscape: what’s your current estimate for cryptographically relevant quantum computers?
The PQ transition is coming. The question is whether Ethereum has standard infrastructure ready when it arrives, or whether every project scrambles to build ad-hoc solutions under pressure. This standard is the infrastructure.
— Valisthea