We would need to switch from Verkle trees to binary trees based on STARK-friendly hash functions. It would be very beneficial to start writing that code (including the prover) asap.
2 Likes
Ethereum relies on Digital Signing over Elliptic Curve Cryptography (ECDSA – to represent the entire ECC family, e.g. EdDSA, BLS, Schnorr) for transaction security, with wallets storing private keys for signature creation, and nodes verifying transactions using corresponding public keys. However, with the rise of quantum computing, quantum computers could potentially break ECDSA cryptography, enabling attackers to steal assets by deriving private keys from public keys without wallet access. Estimates suggest cryptographically-relevant quantum computers could appear between 2028 and 2040, necessitating proactive mitigation strategies to safeguard Ethereum’s decentralized ecosystem.
pQCee dot com has been working on a quantum-safe ECDSA based on the pre-image proof called Signature Pre-image Proof (SPP) and is patent-pending. SPP was presented at DeCompute 2023 (a side event from Token2049). Coincidentally, in March 2024, @vbuterin wrote this post titled “How to hard-fork to save most users’ funds in a quantum emergency” which suggested a design similar to SPP.
We are excited to share a draft of an EIP that we have been working on. The proposal aims to present a solution for integrating a post-quantum signature scheme into the Ethereum blockchain while maintaining backward compatibility with existing ECDSA. The PQC signature scheme, targets integration with a quantum-safe zero-knowledge proof system such as zkSTARK or MPC-in-the-Head, to ensure the long-term security of Ethereum transactions against quantum attacks without requiring immediate upgrades to existing infrastructure.
Looking forward to your thoughts on the proposal.
I am really interested in this. Great post and topic. As I understand it, there are already quantum computers and a variety of models thereof. For example, D-Wave has adiabatic quantum computers, IBM has gate-model quantum computers, and PsiQuantum has photonic circuit board quantum computers.
Among the industry there seems to be a lot of in-fighting and competition for funding. As a result, many claim certain models are not real quantum computers. I’m more optimistic and think time will tell. In my opinion, what is important is whether there is an existing hardware-software combination that can break all classical crytpography.
I agree with you that we are already well-positioned to make a pretty simple recovery fork to deal with such a situation. I think this is an extremely insightful point.
I’m curious what led you to the conclusion that hashes are still safe, even when elliptic curves can be broken?
Overall, really brilliant analysis here.
Do we have any existing specification or a plan to write one for below?
- PQC / EC co-exisitng status
- How to map PQC & Account
- Quantum Bomb just like the Difficulty Bomb
Can this be done securely if an account is controlled by a threshold key?
I believe this suggestion as-is supports less wallets and less volume/value than we initially expect. Maybe we can add to it to cover more.
It currently does not support threshold keys because they are not created from a seed and hash but rather from an interactive process between multiple parties. While the end characteristics of the keys are equivalent, they do not have the same “history” and there is no specific hash protected seed in the process. There is no official public number of threshold keys in the ecosystem to reference, but it’s reasonable to assume that it is in double digit percentage as it became a very common practice.
Additionally this approach assumes that wallets that were created from a seed actually allow the extraction of the underlying seed (e.g. 12/24 words of a typical wallet), which is likely not the case in some advanced HSM systems and also maybe in some general wallets and so even if there was an initial seed it might not be accessible by intentional design (security) or by unintentional design (why keep the seed if I keep the actual key).
If we want this plan to be “the plan” for all wallets in case of emergency we can add to it an ERC based solution that allows active wallets to be included in the plan regardless of their original creation process. This would allow wallets that are concerned to take action and “future proof themselves” without having to change their ongoing security practices by introducing a risky seed with any access today.
The general idea is to use the current ECDSA key (before it is breachable) to declare a new quantum protected seed phrase that will be used in this process in the future - in case the need arises. The ERC would define an acceptable format to define a quantum safe hash that hides a seed. If we already have a stage we can allow hashes that are considered more quantum safe (or just the existing ones) and we can allow other optional parameters for limiting the scope.
A naive solution would be a typed 712 message, but of course 712 messages are not timed and so we would not know if it was signed before or after the breach, so we need to make sure it’s stored on-chain before the acceptable breaching date that is defined in the emergency plan. We can use some on-chain registery (e.g. EAS) for that purpose or a custom built one that is optimized for the usecase. Alternatively, with EIP-7702 going live we can define a standard that is based on that with a specified storage mechanism that stores this seed hash for use in case of emergency - again, does not require more than an ERC, but can also be embedded as part of an EIP for a more specific definition.
Practically the only thing needed for this approach to work is that it is decalared as part of the “emergency plan” alongside the initial suggestion for seed based wallets. As soon as it’s clear to the ecosystem that signing that ERC message/transaction will not be ignored in a possible future emergency solution - the most quantum concerned users will start using it and we will likely see the ecosystem support in tooling around it.
1 Like
Does anyone know, how can this work with EOA-based accounts that is/was generated pre-BIP, just in case? In other words, can an EOA-based pre-BIP account provide all the necessary data for the “STARK proof”?
It depends on the exact method of generation. If something can be proven in ZK / STARK manner, then it’s prob fine.
If not, it’s better to move to other solutions.
Thank you for replying. Would you think the private key alone is sufficient for the proof? I am not fond of BIP protocol-generated mnemonic phrases because after all they are all just “derivatives” of something higher (private keys).
Not enough. If quantum computers will be created, they would be able to bruteforce private keys. So knowledge of one is not relevant.
So only BIP-generated mnemonic phrases are valid for the transition?
Edit: After re-reading Vitalik’s post, I guess only mnemonic phrases are accepted as inputs because the validation only consider hashes. Now what if I convert everything (EOAs) into smart contracts right away before any quantum crisis strikes, would that be a good idea?
Update: After some thought, I believe the private key should be accepted as a valid input for the transition simply because:
- If a private key is compromised because it has been used for OUT transaction at least once (never been used private keys are 100% safe), then chances are its account would be empty anyway and pointless to the transition.
- For a never-been-used private key, the transition to a smart contract-based account should still be practical if the infrastructure allows a seed (or seeds, as decided by the account owner) as additional input for the creation of a smart contract-based account, therefore any hack post-transition would require both the private key + seed(s).
What I see is happening now, is the private key being the strongest component of the network and there are groups of people behind the scene that are trying hard to get rid of the private key component to usher in something that can be far less secure, i.e. mnemonic phrases generated by 3rd-party apps/gadgets/widgets (you name it) that can only be used online (not offline) so that the future may be the one whereby everyone is not safe as everyone’s wealth can be 100% hacked, under the stupid pretense of trying to make everything convenient and to protect clumsy/lazy users from their mistakes. Security does not correlate with convenience.
- Anything which can be proven in ZK manner can theoretically create recovery keys. There are all kinds of different methods besides mnemonics. You can build your own scheme.
- Mnemonics are 100% offline-friendly.
Most hardware wallet (with mnemonic phrases) users (that I know of) doing an OUT transaction can only do so through online connection, i.e. their hardware device is required in online connection for the validation, the same hardware device that store the private key for the validation. Unlike using private key directly whereby you can store the private key strictly offline on a device and use an entirely different device for OUT transaction. Even if the hardware device is connected online for the validation for just a very brief moment, that should still be counted as online and all the dangers of getting online should still be considered as malware/virus/personal data/etc can be transmitted in almost an instant. An example is a wallet brand, if I remember correctly Tangem, that transmitted the users’ private key directly to the manufacturer the moment the hardware wallet gets connected. But if you want to use the mnemonic phrases offline for OUT transaction, you cannot, as I am not aware of any 3rd-party device is accepting such arrangement. This is what I mean when I say mnemonic phrases can only be used online, through any 3rd-party devices you can think of. And this poses a huge risk.
Update: And in Tangem’s case, whereby the company said it has fixed the glitch, this CAN be a situation whereby a criminal deliberately breaks into your (or anyone) house to steal valuable things, and when caught, the criminal simply said, “Oh, I am sorry. I thought this is my house. But don’t worry. I have replaced the padlock/alarm/security for you and you may continue to live in your house and assume nothing ever happened.” And this criminal can be in possession of your house key all along and he is just not telling you that, which is why he broke into your house when you were away. And this is the risk when you use mnemonic phrases online through any 3rd-party device that you can name for any OUT transaction.
Most hardware wallet (with mnemonic phrases) users (that I know of) doing an OUT transaction can only do so through online connection
Who cares? Build a proper offline hardware device by yourself or maybe ask someone to build it. The scheme is offline-friendly. It does not require online presence even for brief moments.
Everyone who has vested interest in Ethereum should 100% care.
Why (#1)? The problem is when the Ethereum blockchain’s future development is being done to revolve around such users whereby the partial thesis is to protect such users from their mistakes, which to my speculation can be somewhat detrimental to the overall security of the network. Like I said, security does not correlate with convenience. And when the security is being done to revolve around protecting dumb/stupid/lazy users from their dumb/stupid/lazy mistakes by making things more user/human-friendly, then the underlying security may eventually be compromised to some extent. Users that are not dumb/stupid/lazy will have to accommodate overall weaker security structure in order to be friendly to dumb/stupid/lazy users.
Why (#2)? In the beginning, everything revolves around private key + trustless. Now and in the future development, everything is shifting to no private key + trusted wallet (as mentioned in one of Vitalik’s blog posts). You should be aware of the difference in its significance.
Being able to build one’s own device is beside the main point.
Update: I wish to add. A private key can do everything that a mnemonic phrase can, but a mnemonic phrase is created mainly not because it is better, but rather so that the user experience is such that it is easier to remember. Being easier to remember has nothing directly to do with security. And I have used mnemonic phrases before and I can tell everyone honestly the care that involves using such phrases is more complicated than using the private key directly.
Update #2: Consider the possibility of a future whereby everyone can only do online transactions (no offline signed messages for online broadcast) through a trusted 3rd-party wallet (by imposing the need for partial validation or co-signing from such trusted 3rd-party wallet for the transaction to be processed). In other way of saying, you building your own device for offline use on online transaction will not be processed. And all these setups will be justified under the false/stupid pretense of protecting the users from their mistakes and enhancing user experience. What would you do then? And in case you still do not understand up to this point, what if those trusted 3rd-party wallets are criminals in the waiting to strike at the opportune time (or as ordered by the government), resulting in the total (or significant) loss of your entire wealth? Such future is possible.
I hope the recent Bybit’s $1.5 billion hack will be an additional security lesson that there is absolutely NO trusted 3rd-party wallet that can really be safe. Not Ledger, not Trezor, not Tangem, not Safe, and not any other brand that anyone can name. Every transaction needs to be strictly from offline signing. And if the major industry players truly care, then security must be built around the security-over-convenience thesis, instead of around the stupid pretense of catering to user-friendliness. Therefore, future blockchain infrastructure should also be built as such, instead of having even an iota of reliance on some trusted 3rd-party, no matter how trusted that 3rd-party you think is, for any transaction. Dependence on any hardware wallet/device is a form of reliance on some 3rd-party, and this will open up the potential for hacks.
Almost everyone (99.99%) keep saying using hardware wallet is the safest, but it actually is not. The Safe wallet that got hacked in order to get to Bybit’s $1.5 billion is a fine example of that. Hardware wallet is NOT the safest. You may name whatever the brand for being the safest, but they are just taking turns to get hacked. Do not use quantum computing, or user-friendliness, or any other stupid and lame excuses to end up building a weaker blockchain security structure.
Air-gapped and strictly offline-generated signed messages for online broadcast (as well as for cold storage), independent of any 3rd-party hardware device, is the ultimate security. “Not your keys, not your coins” is widely spoken but almost nobody truly understands it entirely. If you do NOT know your private keys (maybe because someone told you are not supposed to because you pose a huge security risk, even though you are the owner), then you do not really own your coins. Just the same as if you have never seen your wife nor touched her, then you cannot claim that woman is your wife.
Less words, more code. Write code which solves the pq issue reliably and show it to us.
I am not a developer, but my main point, to put it differently, is to develop a blockchain structure that revolves around enabling, empowering, and enhancing strictly offline signing and cold storage capabilities to everyone (including the laypeople), and NOT on enabling, empowering, and enhancing online signing by way of abolishing private keys and relying on trusted 3rd-party apps. Do not say there is no other way.
Learn to code then, to understand trade-offs, and stop posting nonsense. BIP39 is fully offline scheme which generates private keys. No one abolishes offline signing or private keys. You can generate keys once from bip39 and then copy-paste them anywhere.
1 Like