Quantum resistant blockchain and cryptocurrency, the full analysis in seven parts. Part 7.
By QR Collector on ALTCOIN MAGAZINE
Failing shortcuts in an attempt to accomplish Quantum Resistance.
- Hashing public keys
- “Instant” transactions
- Standardized fees
- Timestamped transactions
Here are some of the claims regarding Quantum Resistance without the use of a quantum resistant signature scheme that I have come across so far. For every claim, I give arguments to substantiate why these claims are incorrect.
“We only have public keys in hashed form published. Even quantum computers can’t reverse the Hash, so no one can use those public keys to derive the private key. That’s why we are quantum resistant.” This is incorrect.
This example has been explained in the previous article. To summarize: Hashed public keys can be used as an address for deposits. Deposits do not need signature authentication. Alternatively, withdrawals do need signature authentication. To authenticate a signature, the public key will always need to be made public in full, original form. As a necessary requirement, the full public key would be needed to spend coins. Therefore the public key will be included in the transaction.
The most famous blockchain to use hashed public keys is Bitcoin. Transactions can be hijacked during the period a user sends a transaction from his or her device to the blockchain and the moment a transaction is confirmed. For example: during Bitcoins 10 minute blockchain, the full public keys can be obtained to find private keys and forge transactions. Page 8, point 3 Hashing public keys does have advantages: they are smaller than the original public keys. So it does save space on the blockchain. It doesn’t give you Quantum Resistance however. That is a misconception.
“Besides having only hashed public keys on the blockchain, we also have instant transactions. So there is no time to hijack a transaction and to obtain the public key fast enough to forge a transaction. That’s why we are quantum resistant.” This is incorrect and impossible.
There is no such thing as instant transactions. A zero second blocktime for example is a claim that can’t be made. Period. Furthermore, transactions are collected in pools before they are added to a block that is going to be processed. The time it takes for miners to add them to a new block before processing that block depends on the amount of transactions a blockchain needs to process at a certain moment. When a blockchain operates within its maximum capacity (the maximum amount of transactions that a blockchain can process per second), the adding of transactions from the pool will go quite swiftly, but still not instantaneously.
However, when there is high transaction density, transactions can be stuck in the pool for a while. During this period the transactions are published and the full public keys can be obtained. Just as with the previous hijacking example, a transaction can be forged in that period of time. It can be done when the blockchain functions normally, and whenever the maximum capacity is exceeded, the window of opportunity grows for hackers.
Besides the risk that rush hours would bring by extending the time to work with the public key and forge transactions, there are network based attacks that could serve the same purpose: slow the confirmation time and create a bigger window to forge transactions. These types are attacks where the attacker targets the network instead of the sender of the transaction: Performing a DDoS attack or BGP routing attack or NSA Quantum Insert attack on a peer-to-peer network would be hard. But when provided with an opportunity to earn billions, hackers would find a way.
For BTC: https://eprint.iacr.org/2015/263.pdf
An eclipse attack is a network-level attack on a blockchain, where an attacker essentially takes control of the peer-to-peer network, obscuring a node’s view of the blockchain.
That is exactly the recipe for what you would need to create extra time to find public keys and derive private keys from them. Then you could sign transactions of your own and confirm them before the originals do.
This specific example seems to be fixed now, but it most definitely shows there is a risk of other variations to be created. Keep in mind, before this variation of attack was known, the common opinion was that it was impossible. With little incentive to create such an attack, it might take a while until another one is developed. But when the possession of full public keys equals the possibility to forge transactions, all of a sudden billions are at stake.
“Besides only using hashed public keys as addresses, we use the First In First Out (FIFO) mechanism. This solves the forged transaction issue, as they will not be confirmed before the original transactions. That’s why we are quantum resistant.” This is incorrect.
There is another period where the public key is openly available: the moment where a transaction is sent from the users device to the nodes on the blockchain network. The sent transaction can be delayed or totally blocked from arriving to the blockchain network. While this happens the attacker can obtain the public key. This is a man-in-the-middle (MITM) attack. A MITM is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. No transaction is 100% safe from a MITM attack. This type of attack isn’t commonly known amongst average usergroups due to the fact communication is done either encrypted or by the use of private- public key cryptography. Therefore, at this point of time MITM attacks are not an issue, because the information in transactions is useless for hackers. To emphasize the point made: a MITM attack can be done at this point of time to your transactions. But the information obtained by a hacker is useless because he can not break the cryptography. The encryption and private- public key cryptography is safe at this point of time. ECDSA and RSA can not be broken yet. But in the era of quantum computers the problem is clear: an attacker can obtain the public key and create enough time to forge a transaction which will be sent to the blockchain and arrive there first without the network having any way of knowing the transaction is forged. By doing this before the transaction reaches the blockchain, FIFO will be useless. The original transaction will be delayed or blocked from reaching the blockchain. The forged transaction will be admitted to the network first. And First In First Out will actually help the forged transaction to be confirmed before the original.
“Besides having only hashed public keys, we use small standardized fees. Forged transactions will not be able to use higher fees to get prioritized and confirmed before the original transactions, thus when the forged transaction will try to confirm the address is already empty. This is why we are quantum resistant.” This is incorrect.
The same arguments apply as with the FIFO system. The attack can be done before the original transaction reaches the network. Thus the forged transaction will still be handled first no matter the fee hight.
“Besides the above, we use multicast so all nodes receive the transaction at the same time. That’s why we are quantum resistant.” This is incorrect.
Multicast is useless against a MITM attack when the attacker is close enough to the source. (On a sidenote, if you need a service outside of the blockchain mechanism to be secure, you’re blockchain apparently isn’t. So using this means you are relying on an external party for your security. If they get compromised, you are too.)
“Besides the above, we number all our transactions and authenticate nodes so the user always knows who he’s talking to. That’s why we are quantum resistant.” This is incorrect.
Besides the fact that you’re working towards a centralized system if only verified people can become nodes. And besides the fact that also verified nodes can go bad and work with hackers. (Which would be useless if quantum resistant signature schemes would be implemented because a node or a hacker would have no use for quantum resistant public keys and signatures.) There are various ways of impersonating either side of a communication channel. IP-spoofing, ARP-spoofing, DSN-spoofing etc. All a hacker needs is time and position. Time can be created in several ways as explained above. All the information in the transaction an original user sends is valid. When a transaction is hijacked and the communication between the user and the rest of the network is blocked, a hacker can copy that information to his own transaction while using a forged signature. The only real effective defense against MITM attacks can be done on router or server-side by a strong encryption between the client and the server (Which in this case would be quantum resistant encryption, but then again you could just as well use a quantum resistant signature scheme.), or you use server authentication but then you would need that to be quantum resistant too. There is no serious protection against MITM attacks when the encryption of the data and the authentication of a server can be broken by quantum computers.
Only quantum resistant signature schemes will secure blockchain to quantum hacks. Every blockchain will need their users to communicate their public key to the blockchain to authenticate signatures and make transactions. There will always be ways to obtain those keys while being communicated and to stretch the period where these keys can be used to forge transactions. Once you have, you can move funds to your own address, a bitcoin mixer, Monero, or some other privacy coin.
There is only one way to currently achieve Quantum Resistance: by making sure the public key can be made public without any risks, as is done now in the pre-quantum period and as Satoshi has designed blockchain. Thus by the use of quantum resistant signature schemes. The rest is all a patchwork of risk mitigation and delaying strategies; they make it slightly harder to obtain a public key and forge a transaction but not impossible.
Quite often this strategy of postponing quantum resistant signature schemes is mentioned:
“Instead of ECDSA with 256 bit keys we will just use 384 bit keys. And after that 521 bit keys, and then RSA 4096 keys, so we will ride it out for a while. No worries we don’t need to think about quantum resistant signature schemes for a long time.” This is highly inefficient, and creates more problems than it solves.
Besides the fact that this doesn’t make a project quantum resistant, it is nothing but postponing the switch to quantum resistant signatures, it is not a solution. Going from 256 bit keys to 384 bit keys would mean a quantum computer with ~ 3484 qubits instead of ~ 2330 qubits could break the signature scheme. That is not even double and postpones the problem either half a year or one year, depending which estimate you take. (Doubling of qubits every year, or every two years). It does however have the same problems as a real solution and is just as much work. (Changing the code, upgrading the blockchain, finding consensus amongst the nodes, upgrading all supporting systems, hoping the exchanges all go along with the new upgrade and migrate their coins, heaving all users migrate their coins.) And then quite soon after that, they’ll have to go at it again. What they will do next? Go for 512 bit curves? Same issues. It’s just patchworks and just as much hassle, but then over and over again for every “upgrade” from 384 to 521 etc.
And every upgrade the signatures get bigger, and closer to the quantum resistant signature sizes and thus the advantage you have over blockchains with quantum resistant signature schemes gets smaller. While the quantum resistant blockchains are just steady going and their users aren’t bothered with all the hassle. At the same time the users of the blockchain that is constantly upgrading to a bigger key size, keep on needing to migrate their coins to the new and upgraded addresses to stay safe.