Background
Cryptographically relevant quantum computer, if built, could enable Shor’s algorithm and Grover’s algorithm. These completely break ECDSA / ECDH, and reduce hash function (& cipher) strengt...

<div><h2><a href="https://ethresear.ch#p-51852-background-1" rel="nofollow"></a>Background</h2>Cryptographically relevant quantum computer, if built, could enable Shor’s algorithm and Grover’s algorithm. These completely break ECDSA / ECDH, and reduce hash function (&amp; cipher) strength from 2^n2n to 2^\frac{n}{2}2n2There are some non-obvious parts of ETH which would need to be upgraded.<h2><a href="https://ethresear.ch#p-51852-what-is-still-ok-2" rel="nofollow"></a>What is still OK</h2><ul><li>bip39 (pbkdf2-sha512) seems just fine</li></ul><h2><a href="https://ethresear.ch#p-51852-what-is-not-ok-3" rel="nofollow"></a>What is not OK</h2><ul><li>bip32 hdkey derivation<ul><li>Should be replaced by something post-quantum and better (no “non-hardened” keys)</li><li>New scheme could be based on HKDF (like EIP-2333), but not HKDF-SHA256</li><li>Alternative KDF is Blake3 in context mode (pq security is unclear)</li><li>The proposed scheme should support both ECC and new pq mode</li></ul></li><li>Transaction signing<ul><li>Should be replaced by lattice-based Falcon (FN-DSA / FIPS-206), or hash-based Sphincs-plus (SLH-DSA / FIPS-205)</li><li>New keys and signatures will consume more space</li><li>Falcon-1024 has 1.75KB keys and 1.25KB sigs</li><li>SLH-DSA-256 has 128B keys and 17KB-50KB sigs</li></ul></li><li>Sender address recovery<ul><li>It was feature of ECDSA (not available in Schnorr, for example)</li><li>Perhaps txs (and not sigs) should encode sender addresses</li></ul></li><li>Address format<ul><li>Currently it’s 40 hex characters, keccak256(pubkey)</li><li>keccak256 should be replaced by keccak512 / sha3-512 / sha512 / blake3-512</li><li>How does Grover algo affect brute-forcing of addresses? Should 40 characters be upped to 80-128?</li><li>Longer address formats should probably use something like bech32 for checksumming &amp; human-friendliness</li><li>How would new addresses interop with old addresses / EVM?</li></ul></li><li>Encrypted wallets<ul><li>Should upgrade from AES-128 to AES-256 or chacha20</li><li>HMAC-SHA256 should upgrade to HMAC-SHA512 or KMAC / blake3-512 (keyed mode)</li></ul></li><li>KZG EIP-4844 verification<ul><li>Should be replaced by a post-quantum scheme</li><li>Algorithms are unclear for now, any suggestions?</li></ul></li><li>EVM 0x20 opcode (KECCAK256)<ul><li>Should be replaced by keccak512 / sha3-512 / sha512 / blake3-512</li></ul></li><li>EVM precompile for ECRECOVER<ul><li>See address recovery above</li></ul></li><li>EVM precompiles for BN / BLS / KZG<ul><li>Should be replaced by newer schemes (unclear which ones?)</li></ul></li><li>Consensus layer signature aggregation<ul><li>Currently aggregates signatures of all validators once per epoch (6 mins)</li><li>More than 1M signatures right now?</li><li>Algorithms are unclear for now, any suggestions?</li></ul></li><li>Anything else?</li></ul><h2><a href="https://ethresear.ch#p-51852-final-thoughts-4" rel="nofollow"></a>Final thoughts</h2>I’m confident all of these problems can be solved even in limited time. Let’s start solving them.If such computer appears soon, it’s possible to do Vitalik’s trick (<a href="https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901" rel="nofollow">How to hard-fork to save most users’ funds in a quantum emergency</a>): freeze all accounts and leverage BIP39 with ZK-proofs to recover funds into new pq scheme.</div>

Tidbits of post-quantum ETH

背景
如果建成,具有密碼學意義的量子計算機可以實現Shor演算法和Grover演算法。這些演算法完全破壞了ECDSA/ECDH,並降低了雜湊函式(和密碼)的強度...

<div><h2><a href="https://ethresear.ch#p-51852-background-1" rel="nofollow"></a>背景</h2>如果建成量子計算機,它可以實現Shor演算法和Grover演算法。這些演算法可以完全破解ECDSA/ECDH,並將雜湊函式(和密碼)的強度從2^n2n降低到2^\frac{n}{2}2n2ETH中還有一些不太明顯的部分需要升級。<h2><a href="https://ethresear.ch#p-51852-what-is-still-ok-2" rel="nofollow"></a>仍然可以的部分</h2><ul><li>bip39 (pbkdf2-sha512)似乎沒有問題</li></ul><h2><a href="https://ethresear.ch#p-51852-what-is-not-ok-3" rel="nofollow"></a>不可以的部分</h2><ul><li>bip32 hdkey派生<ul><li>應該被一種後量子和更好的方案取代(沒有"非硬化"金鑰)</li><li>新方案可以基於HKDF(如EIP-2333),但不是HKDF-SHA256</li><li>另一種KDF是上下文模式的Blake3(後量子安全性不明確)</li><li>擬議的方案應該同時支援ECC和新的後量子模式</li></ul></li><li>交易簽名<ul><li>應該被基於格的Falcon(FN-DSA/FIPS-206)或基於雜湊的Sphincs-plus(SLH-DSA/FIPS-205)取代</li><li>新的金鑰和簽名將佔用更多空間</li><li>Falcon-1024有1.75KB的金鑰和1.25KB的簽名</li><li>SLH-DSA-256有128B的金鑰和17KB-50KB的簽名</li></ul></li><li>傳送者地址恢復<ul><li>這是ECDSA的一個特性(Schnorr等演算法中沒有)</li><li>也許交易(而不是簽名)應該編碼傳送者地址</li></ul></li><li>地址格式<ul><li>目前是40個十六進位制字元,keccak256(公鑰)</li><li>keccak256應該被keccak512/sha3-512/sha512/blake3-512取代</li><li>Grover演算法如何影響地址的暴力破解?是否應該將40個字元增加到80-128個?</li><li>更長的地址格式可能應該使用類似bech32的東西進行校驗和和人性化</li><li>新地址如何與舊地址/EVM互操作?</li></ul></li><li>加密錢包<ul><li>應該從AES-128升級到AES-256或chacha20</li><li>HMAC-SHA256應該升級到HMAC-SHA512或KMAC/blake3-512(金鑰模式)</li></ul></li><li>KZG EIP-4844驗證<ul><li>應該被一種後量子方案取代</li><li>目前演算法還不清楚,有什麼建議嗎?</li></ul></li><li>EVM 0x20操作碼(KECCAK256)<ul><li>應該被keccak512/sha3-512/sha512/blake3-512取代</li></ul></li><li>EVM預編譯的ECRECOVER<ul><li>見上面的地址恢復</li></ul></li><li>EVM預編譯的BN/BLS/KZG<ul><li>應該被新的方案取代(不清楚用哪些?)</li></ul></li><li>共識層簽名聚合<ul><li>目前每個時期(6分鐘)聚合所有驗證者的簽名</li><li>現在已經超過100萬個簽名了?</li><li>目前演算法還不清楚,有什麼建議嗎?</li></ul></li><li>還有其他什麼嗎?</li></ul><h2><a href="https://ethresear.ch#p-51852-final-thoughts-4" rel="nofollow"></a>最後的想法</h2>我相信這些問題都可以在有限的時間內解決。讓我們開始解決它們吧。如果這種計算機很快就出現,可以嘗試Vitalik的方法(《如何硬分叉以拯救大多數使用者的資金》):凍結所有賬戶,利用BIP39和ZK-證明將資金恢復到新的後量子方案。</div>

後量子ETH花絮

XWeChatTelegramSina WeiboCopy Link
後量子密碼（post-quantum cryptography, PQC）[6] 是一類能夠抵抗量子計算攻擊的新型密碼算法。
作者：ZAN Team
前言：谷歌推出了量子芯片 Willow 可以在 5 分鐘之內便完成了當今最快的超級計算機都需要 10^25 年才能完成的計算任務，雖暫時還無法對現實中使用的如 RSA 和 ECDS...

區塊鏈的達摩克里斯之劍：一文讀懂谷歌新量子芯片對區塊鏈的影響

RON決定下架幣安已經導致WazirX的WRX代幣價格在一小時內下跌60%。
被幣安下架,WazirX(WRX)代幣價格暴跌。圖片:The Crypto Times
WazirX,曾經...

幣安下架， WazirX （WRX）價格大幅下跌

幣安官方上線了幣安Alpha，這是一個新的整合在幣安錢包中的平臺，旨在介紹Web3生態系統中潛力巨大的早期加密貨幣專案。<Introducing Bin...>