search

trezor / trezor-mcu

:lock: Don't use this repo, use the new monorepo instead:
https://github.com/trezor/trezor-firmware
GNU Lesser General Public License v3.0
317 stars 255 forks source link

Using M of N paper backup seeds to restore TREZOR (SSSS) #61

Closed prusnak closed 5 years ago

prusnak commented 8 years ago

Enable option of fragmented seed backups, e.g. 2-of-3 seed backup and so on.

jhoenicke commented 8 years ago

Since this came up on reddit, I just thought I add some comments how this could be implemented.

Setup: Add an option when initializing a trezor to use M-of-N SSSS. Instead of a single list of words it will then display multiple lists of words, one for each share. I would suggest to not support splitting an existing seed.

Word Lists: SSSS can be used to split arbitrary bits into several shares of the same size. It would probably be best to encode the initial binary seed with SSSS from which the bip39 word list is computed. This means that the language must be fixed, because the same binary seed produces different keys for different word lists. I would imagine that the SSSS word lists contain one or two additional words specifying the language and the SSSS scheme (M, N, share nr, version number).

Seed Length: Because of the additional words, the SSSS seeds for 256 bit would not be suitable for cryptosteel or similar that assume at most 24 words. One could reduce the bit length a bit to fix it, e.g. specifying that the last 10 bit are 0. Or one could only use 192 bit seeds (18 words) and add two words. The security is still better than anything bitcoin with 256 bit ECC and 160 bit addresses can promise.

The main problem is to make this a long term standard. So that after 5-50 years there are still implementations around that can recover a shared secret and compute the private keys.

prusnak commented 8 years ago

Check https://github.com/trezor/python-mnemonic/blob/master/test_shamir.py

These are just experiments, but could become a BIP39-like standard later.

I did this quite some time ago, so I am not very satisfied with it, but I think it can be polished to usable form.

That said, this is something I would like to keep for TREZORv2 because of the crypto that is missing.

prusnak commented 7 years ago

JFYI: Jochen, we are trying to come up with a new SSSS standard. Added you to shared document via gmail ...

rkagerer commented 6 years ago

Just wondering, did anything ever become of this? (EDIT for anyone else landing here from a google search: I saw some recent talk on this reddit)

prusnak commented 6 years ago

The new standard is being drafted here: SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes

jb55 commented 6 years ago

@prusnak has there been any work done on the firmware side of this since the standard was drafted? I have a client who could use it, and I don't mind looking into the initial implementation if it hasn't been started yet. Perhaps if I could be pointed into the right direction in the codebase? Thanks!

jb55 commented 6 years ago

I see there is a competing implementation as described here: https://github.com/satoshilabs/slips/issues/262 perhaps it's a bit early to start implementing this? cc @onvej-sl

prusnak commented 6 years ago

Don't implement anything unless the standard has been approved.

rkagerer commented 6 years ago

I feel like this has been stalled for ages. Is there any hope of a standard getting approved anytime soon?

It would offer users a tool to plug what I consider a serious, widespread gap in their security practices i.e. writing down seed phrase backups in clear text. Alternatives are either very complicated and/or unsafe to implement external to the Trezor (or whatever device already knows your seed).

Any way we can help?

prusnak commented 5 years ago

SLIP-39 will be implemented in the monorepo soon: https://github.com/trezor/trezor-firmware