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:
- choose a Master Secret
- encrypt that Master Secret under some passphrase
- 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 
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 
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
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…
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
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/shamir.py)
I would like to follow up here; last reply was a year ago.
In 2021 I backup up a “T out of N” shamir backup on my Trezor Model T. After a firmware upgrade the Trezor had to reset, and I’m now to put in my phrase sets.
Problem: I can only put in one set. I think Matejcik explaind why that is - fine for me.
If I get this right:
- Getting the master key from my shamir / Slip39 backup is possible (e.g. using the “Combine” method here: iancoleman .io / slip39/ )
- Trezor does not use a pass phrase here (I’m assuming)
- There’s a hidden identifier inside the backups, which does not influence the Master Key, but is still necessary.
- The Trezor does not store the master key on it directly, but an encrypted form of it. In order to get that encrypted form and restore the Trezor, that identifier is needed.
- Also: I cannot put in T phrase sets on the trezor, but only ONE set (12,18,28,24 or 33 words)
- There’s currently no (documented) way to extract that identifier from the (T out of N) backup phrase sets.
Any pointers in how to get that identifier out? I could try to code some python, possibly.
Is this correct? (And: How did @foo get his backup recovered, may I ask?)
This seems 100% unrelated to what we were discussing here. Trezor T will let you enter as many shares (a single set of 20 or 33 words is called a “share”) as you need to recover your wallet backup.
Are you running into a problem at this step?
from your description I’m not totally sure what you’re trying to achieve… however
you can use iancoleman / slip39 tool, patch the javascript and extract three values (master secret, identifier and iteration exponent) which represent the whole backup
patching the same tool and submitting these three values would allow you to re-create the shamir backup scheme of any configuration (M out of N)
depending on your situation this should be done with extreme caution on a dedicated offline hardware (e.g. boot live cd on an old laptop, avoid any network connection, etc.) - Trezor could/should save you from all this but they simply decided not to and don’t support repeated backups of ‘old’ shamir backups created by the device before version 2.7.2
this is ridiculous… you definitely didn’t have to
Yes, you are right. I thought it was related to this - but probably isn’t.
After trying again I could input all parts, and it’s recovered now. Thanks for the heads-up.
Also: it makes sense that this works, as the number of required shares is incoded in the phrases. After putting in the first it told me to put in the other ones.
Sorry for the confusion!
@matejcik Could you please clarify. You said that you had to change the SLIP39 spec to implement the feature. How does it work now? Is it still compatible with the link posted above? As I understood the link uses identifier (at least used to use it) and you’ve said that Trezor implementation got rid of it. If it’s the case, is it now possible to correctly transform one Shmir backup to another one without using the Trezor software?
Another question which I don’t fully get from the discussion above. If I use the Shamir backup and I use for example 10 different passphrases on top of it to make my wallets. When I restore the backup will I still have access to the same 10 wallets using the same 10 passphrases?