Smart Contract Proposal for backing up keys

Planning on building some opensource software/ smart contracts - trying to see if my protocol is well thought through - feel free to shit on it

Motivation

A lot of people getting into crypto are concerned about losing their keys/hardware wallet. Balancing losing your keys with them being easily found is a tough line to draw. I’m going to propose a protocol to securely “back up” your keys, and I wanted opinions on it.

The goal is to accelerate crypto mass adoption by ensuring non crypto fanatics can trust that they wont chuck their life savings away on a piece of paper in a recycling bin.

Requirements

I’ve spent a while thinking about the necessary requirements of a good system and my proposal is centered around the following requirements so I’d be appreciative of criticism of the requirements as they greatly affect the proposal.

Security Standards

1. Independent of any 3rd party (obviously). This has 2 parts. Firstly, you do not rely on a 3rd party to access said protocol. Secondly, no 3rd party can access your keys under any reasonable circumstances, for example an authenticator app could be hacked.
2. At least (but realistically better) than bank security. So it should be more difficult for a hacker to access this than your bank account
3. Anonymous - full anonymity (preview: zk proofs, encryption)
4. Open source - all crucial code should be held within smart contracts that does not require front end software to function

I also came up with some practical requirements for this to work.

1. Proofs must be timeless - i.e. something as simple as your car registration plate is insufficient as this could change
2. Proofs must be easy - there must be zero ambiguity in what you need to provide, including details like formatting
3. Proofs must be accessible - there must not be any doubt that the seeker should be able to recover their keys in an emergency
4. Proofs should be editable - in case situations change
5. Contain redundancy in case some information is for whatever reason lost.
6. Must not be biometric - not easy to prove - not standardized means to measure it, not easily always accessible (lets say in 50 years who knows if fingerprint id will be a thing)

Encoding

Encoding contains 3 stages. 1) public id. You enter 5 pieces of publicly identifiable information (PbId) from the stage 1 list and encrypt this using a symmetrical hashing algorithm

in 3s creating 5C3 = 10 combinations of information. Each is stored in Mapping 1 along with a signed version of this information.

2) Private identifiers. You enter as many pieces of (PrId) from the stage 2 list and encode these in triplets using a symmetrical hashing algorithm. Next you encrypt this with Decryption Key 1 (D1) which must start with a hexadecimal representation of your public key and be 44 characters additionally long. You store this with your public key in Mapping 2. So each address corresponds to a list of encrypted data.

3) Personal Identifiers (PerId). You can now create and answer and provide a hint to personal questions and encrypt these with D1. You then hash your private key/mnemonic with D1 and hash the result with each combination of X answers. You then store these in Mapping 3 as a list of hexadecimals.

Decoding

First you select 3 pieces of PbId to hash and find the signed version from M1. You then recover your address using any Zero Knowledge algorithm (to preserve anonymity) and check if your wallet is of value before continuing.

You repeat the process with PrId and recover D1.

You repeat with (PerId) and combine with D1 to recover your private key.

Lists

1. PubId: Name, mothers maiden name, phone number, license, email address, account number/sortcode
2. PriId: Passport number, card number, proof of email address
3. The Questions will be forever hidden so you can pick anything embarrassing that big corporations wouldn't know.

Small Points

1. Why do we need PerIds if only I can access PrIds? - Realistically you will use 3rd party software to put PrIds onchain so we satisfy Requirement 1.
2. Why do we have PrIds given then above if PerIds work by themselves - Requirement 2 - you do not wanted jilted exes who may know some of your PerIds to get in.
3. Why do we need ZK instead of identifying people by their hashed PubIds. Because you want to separate the process of knowing PubIds and PerIds and having a public key could be inherently and independently useful. Also for this information to be updatable we must be able to use addresses to id the updater - especially considering things in List 2 may change