A tool to organise and manage paper wallets without thirdparties.
⇾ Follow our funky new development ⇾ king-kong-II-web3 🌶️
> npm i
> npm run btcNote about bitcoinjs-lib.js: Remove all tslint the comments /* eslint-disable node/no-deprecated-api */ Remove Typescript fields for class ECPair
try the demo, https://evaletolab.github.io/horcrux-wallets/
The goal of this application is to provide a few solutions to protect a Mnemonic without the needs of a trusted thirdparties.
We propose the usage of Shamir Shared Secret (SSS) to protect your Mnemonic without the problem of single point of security. We decide to use as source of SSS the entropy that produce the Mnemonic. Shamir split entropy in 3 separate pieces (called Horcruxes). Your need at least two pieces to reconstitute deterministicaly the same Mnemonic. We recomend you keep them in separate places/locations:
- Use printed paper.
- Use a digital pipcture with our Steganography solution.
- And use our Horcrux SmartContract. 👇
We created a simple ethereum contract that can store one Horcrux (SSS split) in a secure way. Here is the main idea 🧵 What? storing a secret in a public blochain is insaine !
0/5 First, Shamir is considered enough secure (1, 2, 3, 4) to store a private and we recommend to store only one share. That is, any combination of shares less than the necessary threshold conveys absolutely no information about the secret. Second, the shared part is XOR mixed with a private key before being stored. We already planned a tool to delegate the storage and avoid the relation between the original wallet and the stored Horcrux.
1/5 To secure an Horcrux user have to choose and remember an email and password.
2/5 On browser, we computes a pair of values to secure the process. First one is the KECCAK256 hash of the text ethers.utils.id(username+password) that produce a iid (identity id). We compute the value PoW with the Proof-Of-Work of the iid ,both values are inputs for:
- mix (XOR) or encrypt the Horcrux,
- derive the storage key for the EVM,
- restore the Horcrux.
Note: PoW on the client side, is a simple solution to to discourage the brut force attack.
3/5 Because the initial Horcrux should not be stored on a public blockchain, we derive a privateKey based on the KECCAK256 hash of iid and pow. The the Horcrux has tobe MIXED (or encrypted) before to be stored.
4/5 At this point, the storage key is a derivation of the privateKey. That means that neither the privateKey or the horcrux can be restored.
5/5 to restore the content we call a pur solidity function, that means no transaction, it's a silent call.
TODO