Shamir to 12 words and vice versa

putting aside best practice and security concerns… how can I

that’s is not true, is it?
the shares given to me by Trezor are backup of all the possible wallets (that differ by submitted passphrase)

is there a way to create another shamir setup (from let say 2/3 to 1/1 or to 3/5… doesn’t matter) that preserves the same metadata?
the tools I used doesn’t support it clearly

Yes, the shares given by Trezor are the full backup.
A MS (or EMS) that you recover from them is not.

Technically, yes. The shamir_mnemonic Python library allows you to read out and/or specify the identifier.

Practically, I don’t know of any user-facing tool that would allow you to set the identifier.

To expand

You can use the SLIP-39 spec to:

  1. choose a Master Secret
  2. encrypt that Master Secret under some passphrase
  3. later, after providing that same passphrase, recover the same Master Secret.

And this is what I mean by “backing up one particular MS”: you have selected and fixed your secret, there is a single “valid” passphrase that will recover the secret that you chose, and all other passphrases are “invalid” in that the decryption is some random looking bytes that have nothing to do with your chosen MS.

(this is also what you are doing on the slip39 website)

It is decidedly not what Trezor is doing, and that is why, following this script, you will not get the same wallets that Trezor gives you.

thanks for your excellent support - now I finally understand the whole thing
unfortunately it weakened my trust in Trezor shamir implementation, I find it confusing and poorly designed (not with respect to security but let say when it comes to transparency and KISS approach)

anyways… I fully stand behind my closing post from Dec 23rd and hope someone will pay attention to addressing these issues
if nothing else then the possibility of displaying shamir shares in any quorum configuration (based on current MS and additional parameters stored in the device) should be definitely allowed - otherwise it represents sort of a “vendor lock-in” - if you don’t agree then I’d really like to hear a tangible counter argument why not and “increased complexity” or “user’s best interest” doesn’t count :wink:

thanks a lot

Well, you’ll be happy to learn that despite my objections earlier in this thread, we are actually developing exactly this feature right now :slight_smile:

iiii mean there’s nothing “vendor” about it, literally anyone is free to implement this in their product, according to the public spec and publicly available reference implementation

and I’d argue there is no “lock-in” about it either – otherwise you’d have to call Trezor not supporting e.g. Polkadot a “lock-in” too. Like, it’s something, but this doesn’t seem to be the right word at all.

I’ll leave your actual objection standing :slight_smile:

you made my day :wink:
what is the ETA?

I already started patching the JS library to maintain the metadata but your way is the right one for sure…

I don’t fully agree but a little disagreement cannot harm

again I appreciate your time and effort

no ETA as usual, but you can follow progress here and in the attached issue

just to make sure I won’t get disappointed ;)… will it support different quorum and total number of shares than the original one, right? I expect as this information is probably/hopefully not stored in Trezor but one never knows :slight_smile:

you will be able to create new groups of M-of-N, and you can pick M and N.

it looks like we won’t allow creating new SuperShamir backups from normal Shamir, that’s currently under discussion

so, good news bad news

Good news, the feature is now present in firmware 2.7.2. It is currently not possible to go from “basic” (one set of shares) to “advanced”, but are likely going to lift that limitation.

Bad news, it won’t work on currently existing slip39 shares. We had to change the SLIP39 spec to get rid of the identifier involvement, which is what the process will be doing. But older share sets don’t allow that (as we talked about in this thread) and as such are unsupported for this feature.

if what you’re saying is that one won’t be able to change the number of shares for EXISTING backups then it’s beyond ridiculous

ok, so back to the very beginning…

it doesn’t seem to be the case - the identifier is not exposed to the user and it’s not possible without tampering with the code (see /python-shamir-mnemonic/blob/master/shamir_mnemonic/