Shamir to 12 words and vice versa

[foo]

putting aside best practice and security concerns… how can I

@matejcik

But it’s only that one MS that you are backing up.

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)

[foo]

@matejcik

But there’s an additional parameter: the identifier, stored in the first 15 bits of the recovery shares.
This additional parameter is not part of the data (the bits necessary for recalculating the EMS), but instead part of metadata.

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

[matejcik]

@foo

the shares given to me by Trezor are backup of all the possible wallets (that differ by submitted passphrase)

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

@foo

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

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.

[matejcik]

@matejcik

@foo

the shares given to me by Trezor are backup of all the possible wallets (that differ by submitted passphrase)

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

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.

[foo]

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

thanks a lot

[matejcik]

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

@foo

otherwise it represents sort of a “vendor lock-in” - if you don’t agree

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

[foo]

@matejcik

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

you made my day
what is the ETA?

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

@matejcik

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

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

again I appreciate your time and effort

[matejcik]

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

[foo]

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

[matejcik]

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