ERC-8231：後量子密鑰註冊表

摘要

我提議一項新的 ERC，旨在定義一個標準介面，用於後量子加密金鑰的鏈上註冊、輪換、撤銷與遷移——特別是 NIST 標準化的演算法：ML-KEM (FIPS 203)、ML-DSA (FIPS 204) 以及 SLH-DSA (FIPS 205)。

這項提案並非要在協議層級取代 secp256k1，而是一個平行的後量子身份層，任何合約今日即可選擇加入，無需等待共識層的硬分叉。

程式碼庫： https://github.com/Valisthea/styx-erc-pq-key-registry
作者： Valisthea (@Valisthea)
相關提案： ERC: 加密代幣標準、ERC: 加密遺忘介面、ERC: FHE 計算驗證（另行提交）

問題所在

以太坊所依賴的每一種加密原語，在運行 Shor 演算法且足夠強大的量子電腦面前都會被破解：包括 secp256k1（交易簽名）、ECDH（金鑰交換）、BN254 與 BLS12-381（ZK 證明配對）。

這並非理論上的焦慮，目前存在三個具體的威脅：

• 現在收集，稍後解密 (Harvest-now-decrypt-later)。 國家級對手目前正在記錄加密流量和已簽名的交易。當量子電腦出現時，他們可以追溯性地破解一切。任何曾在鏈上暴露的公鑰都會洩露其私鑰。每一筆已簽名的交易都可被偽造。今日使用傳統方案加密的數據，在未來的量子攻擊者面前已經處於受損狀態。

• 缺乏標準的後量子（PQ）金鑰基礎設施。 雖然已有數個專案在以太坊上實驗後量子簽名（EF 研究中的 XMSS、實驗性錢包中的 Dilithium、學術論文中的混合簽名方案），但目前尚無在鏈上註冊、發現、輪換或驗證 PQ 金鑰的標準方式。每個專案都自行開發註冊表，導致錢包無法互操作，協議也無法查詢任意地址的 PQ 金鑰。

• FHE 金鑰交換存在量子漏洞。 全同態加密（FHE）方案（如 TFHE、BFV）使用被認為具備量子抗性的格基加密（lattice-based encryption）。然而，建立共享 FHE 金鑰通常依賴傳統的 ECDH——這是一個易受量子攻擊的步驟。即使你擁有世界上最安全的量子加密技術，仍可能在金鑰交換階段失去一切。Kyber (ML-KEM) 解決了這個問題，但目前尚未有人標準化 Kyber 金鑰在鏈上的存放位置。

• 監管壓力。 NIST 於 2024 年敲定了 PQ 標準。美國國家安全局（NSA）的 CNSA 2.0 強制要求國家安全系統進行 PQ 轉型。歐盟 ENISA 發布了 PQ 遷移指南。區塊鏈上的金融機構將需要可審計的 PQ 金鑰部署證明。目前尚無可供參考的標準。

此標準的功能

一個允許任何以太坊地址註冊 PQ 金鑰對並具備完整生命週期的註冊表：

REGISTERED（已註冊） → ACTIVE（啟用） → ROTATED（已輪換） → REVOKED（已撤銷）

REGISTERED — 金鑰已在鏈上，但尚未成為其所有者/演算法組合的活動金鑰。適用於在金鑰儀式前預先部署備用金鑰。

ACTIVE — 該所有者、演算法及用途（簽名或封裝）的當前金鑰。每個（所有者、演算法、用途）元組僅能有一個活動金鑰。

ROTATED — 已被新金鑰取代。對於驗證歷史簽名仍然有效。週一生成的 Dilithium 簽名在週五仍應能通過驗證，即使金鑰在週三已輪換。

REVOKED — 永久失效。可能表示金鑰已洩露。使用已撤銷金鑰簽署的歷史簽名應被視為可疑。

核心介面

interface IERCWWWW {
    // 帶有持有證明的註冊
    function registerPQKeyWithProof(
        address owner, bytes4 algorithm, KeyPurpose purpose,
        bytes calldata publicKey, bytes calldata proofOfPossession,
        uint256 validityPeriod
    ) external returns (bytes32 keyId);
    
    // 生命週期管理
    function activateKey(bytes32 keyId) external;
    function rotateKey(bytes32 oldKeyId, bytes32 newKeyId) external;
    function revokeKey(bytes32 keyId, RevocationReason reason) external;
    
    // 查詢功能
    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);
    
    // 演算法支持
    function isAlgorithmSupported(bytes4 algorithm) external view returns (bool);
    function expectedKeySize(bytes4 algorithm) external view returns (uint256);
}

演算法識別碼

// 金鑰封裝 — FIPS 203 (ML-KEM / Kyber)
bytes4 ALG_ML_KEM_512  = 0x4B454D31;  // NIST 第 1 級
bytes4 ALG_ML_KEM_768  = 0x4B454D33;  // NIST 第 3 級
bytes4 ALG_ML_KEM_1024 = 0x4B454D35;  // NIST 第 5 級

// 數位簽名 — FIPS 204 (ML-DSA / Dilithium)
bytes4 ALG_ML_DSA_44   = 0x44534132;  // NIST 第 2 級
bytes4 ALG_ML_DSA_65   = 0x44534133;  // NIST 第 3 級
bytes4 ALG_ML_DSA_87   = 0x44534135;  // NIST 第 5 級

// 基於雜湊的簽名 — FIPS 205 (SLH-DSA / SPHINCS+)
bytes4 ALG_SLH_DSA_128 = 0x534C4831;  // NIST 第 1 級
bytes4 ALG_SLH_DSA_192 = 0x534C4833;  // NIST 第 3 級
bytes4 ALG_SLH_DSA_256 = 0x534C4835;  // NIST 第 5 級

擴展功能

雙重簽名 (Dual-Signing) — verifyDualSignature() 同時驗證同一個 EIP-712 摘要的傳統 secp256k1 簽名與 PQ 簽名。這是過渡時期的深度防禦：即使其中一種方案被破解，另一種仍能提供保護。isDualSignReady(address) 用於檢查帳戶是否已啟用這兩種類型的金鑰。

金鑰證明 (Key Attestation) — 關於金鑰品質的第三方證明。HSM 製造商證明「此金鑰是在 FIPS 140-3 認證模組內生成的」。審計師證明「此金鑰是使用適當的熵生成的」。鏈上證明類型包括：HSM_GENERATED、FIPS_VALIDATED、AUDITED、ENTROPY_PROOF。

關鍵設計決策

註冊時的持有證明 (Proof-of-possession)。 註冊者必須使用正在註冊的 PQ 私鑰簽署一條規範訊息。這證明了：(a) 他們擁有對應的私鑰，(b) 金鑰功能正常，(c) 公鑰位元組格式正確。若無此機制，註冊表可能會被無效或惡意金鑰污染。

鏈上計算金鑰 ID。 keyId = keccak256(chainId, contractAddress, owner, algorithm, keccak256(publicKey))。不可預測、不可偽造、防止搶先交易。這是從我們提交的其他 ERC 中吸取的教訓。

金鑰過期。 註冊時可選 validityPeriod。2026 年註冊的 ML-DSA-44 (NIST 第 2 級) 金鑰到 2036 年可能已不足夠。過期機制強制執行定期輪換，這是 PKI 的標準做法（X.509 證書皆有有效期）。

撤銷原因使用列舉 (Enum) 而非字串。 KEY_COMPROMISED（金鑰洩露）、ALGORITHM_DEPRECATED（演算法棄用）、OWNER_REQUEST（所有者請求）、GOVERNANCE_ACTION（治理行動）、SUPERSEDED（被取代）。節省 Gas、可索引且機器可讀。

鏈上 PQ 簽名驗證為選配。 Dilithium-3 的驗證成本約為 150 萬 Gas。SLH-DSA-256f 則超過 1000 萬。對於大多數案例，應在鏈上查詢公鑰並在鏈下驗證。鏈上驗證是一個獨立的擴展，僅用於少數需要去中心化鏈上驗證的場景（例如：根據 PQ 簽名釋放資金）。

支持多種演算法，而非單一演算法。 Kyber 用於金鑰交換（FHE 金鑰分發、加密通訊）。Dilithium 用於快速的通用簽名。SLH-DSA 用於極致保守的安全性——基於雜湊，不依賴格基假設，即使格基問題被破解也能生存。不同的使用場景需要不同的工具。

與其他標準的交互

這是 STYX 協議棧的金鑰基礎設施層 (Fortress / L0)：

與加密代幣標準 (Encrypted Token Standard)： FHE 金鑰交換使用 Kyber。用戶在此註冊表中註冊 ML-KEM-1024 金鑰。FHE 協處理器透過 activeKeyFor() 查找金鑰，執行 Kyber 封裝以建立共享密鑰，並將其用於 FHE 輸出的重新加密。

與加密遺忘介面 (Cryptographic Amnesia Interface)： 遺忘儀式中的託管人在此註冊 Dilithium 金鑰。銷毀證明使用 PQ 簽名而非 secp256k1 簽署。這確保了儀式在量子對手面前依然有效。

與 FHE 計算驗證標準 (FHE Computation Verification Standard)： 驗證標準中使用的 ZK 證明系統（如 Nova, Halo2）依賴於易受量子攻擊的橢圓曲線配對（BN254, BLS12-381）。當 PQ 安全的證明系統成熟時，驗證標準可以引用此註冊表中的 PQ 金鑰進行證明者身份驗證。

先前技術

• EIP-7212 — secp256r1 (P-256) 簽名驗證的預編譯。雖然是傳統曲線而非 PQ，但其模式（鏈上驗證非原生簽名）具有參考價值。
• EIP-7560 研究 — 以太坊協議層級的 PQ 簽名研究。距離部署尚需數年。本標準今日即可提供應用層級的 PQ 金鑰。
• ERC-6492 — 預部署合約的簽名驗證。解決了「哪個金鑰簽署了此內容」的問題，但僅限於傳統 ECDSA。
• 帳戶抽象 (ERC-4337) — 允許具備自定義簽名驗證功能的智能錢包。PQ 簽名可以在 4337 錢包的 validateUserOp 中進行驗證。此註冊表提供了此類錢包所需的金鑰查詢功能。
• NIST PQC 標準化 — FIPS 203/204/205 於 2024 年 8 月敲定。目前尚無 ERC 引用這些標準。

目前沒有任何 ERC 處理後量子金鑰管理。這是第一個。

社群提問

• 最低 NIST 等級 — 標準是否應強制執行最低安全等級？第 3 級是平衡點（安全性 vs 性能）。第 1 級較快但長期可能不足。第 5 級安全性最高但成本昂貴。建議的最低等級應為何？
• FALCON 支持 — 預計 NIST 將標準化 FALCON 作為額外的簽名演算法（簽名比 Dilithium 小：666 位元組 vs 3,309 位元組）。我們現在應該為其預留演算法 ID，還是等待正式標準化？
• 金鑰存儲 vs 金鑰雜湊 — PQ 公鑰體積龐大（ML-DSA-87 高達 2,592 位元組）。完整的鏈上存儲每次註冊約需 10 萬 Gas。替代方案：僅存儲雜湊，驗證時要求提供完整金鑰。完整存儲方案允許在調用者不提供金鑰的情況下進行鏈上驗證。社群偏好哪種模式？
• 跨鏈金鑰移植性 — 在以太坊主網註冊的 PQ 金鑰是否應自動在 L2 上獲得認可？還是每個鏈應維持獨立的註冊表？跨鏈中繼機制會增加複雜性，但能提升用戶體驗。
• 協議層級的 PQ 準備 — 當以太坊最終在協議層遷移到 PQ 簽名時，此註冊表可作為現有的金鑰基礎設施。本標準是否應考慮到未來的遷移？具體來說，是否應加入 migrateToProtocol() 函數來鎖定註冊表金鑰並發出協議層採用的就緒信號？
• ERC-4337 整合 — 使用帳戶抽象的智能錢包可以在 validateUserOp 中使用此註冊表進行 PQ 簽名驗證。本標準是否應包含展示此整合的參考實現，還是將其視為超出範疇？
• 量子時間線 — 這與其說是技術問題，不如說是實務問題。本標準旨在逐步採用。但專案註冊 PQ 金鑰的緊迫性如何？對於追蹤量子運算進展的人士：您目前對具備加密威脅能力的量子電腦出現時間的估計為何？

PQ 轉型即將到來。問題在於，當它到來時，以太坊是否已準備好標準化的基礎設施，還是每個專案都要在壓力下倉促構建臨時方案。本標準即是該基礎設施。

— Valisthea

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8231-post-quantum-key-registry/28235)