search

iancoleman / slip39

A web tool for SLIP39 mnemonic shares
https://iancoleman.io/slip39/
MIT License
51 stars 22 forks source link

Add field for bip39 mnemonic #1

Open iancoleman opened 4 years ago

iancoleman commented 4 years ago

Add a field for bip39 mnemonic, which automatically converts the mnemonic to entropy and fills the master secret.

Likewise when combining use the master secret to generate and display a bip39 mnemonic.

Not sure if linking the two schemes so closely is a good idea, maybe better to just make a link to bip39 tool with instructions how to use the master secret...?

iancoleman commented 4 years ago

@andrewkozlik @prusnak I would be keen to hear your thoughts on this and what considerations should be had when potentially 'linking' bip39 and slip39...?

The broad idea being to use slip39 mastersecret as the entropy for a bip39 mnemonic and display that bip39 mnemonic in this slip39 tool. Good idea? Bad idea? Is it in the interest of users?

andrewkozlik commented 4 years ago

If you were to combine the SLIP-0039 shares and use the resulting master secret as the entropy for a BIP-0039 mnemonic, as you describe above, you would be getting a completely different wallet. The reason for this is that SLIP-0039 is not built on top of BIP-0039, but it's a separate scheme. Most notably, they each use a different function to generate the binary seed (aka master secret) from the input and passphrase. So I don't see this as being of interest to users.

Creating a tool for converting a BIP-0039 mnemonic to SLIP-0039 shares makes some sense for people who would like to migrate their existing seed to the new scheme and don't want to go through the process of transferring all their funds to a newly generated seed, migrating U2F credentials etc. However, it is not as practical as it appears, because regardless of the length of the BIP-0039 mnemonic, each of the resulting SLIP-0039 shares will need to be 59 words long. This is due to the fact that in BIP-0039 the mnemonic and passphrase are processed by PBKDF2-SHA-512 to produce a 512 bit binary seed, and this is the master secret that would need to get split using SLIP-0039. Furthermore, if someone is using several different passphrases with one BIP-0039 mnemonic to have several wallets, they can only convert one of these to SLIP-0039 shares.

The opposite process of combining SLIP-0039 shares and outputting the corresponding BIP-0039 mnemonic is cryptographically infeasible, because PBKDF2-SHA-512 is a one-way function.

andrewkozlik commented 4 years ago

Slightly off topic, but worth mentioning in terms of SLIP-0039 integration: When I was creating SLIP-0039 test vectors for our device tests I used your online Mnemonic Code Converter. The only problem I had is that the "BIP39 Seed" field is not editable. This field is where I needed to put the SLIP-0039 master secret. Instead I had to manually calculate the BIP32 Root Key and put that in. Making this field editable and renaming it to "BIP39 Seed / SLIP39 Master Secret" would be very helpful.

iancoleman commented 4 years ago

Ah ok I was under the impression that slip39 master seed being used for bip39 entropy was equally valid as use for bip32 seed, but it seems the intention was only to be used for bip32 seed.

Seems like the best additional encoding to display would be base58 bip32 root key (ie derivation path m) and have no connection to bip39 mnemonics at all.

I can see now after re-reading that this is in the slip39 abstract: "SSS splits a master secret, such as the master seed S for Hierarchical Deterministic Wallets described in BIP-0032".

Thanks for clarifying.

dzid26 commented 4 years ago

So what I am getting from this is that for simply splitting BIP39 mnemonics, your original BIP39 and Shamir39 are still more appropriate tools - specifically designed for this purpose.

yancyribbens commented 4 years ago

Creating a tool for converting a BIP-0039 mnemonic to SLIP-0039 shares makes some sense for people who would like to migrate their existing seed to the new scheme.

@andrewkozlik correct me if I'm wrong, but isn't BIP-0039 a newer scheme than SLIP-0039? I remember working on the original SLIP-0039 at RWOT8, and then also the later BIP-0039 at RWOT9. I think there is a valid argument for supporting BIP-0039 as a newer "scheme" which supports round trip from BIP39<->seed<->shards which is not possible with SLIP-0039?

prusnak commented 4 years ago

@yancyribbens Yes, you are wrong. BIP39 is from 2013, SLIP39 from 2017. Also there are very different purposes - BIP39 is single share only, SLIP39 are multiple shares with group support.

wigy-opensource-developer commented 4 years ago

@prusnak Of course nobody should call an implementation SLIP-0039 that treats the BIP39 entropy as the master secret that is split into multiple shares. But it is a natural use-case for upgrading a single share wallet into a multi share wallet deleting/destroying all copies of the BIP39 mnemonic.

Also, it is unclear how to integrate SLIP-0039 with SLIP-0010 in its current form for other curves. Would it be better to standardize these reusing the awesome pieces of technology that appeared in SLIP-0039?

prusnak commented 4 years ago

But it is a natural use-case for upgrading a single share wallet into a multi share wallet deleting/destroying all copies of the BIP39 mnemonic.

Natural, but also error-prone. Every year we have users who thought, they've secured their BIP39 seeds, but it turns out the other person living with them found out and swept the coins.

Also, it is unclear how to integrate SLIP-0039 with SLIP-0010 in its current form for other curves.

Where do you see the issue? SLIP-0039 generates entropy from shares, you feed this entropy into SLIP-0010. It is that trivial.

wigy-opensource-developer commented 4 years ago

The standard says "[SLIP-0039] splits a master secret, such as the master seed S for Hierarchical Deterministic Wallets described in BIP-0032" in the abstract and then never revisits this definition.

If the master secret is not the master extended private key, but the seed, then of course SLIP-0010 can be used.

Also, entropy is used for yet another concept in BIP-0039, so please be careful with the wording.

Thanks for your fast response!

prusnak commented 4 years ago

If the master secret is not the master extended private key, but the seed, then of course SLIP-0010 can be used.

Yes, I use the words "entropy", "seed" and "master secret" interchangeably, sorry about that. :-)

yancyribbens commented 4 years ago

@prusnak I stand corrected (thanks). It seems like I'm confusing SLIPS and BIPS. I'm still concerned that SLIP-0039 shares can't be recombined for use with BIP-0039 wallets etc. This doesn't seem favorable for interop with other devices and creates a lot of confusion imo. I believe the intent with BIPXXX is to maintain compatibility with BIP-0039, although it doesn't look like the current spec defines it.

monperrus commented 3 years ago

In terms of GUI, we could have the BIP39 mnemonic after combination just below the recombined "master secret".

nioncode commented 3 years ago

I think there would be a great value add if it would be supported to take a BIP39 seed as input and generate Shamir shares out of it and vice versa: backing up / restoring already used hardware wallets.

Afaik only Trezor supports SLIP-39, but other wallets would benefit from having a way to simply split up the existing BIP39 seed (that they almost all use) into multiple shares. This would fix the biggest issue of BIP39 seed backups: if someone gets hold of your seed backup, they can sweep your wallet.

Yes, there are downsides with going that route (most important one: you have to be sure that your existing BIP39 seed backups were not breached already), but moving from a BIP39 wallet to a SLIP-39 wallet is a non-trivial operation as well, especially if you are concerned about not joining your UTXOs together.

To be clear, this is a strong focus on only using SLIP-39 for backup/restore of a BIP39 seed, not for moving a BIP39 seed into a SLIP-39 wallet or vice versa. As far as I understood, it is quite easily possible to create SLIP-39 shares out of a BIP39 seed by converting the BIP39 seed back to a 256bit entropy and then running that through SLIP-39. For restoring, just combine the shares and calculate a BIP39 seed from the restored 256bit entropy. In my mind this would make a perfect candidate of replacing BIP39 backup seeds, while still keeping the wallet software itself BIP39 compatible.

secinthenet commented 3 years ago

@andrewkozlik the idea above from @nioncode is exactly what I thought about and commented on in https://github.com/BlockchainCommons/bc-lethekit/issues/38#issuecomment-751904641 and https://github.com/oed/seedsplit/issues/6#issuecomment-751905751

Is there a reason why this shouldn't be done, other than the fact people can be confused? FWIW, I think that if it is indeed a bad idea because it's incompatible with Trezor's implementation (or other existing SLIP39 implementations), the spec should clearly define that SLIP39 is used only for the BIP32 master seed, and nothing else. The way it's phrased right now implies it has flexibility in how it can be used to derive a wallet.

andrewkozlik commented 3 years ago

@secinthenet, technically it is possible, though it wasn't our intention (see https://github.com/satoshilabs/slips/blob/master/slip-0039.md#user-content-bip39compatibility). I am really worried about the confusion it would lead to:

secinthenet commented 3 years ago

@andrewkozlik I agree this can be a great source of confusion for users. I opened https://github.com/satoshilabs/slips/pull/1044 to specify that this is the only way SLIP39 can be used for backing up and restoring BIP32 wallets.

efnats commented 3 years ago

To be clear, this is a strong focus on only using SLIP-39 for backup/restore of a BIP39 seed, not for moving a BIP39 seed into a SLIP-39 wallet or vice versa. As far as I understood, it is quite easily possible to create SLIP-39 shares out of a BIP39 seed by converting the BIP39 seed back to a 256bit entropy and then running that through SLIP-39. For restoring, just combine the shares and calculate a BIP39 seed from the restored 256bit entropy. In my mind this would make a perfect candidate of replacing BIP39 backup seeds, while still keeping the wallet software itself BIP39 compatible.

This is exactly what we've been working on at https://seedhodler.io

We don't encode the BIP39 seed but the entropy which results in smaller shards (20/33 words for 128/256bit entropy) I never published or announced this anywhere because I get nightmares if I think that a user would accidently fund a non-backuped account due to this confusion at the moment. But I feel that here there are people who will know not to use it, yet - or if you do, at least you know what you are doing.

I think the way we want to go forward with this is to support both BIP39 and SLIP39 and make sure to make it very very clear in the interface that shards from a split BIP39 seed can not be recovered in a trezor device.

We want to stick to BIP39 and and could also encode the seed for Trezor with 59 word shards, so that the same wallet can be restored with BIP39 and SLIP39. Decoding of BIP39 and SLIP39 wallets should be supported, too. This way no additional software would be needed for recovery. I'd be interested in your opinions.

Any help is appreaciated. I want to contribute to make splitting master seeds become a thing for everyone.

secinthenet commented 3 years ago

@efnats I suggest adding a very loud and clear warning to seedhodler that this is not SLIP39 compatible. In fact, I would probably use a different word list to further avoid confusion. You may be interested in https://github.com/BlockchainCommons/bc-sskr

adam-hurwitz commented 3 years ago

I think there would be a great value add if it would be supported to take a BIP39 seed as input and generate Shamir shares out of it and vice versa: backing up / restoring already used hardware wallets. - @nioncode

BIP39 and SLIP39 compatibility is important when a user considers the long-term security of their wallet(s) configuration. By generating a wallet with a Trezor device using Shamir's Secret Sharing (SSS)/SLIP39, a user is potentially limiting their future compatibility to only Trezor devices.

This creates risk.

In the long-term, the risk is lowered because Trezor is open-source. Therefore, if Satoshi Labs is no longer able to support Trezor the dev community will be able to support SLIP39 with Trezor.

prusnak commented 3 years ago

BIP39 and SLIP39 compatibility is important when a user considers the long-term security of their wallet(s) configuration.

Andrew already replied above why we did not make BIP39 and SLIP39 interoperable on purpose. There is a longer explanation here: https://github.com/satoshilabs/slips/blob/master/slip-0039.md#Bip39Compatibility

By generating a wallet with a Trezor device using Shamir's Secret Sharing (SSS)/SLIP39, a user is potentially limiting their future compatibility to only Trezor devices.

Not really. There is a Trezor emulator you can run if you don't have a Trezor device. Also there is a PR adding SLIP-0039 to Electrum here: https://github.com/spesmilo/electrum/pull/6917

adam-hurwitz commented 3 years ago

@prusnak, Thanks for sharing the detailed explanation, SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes > Compatibility with BIP-0039, and letting me know about the Trezor emulator! I will look into this further.

Is this the supported Trezor emulator mentioned above? The emulator seems like a potentially good option for tech-savvy users.

In order for higher-scale adoption of SSS, it's promising to see the future compatibility with Bitcoin wallets starting with the Electrum wallet. There will also need to be compatibility with an Ethereum and ERC-20 wallet(s) such as MetaMask and MyEtherWallet.

prusnak commented 3 years ago

Is this the supported Trezor emulator mentioned above? The emulator seems like a potentially good option for tech-savvy users.

Yes, that's the one