In my previous post I discussed a little tool I was working on, closely related to my CoinZdense project. Since then I've now completed a first working version of the tool, and I want to explain what the tool is for, why I hope people will use it, why I hope that if they use it, it will be in preparation for an event that will never come to pass, and I want to do a little walkthrough of the different ways to use the tool.
hive-coinzdense-disaster-recovery
So why the tool? Three reasons really:
- To make my CoinZdense project more concrete for the HIVE community
- Just in case. If CoinZdense comes too late, if enough accounts used this tool beforehand, there would still be a disaster recovery strategy possible.
- To show potential project sponsors that CoinZdense isn't just hot air.
We will get into making things more concrete in the walkthrough part of this post, so let's start off with number two.
As I discussed in my HiveFest talk, we are all safe now, quantum computers are going to be a big problem for Web 3.0 platforms that still use ECDSA at the time that quantum computers (of the right type) have a net of more than 1500 error-corrected qubits at their disposal, but we are currently years from that point.
But before that day comes, a lot has to happen:
- CoinZdense (or a similar project doing roughly the same) needs to be completed
- In a number of consecutive hard-forks, CoinZdense needs to be integrated into the blockchain
- The eco-system needs to addopt CoinZdense
- Users need to start replacing their owner/active/posting key with hash-based signing keys.
None of these steps is likely to be completed in weeks or months, so what if despite of starting early on the problem, as we are doing now, we still end up being too late and for example only a relatively small portion of the HIVE userbase will have moved to hash-based signatures the day QC becomes a real threath?
Basically that is where the little tool comes in I'm discussing now.
Let's first look at a situation that is incredably unlikely: What if someone has a 10,000 qubit quantum computer right now and is attacking HIVE. Imagine you are an Orca sized account, almost a Whale, and you care about your anonimity. Nobody on HIVE knows who you are, where you live or what you look like. Now the worst thing that can happen happens, you, and a number of accounts like you get targeted by an advesary with the giant quantum-computer at her disposal.
The attacker plucks the ECDSA pubkey from hiveblocks, and sets her computer to work.
Some days later she has a perfect copy of your owner key. She isn't going to use it just yet, she continues harvesting owner keys like that so in a few months she is ready for the big heist.
She takes care to focus on anonimity centered big accounts.
Now the heist takes place. We aren't going to speculate on the specific details, but the important thing is an number of transactions take place that you and the other account owners don't aprove off. You convince the witnesses that an attack happened, but there is a problem, non of the keys is actually trusted anymore. You have an exactly equal claim to your HIVE identity that the attacker does.
Well, if this happened today, you would be screwed. But let's assume it doesn't happen today, let's assume it happens in five years and let's assume the four steps required for HIVE to be fully ready for this event haven't fully completed yet by then.
Well, in that case, you remember, hey in 2022 @pibara shared a little tool that I used to protect my account precicely against a situation like this. He wrote a brilliant post about the project he was working on, oh and he was nagging about his project having no funding. Damn I wish I had bought some project support tokens back then, then maybe I wouldn't be in this mess right now ;-)
But eventhough you didn't get any project support tokens, at least you used the tool, and so did most of the accounts that got hit, and most of the accounts that didn't get hit, and by doing so they made it possible to roll out a cumbersome but not impossible recovery scenario.
The cumbersome disaster recovery scenario
The tool I am sharing now does one simple little thing. It creates a disaster recovery key from your master password and registers it on the HIVE blockchain by signing the hash-based signing public key with your current OWNER key and adding it to the json_metadata of your account. There are other options to the tool to make it complete and show what it can do, but that part is the core of it.
The hash-based signing key it publishes is at the very lowest level of hash-based signing. It is a single one-time-signing-key. A single one-time-signing-key though that isn't vulnerable to quantum computing based attacks.
So the day of disaster recovery arives. HIVE is set to run mostly read-only. ECDSA signature based transactions are disabled and devs are working like crazy to get everythng working again with hash-based signatures. The witnesses pick a moment one year in the past (that would be four years in the future from our perspective right now), and registered disaster recovery keys up untill that point in time get one single operation enabled that uses that recovery key:
- Replace the ECDSA ACTIVE key with a hash-based ACTIVE key using the recovery key.
That's basically it. People who didn't register a recovery key, good luck to the witnesses and devs in 2027 to figuring out how to handle those, but let's not get too gloomy. I hope the scenario above is enough for you to consider running the tool just in case, and maybe to consider getting some project support tokens to help speed up CoinZdense development a bit.
Installing the tool
Installing the tools should be easy. If you have Python installed, simply run:
pip install hiveqdpr
If you don't have Python installed, I really recomend getting The Annaconda distibution
After installing with pip, you will have a set of nine commandline tools at your disposal.
- hash-based-key registration
- hqpdr-userpost-masterpass : Register a recovery key derived from the same master password your owner and active keys are derived from.
- hqpdr-userpost-altpass : Register a recovery key derived from an alternate password.
- hqpdr-userpost-wif : Register a recovery key using a WIF/base58 encoded private key.
- hqpdr-userpost-randomkey : Register a randomly created recovery key
- hash-based key derivation
- hqpdr-disasterkey-pass : Derive a disasterkey from a username and password
- hqpdr-coinzdensepubkey : Derive a (parameterized) CoinZdense pubkey from a username and password
- Signing
- hqpdr-sign-wif : Sign a CoinZdense key with a one-time recovery key.
- Verification
- hqpdr-userverify-ecdsa : Verify the on-chain recovery pubkey was signed and with what key
- hqpdr-validate : Validate the signature of a signed CoinZdense pubkey
Tool walkthrough
Time for a walkthrough, as we saw above, there are multiple commands you can use in order to register a recovery key. If you still have your master password and never changed or recovered your keys, the easiest is to use hqpdr-userpost-masterpass. That way you ONLY need to give your account name and password and the tool will calculate you recovery,owner and active key to do it's job. Alternatively you can use an alternate password and use the hqpdr-userpost-altpass command. That command will ask you for a password, your owner key AND your active key. If you already created your key elsewhere, you can use hqpdr-userpost-wif instead, again you will be asked for your owner and active keys. Finaly the command hqpdr-userpost-randomkey could be used. That last command creates a random recovery key and registers it. Again asking for your owner and active key. Note that each of the three tools that ask for your owner key allow you to just enter there and only supply an active key. If no owner key is supplied, registration of the recovery key will use an ACTIVE-key signed recovery key with slightly different JSON field names.
Let's use the hqpdr-userpost-randomkey command.
$ hqpdr-userpost-randomkey pibarabot
New disaster recovery key : 7GwUdyjBUEA7woDqstRvbPGGGo9BNfthLosgkxmPfMXwVtcdhCE
Owner Key (press enter if you don't have one):
Active key :
Registered disaster recovery key: QRKcD6MgWXywv1YAse6bWE3vCLamxED4DYnEhV4hJ
Make sure to store the new disaster recovery key somewhere safe
We just pressed enter when prompted for the OWNER key.
Now we can use the hqpdr-userverify-ecdsa command to check if the registerd keys for a given user are OK and to check what key was used for signing it.
$ hqpdr-userverify-ecdsa pibarabot
Key QRKLs9CSRZjqq1i5jykYMHNEu5KHFasneqtEejowU was signed by accounts OWNER key
Key QRKcD6MgWXywv1YAse6bWE3vCLamxED4DYnEhV4hJ was signed by accounts ACTIVE key
As we see here, the account already had a recovery key registered and signed with the OWNER key. The OWNER signed key should probably take precedence in case of a conflict.
Now that we have a recovery key registerd, we could use it to sign a CoinZdense key. Problem though, CoinZdense is highly parameterized i its level-zero keys setup, and we can't just guess what parameter values will eventually get used for HIVE. The command we have allows you to guess three parameters:
- hashlen : The number of bytes used for hashing and keys
- otsbits : The number of bits from a digest that get signed at once.
- l0height : The merkle-tree height for level zero of the CoinZdense multi-level hash-based signing key.
In the example below we use 24 byte hash sizes (like we do in the recovery keys), 8 bit for OTS (meaning 256 operations long OTS chains). and a merkle tree height og 8 bits (meaning room to sign 256 level-1 keys with the level-0 key).
$ hqpdr-coinzdensepubkey pibarabot 24 8 8
Password :
Privkey: 7Ln28Mn6Mp3BwLdshEWMz6V7rB6Jfa9bQET6eBKEgpM6frTZoZ1
Pubkey : CZD23Szwf22GgCiwT6su9BaJ5ZaABEuySn5wf8U7aY
Now that we have created our CoinZdense key (that likely isn't dimentioned right as explained), we can sign it.
$ hqpdr-sign-wif CZD23Szwf22GgCiwT6su9BaJ5ZaABEuySn5wf8U7aY
Disaster recovery privkey WIF :
Signature:
usOwm19Up+Ixv2kV5W2VpdaA12bGlEj3bBfTZpLifGnFi3YtjLF8p1vNGjbjK+4Jmo3Aj+c4ItxaXWMkWx/dIViUJ27T4ff2L6BBP9sODMktozzEosECKPRBC9uXiCyyt6kln7pDMRWlehlVL6SCsRy4z0b6Kc+9eUcQxpO0jxbFbuJ8p/ppx+ljRQXdwbXVvtK75CoAHGxUJqad66/5Moqtw4ZvPYa4Yofoqzgt/Yhk1FBq1HGxBhwDiLWdfu+7YbPN5SYQKaJ4MtImf1yYEndoq1g7Wa0d8+HlM1F4XOX3zBnOjGlbb2TWNU3fNbv3Y/teiL5eIJ5jVWbE5llU81kbPyjr1HWlVAqrZsMzkKRW9ywLeOkw48W1c2mXr89pHEncgN4UoionVIWi1BD7CWmIjQSCSzSSaNXvXmUMmfNNZkLJbBSG8J9AUkN5k54g4t5K7sLgohaNNu4MYRkIffcxSQOVTwqOqizs6GbG5Tdw2c6F0RschwEb9kV5iRF1T6s6UEHDcHg52PNooVQePa+1VouJX5Pyzs7vqYMEpahRlcZFe9kxdjrscsPAsb320fTSOA48jDCkRFxmF48mSx5d/BabfMfEfwZrxqnb6/C6k1yCliD+8ttMNH4ouk7ydAOxunBx7efSz7v8Caljq7JShz77ihbeGdwKYhJjK7F9wjnIRNhMO9XpNFK6FXS4gD8XUIAnNc7nbFVO1LZuXpJcOJdFvAHqUUhOV6xQwoJrw4OMuYLjJwBiUw/GaMvIvsUy0BD/YeMrGQp12RbbTjilMLVxw9i0BsLz+W19a2RuZhGb1L0PEwo8wCdMdqVZtlfiK/mLadINvr/UDrZze9JylFAMLZRH+lSkGDmmkOUhofzd/w3s5L7+53QJbUO4cVN1kgdurh6Ig2IqP2IdpLoB9ou8upUNY1W1zhVrpmuQodGncaafI8b8OchhHpcJwKvCRRdsx3TlJZ3E70Vjt1IGKWy+mcnBITJS1k890k41mP9qeIwCY0QZ56Q53YTtciTljt3tWaDqobiYw3+lFmXTTjHYSsHTVAfNrGELQEhptSRSsEpxuCK+x/vtwMKw
Recovery-Pubkey: QRKcD6MgWXywv1YAse6bWE3vCLamxED4DYnEhV4hJ
Finaly we can use the really long hqpdr-validate command to validate the signature:
hqpdr-validate CZD23Szwf22GgCiwT6su9BaJ5ZaABEuySn5wf8U7aY QRKcD6MgWXywv1YAse6bWE3vCLamxED4DYnEhV4hJ usOwm19Up+Ixv2kV5W2VpdaA12bGlEj3bBfTZpLifGnFi3YtjLF8p1vNGjbjK+4Jmo3Aj+c4ItxaXWMkWx/dIViUJ27T4ff2L6BBP9sODMktozzEosECKPRBC9uXiCyyt6kln7pDMRWlehlVL6SCsRy4z0b6Kc+9eUcQxpO0jxbFbuJ8p/ppx+ljRQXdwbXVvtK75CoAHGxUJqad66/5Moqtw4ZvPYa4Yofoqzgt/Yhk1FBq1HGxBhwDiLWdfu+7YbPN5SYQKaJ4MtImf1yYEndoq1g7Wa0d8+HlM1F4XOX3zBnOjGlbb2TWNU3fNbv3Y/teiL5eIJ5jVWbE5llU81kbPyjr1HWlVAqrZsMzkKRW9ywLeOkw48W1c2mXr89pHEncgN4UoionVIWi1BD7CWmIjQSCSzSSaNXvXmUMmfNNZkLJbBSG8J9AUkN5k54g4t5K7sLgohaNNu4MYRkIffcxSQOVTwqOqizs6GbG5Tdw2c6F0RschwEb9kV5iRF1T6s6UEHDcHg52PNooVQePa+1VouJX5Pyzs7vqYMEpahRlcZFe9kxdjrscsPAsb320fTSOA48jDCkRFxmF48mSx5d/BabfMfEfwZrxqnb6/C6k1yCliD+8ttMNH4ouk7ydAOxunBx7efSz7v8Caljq7JShz77ihbeGdwKYhJjK7F9wjnIRNhMO9XpNFK6FXS4gD8XUIAnNc7nbFVO1LZuXpJcOJdFvAHqUUhOV6xQwoJrw4OMuYLjJwBiUw/GaMvIvsUy0BD/YeMrGQp12RbbTjilMLVxw9i0BsLz+W19a2RuZhGb1L0PEwo8wCdMdqVZtlfiK/mLadINvr/UDrZze9JylFAMLZRH+lSkGDmmkOUhofzd/w3s5L7+53QJbUO4cVN1kgdurh6Ig2IqP2IdpLoB9ou8upUNY1W1zhVrpmuQodGncaafI8b8OchhHpcJwKvCRRdsx3TlJZ3E70Vjt1IGKWy+mcnBITJS1k890k41mP9qeIwCY0QZ56Q53YTtciTljt3tWaDqobiYw3+lFmXTTjHYSsHTVAfNrGELQEhptSRSsEpxuCK+x/vtwMKw
Valid signature
This pretty much covers it for this tool. Currently the tool includes some copied and pasted code from CoinZdense because the CoinZdense codebase is currently to fluid to rely on as a dependency. That code should soon move back to CoinZdense as well as the WIF code that currnetly isn't part of CoinZdense yet.
Play around with the tool, secure your accounts for the future if you'dd like to, and please, if you understand this stuff is importnat towards the future, even if right now it might not be that urgent, please consider supporting the CoinZdense project.
Support the CoinZdense project
As I mentioned in my talk at HiveFest, CoinZdense is a one-man and unfunded project. You can help support the project by buying project support tokens on hive-engine, by helping out looking at the 1995 style project website, or by advocating with the different target Web3 ecosystem communities.
So far the project has received roughly 7 HBD from sale of project support tokens on hive-engine and from a tiny Paypal donation on the tipping-jar page.
I would really like to spent some structural time on this project, so all donations and support are highly welcomed right now. I hope this little disaster preparation tool shows everyone with some concrete and functional, be it very limited code that CoinZdense is a project deserving of your tips and donations.
I'm not sure a mention is the best way to reach out to you guys, but I'm going to try anyway. I ran a little script for a while looking at new claimed accounts getting created, and in the 77693 accounts created, I noticed these accounts did most of the creation:
Just in case any of you are using Python to create these accounts, or could consider integrating a tiny bit of python to do so, it might be interesting to integrate the disaster recovery key creation, and the posting in the account json metadata as part of your account creation.
Please let me know what you think and if I can assist in any way.