# Tidbits of post-quantum ETH

Source: https://ethresear.ch/t/tidbits-of-post-quantum-eth/21296
Kiwi News: https://news.kiwistand.com/stories/Tidbits-of-post-quantum-ETH?index=0x67659dbdab32ddd23b4214c1af0083e6c528b4b6cdd5ef66c8e4a828410ff0e21d86e74b
Submitted by rvolz.eth on 2024-12-20 UTC, 4 upvotes, 0 comments

## Summary

Vitalik Buterin's post-quantum tasklist for Ethereum lists components that would need upgrading if a cryptographically relevant quantum computer is built, since Shor's and Grover's algorithms could break ECDSA and ECDH and weaken hash functions. The article says BIP39 seed phrases and EIP-2333 validator withdrawal keys are fine, while BIP32 derivation, transaction signing, address format, KZG verification and the EVM's KECCAK256 opcode need replacing. It proposes Falcon or SLH-DSA for signatures, which would produce larger keys and signatures; for example, Falcon-1024 has 1.75KB keys and 1.25KB signatures. The author is confident these problems can be solved and suggests that, if such a computer appears soon, a hard fork could freeze accounts and use BIP39 with ZK-proofs to move funds into a post-quantum scheme.

## Article

Tasklist for post-quantum ETH

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) strength from 2^n to 2^\frac{n}{2}

There are some non-obvious parts of ETH which would need to be upgraded.

What is still OK

bip39 (pbkdf2-sha512) seems just fine

eip2333 validator withdrawal keys are also fine!

What needs upgrading

bip32 hdkey derivation

Should be replaced by something post-quantum and better (no “non-hardened” keys)

New scheme could be based on HKDF (like EIP-2333), but not HKDF-SHA256

Alternative KDF is Blake3 in context mode (pq security is unclear)

The proposed scheme should support both ECC and new pq mode

Transaction signing

Should be replaced by lattice-based Falcon (FN-DSA / FIPS-206), or hash-based Sphincs-plus (SLH-DSA / FIPS-205)

New keys and signatures will consume more space

Falcon-1024 has 1.75KB keys and 1.25KB sigs

SLH-DSA-256 has 48-128B keys and 17-51KB sigs

Sender address recovery

It was feature of ECDSA (not available in Schnorr, for example)

Perhaps txs (and not sigs) should encode sender addresses

Address format

Currently it’s 40 hex characters, keccak256(pubkey)

keccak256 should be replaced by keccak512 / sha3-512 / sha512 / blake3-512

How does Grover algo affect brute-forcing of addresses? Should 40 characters be upped to 80-128?

Longer address formats should probably use something like bech32 for checksumming & human-friendliness

How would new addresses interop with old addresses / EVM?

Encrypted wallets

Should upgrade from AES-128 to AES-256 or chacha20

hmac-sha256 should upgrade to hmac-sha512 / kmac / blake3-512 (keyed mode)

KZG EIP-4844 verification

Should be replaced by a post-quantum scheme

Algorithms are unclear for now, any suggestions?

EVM 0x20 opcode (KECCAK256)

Should be replaced by keccak512 / sha3-512 / sha512 / blake3-512 (new opcode)

EVM precompile for ECRECOVER

See address recovery above

EVM precompiles for BN / BLS / KZG

Should be replaced by newer schemes (unclear which ones?)

No more Groth16, vanilla PLONK, Marlin, BulletProof

Consensus layer signature aggregation

Currently aggregates signatures of all validators once per epoch (6 mins)

More than 1M signatures right now?

Algorithms are unclear for now, any suggestions?

ZK-rollups (non STARK)

Anything else?

Final thoughts

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 (How to hard-fork to save most users’ funds in a quantum emergency): freeze all accounts and leverage BIP39 with ZK-proofs to recover funds into new pq scheme.