general goal for bounty5

[catShaark]

Update: see my comment below for goals and updates.

---

we start from 24 standard words and use something very simple that only requires sha256 to generate more 256bit values: the first one is used for standard kdf & hd derivation for secp keys. The second one for alt sha256-only-kdf for ed25519 keys. we need a sha256-only alternative to hd derivation (or possibly something like aes could work too), at the top top level, followed by some-kdf-for-privkey. Basically I would use standard hd generation but I’m trying to only trust sha256 for important stuff, not sha512. we should first start with a goal document, then a proposed plan document, get it reviewed, before implementation.

[catShaark]

this is what jae kwon said btw

[catShaark]

maybe he wants this ? ?

[nghuyenthevinh2000]

well, firstly, a 64 - bytes private key = 32 - bytes random + 32 - bytes public key according to ed25519.go

[catShaark]

ed25519 privkey is only 32-bytes, the code is misleading

[jaekwon]

Goals:

• Defend against hacking issues that may arise from hardware wallet providers.
• Defend against potential weaknesses in the Secp256k1 algorithm. For example, Satoshi's "2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1" constant is potentially flawed.
• Defend against potential weaknesses in bip32's HMAC-SHA512 function. SHA256 is somewhat economically tested by the Bitcoin hashing algorithm and mining incentives, so the goal here is to provide an alternative that relies primarily on sha256.
• Defend against potential weaknesses in bip39's PBKDF2 function (which also relies on HMAC-SHA512). For example, the PBKDF2 function may have a limited range of outputs, which limits the private keyspace.
• Continue to allow the usage of hardware signing devices, and bip32/39 and secp256k1 algorithms for day-to-day usage.

I propose that we allow for the registration of an alternative key based on ed25519 as a backup key that is not used, but can be used in case of emergencies when issues arise with the default bip32/39/sec256k1 keys. Tooling should be provided to allow this alternative backup key to be generated on an airgapped computer, without the aid of a specialized crypto signing device.

The (primary) mnemonic for the secp256k1 key must be separate from the (secondary) mnemonic for the ed25519 key, because hardware crypto signers ask for the mnemonic to set up the device, and the second mnemonic should only be entered on airgapped general computers.

On the Cosmos Hub, I propose that to get GNO airdrops, you must "pre-register" your backup ed25519 key by sending to a "zero" address with the memo field set to something obvious like: "SET_BACKUP_KEY=<tmhash.SumTruncated(ed25519PubKey[:]) in bas58>" (so as to differentiate from g1XYZABC keys to prevent users from naively entering yet another SECP256k1 gnoland address as the backup key. Lets call this "airdrop-registration".

In Gno, instead of relying on the memo field, we can add a "RegisterAccount" sdk.Msg to provide the backup ed25519 pubkey-hash, and furthermore we can require the user to register their account w/ backup key before actually using their secp256k1 keys. This way, users can just use a hardware wallet to generate a secp256k1 address to receive funds, but are incentivized to register a ed25519 pubkey.

In the case of issues with the bip32/39/secp256k1 system, the gno.land chain can fork and just use the ed25519 key. Users who have not yet registered an ed25519 backup key would either end up losing their tokens, or possibly the tokens would have to be distributed with real-world KYC etc to catch the hacker who may be trying to reclaim them on the gno.land fork -- this assuming that we come up with a reasonable way to protect the privacy of users while also keeping the recovery accountable. Users who register their account with a backup key would not be affected, and if there are no issues with bip32/39/secp256k1, none of this matters.

24-words -> standard kdf & hd derivation -> secp256k1 address 24-words (different) -> sha256-based-kdf -> ed25519 address

And finally, the gnokey command should be updated to make all of this easier. I like the approach taken by https://github.com/gnolang/bounties/issues/11 and https://github.com/gnolang/bounties/issues/14; there just needs to be another gnokey subcommand that bundles these two together (and explains everything, and requires different mnemonics) and produces an unsigned msg for account registration on gno, as well as MEMO-based airdrop-registration on cosmos.

Thoughts and feedback welcome.

[piux2]

Here is my solution, Happy New Year!

https://github.com/piux2/gnobounty5

Solution Doc

https://github.com/piux2/gnobounty5/blob/master/bounty5solution.md

Instruction Doc

https://github.com/piux2/gnobounty5/blob/master/bounty5instruction.md

[jaekwon]

Happy belated new year! Still around, @piux2?

[jaekwon]

@piux2 or someone please make a PR with @piux2's contributions. Right now I have to manually use git diff; but with a PR in github we can use the web interface to review changes. The HKDF approach seems right.

[jaekwon]

@catShaark what is your gno address?