Clarification on SLIP-39 + Passphrase Implementation in Trezor Safe 5

Security About seeds and wallet
1

Hi Trezor Community,

I’m working on recovering a forgotten passphrase on my Trezor Safe 5 and need clarification on your cryptographic implementation.

Current Understanding:

  • My Trezor Safe 5 generated a 20-word mnemonic following SLIP-39 standard
  • The device allows me to add an arbitrary user-chosen passphrase on top of this mnemonic
  • This passphrase + mnemonic combination generates unique Ethereum addresses

Technical Question: In standard SLIP-39, passphrases are typically integrated during the secret sharing process itself. However, your implementation appears to work differently - it seems like you:

  1. Use SLIP-39 to recover the master secret from the 20-word mnemonic
  2. Convert this to a seed
  3. Then apply BIP-39 style passphrase derivation to generate addresses

What I need to confirm:

  • Does Trezor Safe 5 recover the SLIP-39 master secret first, then use BIP-39 passphrase derivation?
  • Or does it use a different approach for combining SLIP-39 mnemonics with user passphrases?
  • Please confirm that the derivation path for Ethereum address generation is "m/44'/60'/0'/0/x"?

Context: I’m developing a programmatic brute-force tool to test passphrase combinations (I have the mnemonic, know the output address, and know components of the passphrase just not their order…). I can manually test with the device, but this is time consuming. I would therefore appreciate it if you could help me understand the exact cryptographic process to implement this efficiently in code.

I’ve been testing with:

Master Secret = SLIP39.recover([mnemonic]) 
Seed = PBKDF2(master_secret, "mnemonic", 2048, 64) 
Final_Seed = PBKDF2(seed, passphrase, 2048, 64) 
Address = derive_ethereum_address(final_seed)

Is this approach correct for your implementation?

I tried having a look at your documentation What is a passphrase?
but it doesn’t even reference the possibility of this with a 20 word mnemonic. I would assume that the documentation hasn’t been updated?

Any additional technical documentation or confirmation of the exact process would be extremely helpful.

Kind regards,

2

You’d want to review the SLIP39 standard first. It should contain the details you are looking for about how passphrase is derived in SLIP39.

Good luck!

3

This is technically incorrect.
For both BIP39 and SLIP39, the passphrase is an integral part of the derivation process.

The “on top of” thing comes from wallet UX: you can use “plain” seed or “add a passphrase”. But the “plain” option only means “automatically use empty passphrase”, nothing else.

Nope, they’re not.

Not even a little how this works.

Where did you gain the understanding? Check your sources. They are highly confused.

That’s a decisive No.

Yes.

I’m gonna expand on this one because that’s the most tricky part of SLIP-39 in HWWs.

The result of SLIP-39 share recombination is an Encrypted Master Secret.
The passphrase plugs in as a decryption key, to get out the Master Secret.
(Different passphrases give different decryptions, and so different Master Secrets.)

Then you plug the decrypted Master Secret directly into BIP-32 Master Key Generation

…no PBKDF2 in sight, just people living in the moment…

1 Like
4

Thanks @NickW and @matejcik — I really appreciate your insights and patience here.

I wanted to follow up after some additional work. After quite a bit of reverse engineering and testing (using a second device), I was able to fully map out the cryptographic process and, most importantly, successfully recover my lost passphrase :pray:.

Given how little documentation exists on combining SLIP-39 with user-chosen passphrases, I suspect others might run into similar issues in the future. I’ve put together a small GitHub repo that implements the derivation logic and can brute-force passphrase permutations (if you already know the mnemonic, the derived address, and the components of the passphrase but not their order).

Before I share it more broadly (here or on Reddit), I wanted to get your opinion:

  • Do you think this would be a useful resource for the community?
  • Or would the potential for misuse outweigh the benefits, even though it requires knowledge of the mnemonic and significant constraints on the passphrase?

I’d rather err on the side of caution, but if it could save people from losing access to their wallets, I’d be happy to make it available.

Kind regards,

1 Like
5

What sort of documentation would you be interested in?
The SLIP-39 spec explicitly talks about this, and it is also a feature of the shamir tool of the python-shamir-mnemonic package.

Feel free to share your project. I believe the potential for misuse is negligible, given the requirements (and also considering that any malefactor could replicate your work in exactly as much time or less)

1 Like