# WIP: Social backup on Ethereum

###### tags: `dc-web3`

## Architecture

#### Webapp
- a website accessible through your browser
- written in react/vue/vanilla js
- hosted on gitlab/heroku/??
- has a description of how the app/entire process works
- has a button that says 'create new key' (or something similar)
- has an input box for the user to input their chosen public key, which will be used to sign a hash of {some data (app name?)}
- does it check that the user's input is in fact a signing key?
- if we are generating the keypair deterministically through a wallet connection then this would not be needed
- this could also look like prompting them to connect a wallet (metamask or wallet connect or something similar) and then asking them to create a signature with it
- does some computation on this signed-hash to deterministically generate a new (Curve25519) encryption keypair
- which can be regenerated (as deterministic) when needed in the future, provided the shareholder still has access to their signing key and to the data that was hashed (for this reason maybe e.g. app version number should not be used?)
- the shareholder sends the public key from this encryption keypair to the owner, and discards the private key

#### Rust app
- offline-first CLI application (could later have a UI)
- has an input box for the secret-owner's secret
- has an input box for the keys provided by the secret-owner's shareholder friends
- does some computation on these inputs and produces encrypted shares
- output is:
- a qr code? a call to the web3 api? a call to the webapp to send a transaction to the blockchain via metamask?
- the shareholders' shares
- when the qr code is scanned (by what?) it makes a call to the web3 api to publish this ethereum transaction to the blockchain
- this call needs to be signed by (made from?) an 'external account'
- does this 'external account' / signing key belong to the app, so is the same for all transactions published from the app?
- or the secret-owner's public ethereum address/key
- or a burner address/key => would need some eth to be sent to it before it could publish the transaction

#### The transaction
- who is the transaction 'to'?
- does it go to the smart contract?
- what does it do there?
- does this make it trivial to find all 'share' transactions (all transactions addressed to that contract) and does this weaken the system?
- does it go to a zero account?
- would this be a fixed null address (has same problem as contract address above), or a randomly generated one each time?
- either way, how would the message be indexed/found later on?
- how is the message in the 'data' field constructed?
- data field contains the shares
- each share is encrypted with the respective key of the share-holder (as created in the webapp and passed to the secret-owner in step 1)
- does each share have a corresponding piece of information that indicates to which shareholder it belongs?
- is this data field somehow encrypted? how is it obfuscated that this transaction contains a list of shares (and corresponding shareholders)?
- does there exist web3 api call that allows this data field to be easily read, as a way of 'finding' the message again? else what information do you need to be able to access it?

## Implementation details

#### Ensuring both anonymity of shareholders and ease of identifying share
- why is this needed
- anonymity so that shareholders cannot be targeted for access to an owner's account
- identification of share so that shareholders can easily know which share in a transaction is their's and can be decrypted with their key
- why do we need this - assuming there will be max e.g. 20 shares, why can't the recovery function just cycle through the shares with a given shareholder's key until it decrypts one
- include identifying information for the secret (eg: the associated address/public key) in the derivation of the shareholder's encryption keypair at the beginning of the process.
- each shareholder's encryption key would be unique to the owner's particular secret, rather than unique to the application.
- so it is a way of us being able to find the right share without putting any identifying information on the blockchain.
- how does this relate to finding the right share?
- or to anonymity of the shareholder?
- downside is that we need to know the identifying information during recovery. otherwise there is no way to decrypt the shares.
- presumably if it is a private key of some kind, the ownerwould still have access to the public part, or else would not need recovery.
- if it is not a key, but e.g. a phone number, this would be different

## Use-cases

#### Possible hooks for rediscovery:
- Owner's ethereum address + smart contract address (from + to fields)
- would need additional info if app is secret-agnostic, in case a given address shares multiple secrets
- Transaction hash (stored on ENS?)
- would be public, so could also be found in the case of inheritance (tho shareholders would still need to find each other) or in the case that the sending address was forgotten or lost
- would be public - so would also be very easy for anyone to find out if a person has shareded an important secret
- Smart contract address plus some particular info from the 'data' field
- could be shareholder data (public key, private key, ethereum address), but would need to be a hash or otherwise not discoverable who the shareholders are
- could be quite complicated to search through & locate a transaction based on the content of its data field

#### Threats:
- transactions all go through the same smart contract, so can be identified as secret-sharing transactions in this way
- transactions will be sent to that contract from the address of an owner
- this address may or may not be related to the secret being shared, but will relate to the owner of the secret
- unless a burner account is used => this has complexities in terms of needing eth and needing some hook for rediscovery
- transaction data field will contain the shares
- the shares will be encrypted
- the private keys of the shareholders will be needed to decrypt them
- will it be possible to derive the identities of the shareholders from the shares?
- if not, only the owner knows who they are, and can recover the key
- this does not work for an inheritance use-case, where shareholders need to locate each other
- shareholders knowing who one another are may itself present a threat of collusion, may be preferable to the owner that they do not

#### Scenarios:
- Owner loses private key (e.g. forgets password), remembers address the transaction was published with
- Owner can find the shares using their public address
- what if they shared more than one secret using that address - how to indentify which transaction they need now
- Owner can find the shares using the saved transaction hash
- would require them saving/storing the transaction hash, which is problematic, but is less secretive / less risky to store written down in a notebook or emailed to oneself than a private key
- Owner loses computer, can't remember private key or address, but remembers who the shareholders are
- Shares can be found if owner or shareholders can remember some info with which they can find the owner's address (e.g. remember a transaction that they made with the owner to that account)
- Owner or shareholders can find the shares using a shareholder's address (/hash of etc) by searching all the 'data' blocks on transactions sent to the contract)
- Owner loses computer, can't remember private key or address, can't remember who the shareholders are
- null - can't recover key
- Owner dies, shareholders know who each other are
- Shareholders can find the shares using the owner's address
- Shareholders can find the shares using a saved transaction hash
- Shareholders can find the shares using their own public key (/hash of etc - through searching all the 'data' blocks on transactions relating to the contract)
- Owner dies, shareholders don't know who each other are