Shamir to 12 words and vice versa

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 :slight_smile: 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?

the best source is the spec itself: https://github.com/satoshilabs/slips/blob/master/slip-0039.md

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 :wink: 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 :wink:

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:

  1. you have a backup of one wallet.
  2. if your backup is lost, assume that it is compromised
  3. 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

  1. 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…
  2. 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 :slight_smile:

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 :slight_smile: 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 :wink:

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

  1. one needs to clone the device
  2. 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