Is there a tool that can convert my shamir backup (let say 2 out of 3) to standard 12 word seed and vice versa?
Nope, can’t be done. The backup types are not compatible; there is no combination of 12 words that will give you the same wallet as any Shamir backup
Don’t know what you mean by “compatible” but both backup types should end up with the input for PBKDF2 generating 512 bit seed from which point the situation is the same no matter what backup scheme is used.
I cannot input links (wtf? :)) but if you google “convert_any_1224_seed_into_a_shamir_backup” you’ll see something that looks like a plausible solution. What is for instance wrong with that?
Thanks
yeah, but they actually don’t.
per BIP32 you start with a “seed value” of 128 to 512 bits that gets HMAC-SHA512’d into the master extended key.
In case of BIP39 (standard backup), you have a mnemonic generated from some entropy, which you feed into a PBKDF2 (I believe this step is what you meant?), and the output becomes the “seed value” – which then gets HMAC-SHA512’d again to become the master extended key.
In case of SLIP39, the output of the share recovery process is something called a Master Secret, and it is used as the “seed value” directly. The size of the MS is 128 bits for 20-word Shamir or 256 bits for 33 words.
(per spec, but not enabled in Trezor, also 59 words for 512 bits).
BIP39 seed mnemonic, after passing through PBKDF2, cannot ever give you a 128-bit seed value to generate the same BIP32 wallet.
(it’s kinda possible to go the other way, encrypt a 512-bit seed value you got out of a BIP39 mnemonic via Shamir to get a set of 59-word shares. In this case however you’re still only getting one particular seed+passphrase combination.)
There’s a bunch of schemes that implement Shamir on top of (a subset of) BIP39. But SLIP39 is not doing that.
thanks for your explanation, I must say it’s a little bit disappointing, confusing and I don’t get why SLIP took this approach…
I’m personally using shamir + password on top which suggest there must/should be PBKDF2 involved generating different master keys (on the fly depending on the password submitted)
Well, okay 
yes. The output of the share recovery process is actually an Encrypted Master Secret. You run the passphrase through PBKDF2, use the result as a symmetric key for a small custom block cipher, and decrypt the EMS with that. Due to block cipher properties, the decryption will give you a different MS for every different passphrase. But the output is still the same size, 128bit MS for a 128bit EMS.
1 Like
thanks for explanation, now it makes sense… yet it makes me honestly a little unease as it doesn’t feel like a straightforward solution to me - is the some public article about the reasoning behind this approach?
putting aside BIP39 and considering purely SLIP39…
do I understand it correctly there is no other/easier way to recover something alike BIP39 backup (single set of words more suitable to remember) than using a tools on my PC and transforming my shamir shares (whatever configuration… like 3 out of 5 or 2 out of 3) to 1 out of 1?
The correct choice for that is making a Super Shamir with two groups, a 1-of-1 for remembering and another (e.g., 3-of-5) for splitting up and secure storage. Set the group threshold to 1, so that you can recover either (a) with one share from memory or (b) by recovering 3 of the stored shares from the second group.
(memorizing your seed without a physical backup is strongly discouraged – you’re one unfortunate bump on the head away from losing all your money)
You can’t convert an existing backup configuration on Trezor, which is kiiiinda a deliberate choice: (a) the UX for that would be difficult to figure out and (b) regenerating an existing backup kinda-sorta opens some holes in the security model, namely, there are now multiple completely independent backup configurations leading to the same wallet.
So that is a Yes to your question, if you want to convert an existing backup, that can currently only be done with a PC.
Mind you, the secure way to do this is to compile a custom firmware with the “only one backup” rule removed. (you might also need to drop some other restrictions, e.g., allow Super Shamir backup from a Basic Shamir secret, or allow 1-of-1 in Basic Shamir)
Then you would install this firmware, recover your shares into it, trigger the backup flow and set up a new configuration.
of course it’s meant to be an alternative (to memorize) not a replacement of physical backup
I appreciate your support and I hate to criticize all the time 
but I hope that you understand that
this
and that
is pretty contradictory and your deliberate decision not to allow something totally straightforward pushes the user to a obviously much more dangerous situation and ideas like working with shamir backup of existing device on a PC.
Current user who own Trezor for years are (“vendor”) locked in a situation that could be easily avoided by letting the user work with his current seed in Trezor (the safest place to do so). Instead you’re pushing people to way more unsafe and inconvenient position like playing with the firmware, new device and transferring the coins to a new wallet (implicating trouble like huge fees, losing coin control mixing UTXO, not mentioning possibility of human error and time consumption.
No, no, you’re missing the point, which is don’t do this
We don’t provide convenient tools for people to mess with their backups because we don’t want people to mess with their backups. This is the strong security stance. A very clear, tractable way of managing backups is this:
- you have a backup of one wallet.
- if your backup is lost, assume that it is compromised
- you can invalidate that backup by moving funds to a new wallet.
You have a point in the other thread, that it may be useful / friendly / still secure to allow showing the seed mnemonic from a Trezor that was already backed up before. That is allowing you to make copies, which you can already do by hand from your existing backup. On certain metrics, it’s not making things any worse.
Reconfiguring the Shamir backup of the same secret decidedly does not fall under this. It is neither clear nor tractable: you created a new backup (not a copy!) but did not invalidate the old one. This is absolutely a footgun.
Now, I am not claiming that the current state of things is “good”. There is a lot of room for improvement, and we will continue working on it.
I am asserting that (a) this is a difficult problem and careful design is needed, and (b) providing a naive implementation of “just do whatever to the seed” weakens the security stance.
One part of this design is enumerating sensible usecases. Right now Shamir is rather awkward in that you first need to figure out your backup configuration, then create a new wallet with that configuration. This makes a lot of sense when migrating from BIP-39: you absolutely should invalidate your old backup when moving to the new configuration, otherwise there could, in theory, be an “unauthorized” one-ring-to-rule-them-all backup floating around wherever.
It makes less sense in your case, where you first create a 3-of-5 setup, and later explicitly want to add new access rights to that setup. But yours is an edge case. In general, “adding rights” without the clear ability to “enumerate rights” and ideally also “revoke rights” is a footgun.
(and the “enumeration” is a huge problem – one Trezor could in theory remember all configurations coming from it, but a Trezor which you restore from the backup will not know anything).
Moving all coins to a new wallet is a hassle, yes, but it has a massive usability advantage in that you already know perfectly well how to do it. And moving coins is the second most secure thing you can do with a HWW (the first being “keep it locked in a box”).
Sure, it is a hassle – a hassle worth a completely separate solution, because in case of seed compromise this is what you want to be doing anyway.
thanks for your effort and time… I totally understand that many more experienced people thought through these scenarios
I’m simply trying to point out some stuff where I believe Trezor designers are too much in “god mode”
let’s consider a (very plausible) scenario:
imagine somebody with 100BTC (in 10 accounts, 1000 UTXOs, all labeled, documented)
held via 2x model T (one primary, one secondary) initiated with the same seed, (good) password protected, good PIN used and let say 5/8 shamir backup safely stored and distributed geographically
responsible person, all by the book, family knows, trustees/attorneys know, airplane crash situations covered
then one Trezor dies, is destroyed or stolen
the user switches to the secondary device, naturally buys a new one and wants to initiate his new (backup) device
and… surprise… it’s NOT POSSIBLE, wtf, everything is fine, under control, but somebody decided on his behalf that it’s not safe to reveal the Master Secret (just stressing out that additional passwords are used) despite it’s stored in readable form in the working device (no secure element btw…) in his hand
instead Trezor suggests two option
- create a new backup, do everything from scratch and move all your password-base wallets, accounts, UTXOs, labels, …, pay the fees, take unnecessary risk, create and distribute all the shares etc…
- go/fly wherever you stored your backups, mess with all you prepared for a real emergency situation and recover your secondary device using your shamir backups
GOOD LUCK with standing behind these options…
my only point is… there SHOULD BE a CHOICE
This is an X-Y problem.
The actual underlying usecase is “I want to be able to clone my Trezor for redundancy.” An interesting and valid usecase, possibly worth adding a feature.
“Allow the user to see the Master Secret” is just one possible solution of that usecase. Another is, off the top of my head, something like end-to-end pairing the two Trezors, allowing them to exchange the seed under the hood without ever exposing it to the user.
Now let’s talk security design.
You seem to be thinking (correct me if I’m wrong), “this is just a simple matter of showing the seed to the user, done, problem solved”, and “why tf are you deliberately making this simple thing so hard??!?”.
I and my colleagues have to think from a different angle: what else can this feature do, especially if we install it on all Trezors for all users?
The answer is somewhere between “a whole lot actually” and “I don’t really know, which is a problem”.
For one, remember the whole Ledger Recover hoolaboo? For a lot of users, there is the strong expectation that the seed never leaves the device. I hope you see that implementing a feature doing exactly that would not be received well
Second, is cloning your device really that good of an idea? One thing it does is provide a hassle-free way for tech support scammers to steal things from users. So you’d need some strongly worded warnings in the user’s face before doing that, maybe hide the feature behind some config flag only available from the command line … at that point, we’re doing a whole lot more than “just expose the seed dammit”.
Again, I want to stress that you have valid points. The status quo is nowhere near perfect, and there are situations in which the user would be better served if a feature like “show the user the master secret” existed. If you start at wanting this feature, you can easily generate a dozen legitimate situations and usecases for it.
What I am saying is, the problem lies in all the other situations in which it is undeniably better that the feature does not exist. You are a power user, you seem to know very well what you’re doing. More power to you. It would make my job so much easier if everyone was like you but it is not the case.
There are tradeoffs here, and the current one might be changed. But it’s definitely not as simple as “there should be a choice”.
ok, I think all important was said and no need to repeat ourselves
I’m obviously no security expert but my background in math and software development allows me to appreciate all the aspect of security design you pointed out and I mostly agree with all you say
allow me to summarize my stance (hoping somebody will consider it and reflect in future development)
- one shouldn’t be forced to touch word seed or shamir shares unless the last device is damaged or lost
- one shouldn’t be forced to move his coins and change the seed unless the current one was compromised as (amongst many practical/economical reasons mentioned previously) there might exist signed (yet not submitted) transactions or addresses being part of complex schemes or contracts
- the seed (or master secret) stored in the device shouldn’t be considered safe under any circumstances (presence of secure element doesn’t change much in my opinion) and if anything should be forced by Trezor (for the benefit of the user) then it’s usage of additional password (plausible deniability is the ultimate function and only real protection against all the malicious actors as well as $5 wrench attacks) - with this in mind I personally don’t see any valid arguments why the firmware should not allow display of the backup (in any requested configuration N out of M)
these pretty common situations require a simple solution
- one needs to clone the device
- one needs/wants to change the shamir quorum ex-post or create alternative shamir backups for different scenarios while keeping the master secret unchanged (which solves 1) as well obviously)
I’m aware that most users don’t recognize any of these problems but I strongly believe that looking at it from the perspective of an experienced bitcoin user actively working with the coins, being existentially dependent on it, thinking globally and traveling around world, it makes a lot of sense
thanks for your time
1 Like
After couple of months (and still not happy about the situation and Trezor design) I did some tests using a new device and this tool http//iancoleman.io/slip39/ to better understand what’s going on.
I have 2/3 shamir backup generated by freshly initiated Trezor Model T. I set up one standard and two passphrase protected wallets with come balances to be able to distinguish what is what.
I verified the recovery process using any two shares out of three, works fine obviously.
Then (following my original objective to create an alternative 1/1 shamir backup suitable for memorizing or whatever purpose) I used the tool linked above (Combine section) and recovered the Master Secret using 2 shares (and no passphrase) from the original set.
Then I used same tool (Create section) submitted the recovered Master Secret and created a new alternative shamir scheme 1 of 1 and no passphrase submitted.
I verified this new single share produces the same Master Secret - all seemed good.
Then I factory reset my Trezor device and recovered the wallet using 1/1 share, which was straightforward and my standard wallet was accessible again - so far so good, all was expected.
Now, I tried to open one of the passphrase protected hidden wallets and, to my huge surprise, this didn’t work - the wallet was empty.
I must say I’m totally confused and the slip39 specification on github doesn’t help me to understand.
What is actually stored in the Trezor device? The Master Secret (this would make sense to me as then endless number of hidden wallets can be accessed using endless number of passphrases) or the Encrypted Master Secret (which doesn’t seem technically sensible).
Can you please help me understand what’s going on here?
thanks
It just so happens that I ran into exactly this a couple days ago. There’s an additional subtlety about the way Trezor uses SLIP39, that should not be there in my personal opinion, but here we are.
It’s the latter. Trezor stores an Encrypted Master Secret that was randomly generated. Due to properties of block ciphers, you can “decrypt” the EMS with any passphrase you like, and the result is a perfectly fine Master Secret which is a basis for a wallet for that passphrase.
Now comes the subtle part: the SLIP39 identifier is a parameter of the passphrase encryption (along with the iteration exponent).
Given a fixed MS (which you recovered and then re-encrypted), and an identifier 'a, encryption with the empty passphrase will give you EMS'a. Using a different identifier 'b will give you a different EMS'b. Now, you can decrypt both EMS'a and EMS'b, using their corresponding identifiers and the empty passphrase, to recover the original MS.
But if you use a different passphrase, the results from EMS'a and EMS'b are going to be different!
In conclusion, the Master Secret is not actually a full backup of your Trezor. It is only a backup of a wallet matching a single passphrase.
The full backup is EMS + identifier + iteration exponent.
hmm, this design is really something…
so fresh Trezor device creates random EMS and it’s “translated” into shamir shares
when recovered (using your own words) “The output of the share recovery process is actually an Encrypted Master Secret” and it’s re-stored to the device like nothing happened
now going back to my case… I take my shares (2/3) and use the linked javascript SLIP39 tool to transform it into another shamir configuration (1/1)
using this single share for recovery I should end up with the same EMS - yet it’s not the case… and only no-passphrase wallet is working and no hidden wallets - I don’t see why
btw this statement of yours “Given a fixed MS (which you recovered and then re-encrypted)” confuses me - you said EMS is stored in Trezor and MS doesn’t exist - it’s only dynamically “decrypted” with given passphrase (an empty one for standard wallet and endless hidden wallets based on endless passphrases)
so no MS is actually recovered, or is it?
The trouble is, you don’t end up with the same EMS.
Normally you would think that if you encrypt a MS with an empty passphrase, you get some fixed EMS corresponding to that MS + passphrase.
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.
So there are 2^15 valid encryptions of the same MS with the same passphrase – one for each possible value of the 15-bit identifier.
The slip39 website, quite reasonably, generates a new identifier for you. So when you re-encrypt the MS, you are getting a different EMS tied to the newly generated identifier.
This is still a perfectly valid encryption of your original MS! Given its identifier, and the “correct” passphrase, it will decrypt to the original MS.
But the property of “can be “decrypted” to anything” no longer holds the way one would expect. A different EMS, given some other passphrase (plus of course the different identifier), will decrypt to a different MS.
Yeah, it is confusing.
The “decrypted” MS is the master seed (in BIP-32 terms) for your wallet.
There is no valid decryption of Trezor’s randomly generated EMS – or, all “decryptions” with all passphrases are equally valid.
What you are doing is choosing a particular decryption (by choosing the passphrase), decrypting to a particular MS, and then backing up that MS.
But it’s only that one MS that you are backing up.
The backup process works exactly as intended, and you will always be able to recover your original MS. But by starting at a MS and encrypting it, you have chosen one valid decryption of the resulting EMS. All other decryptions are “invalid”, in that they don’t correspond to anything anymore.