SLIP-39 based on BIP-39

I stumbled upon this cool Python project for SLIP-39 that makes it super easy to create and save mnemonics in SLIP-39 format, which works with Trezor wallets. You can also switch your current BIP-39 backup to a more secure SLIP-39 one while keeping all your wallets and addresses intact. This is really handy if you're using hardware wallets that don’t support SLIP-39, like the Trezor One for example. With this tool, you can split your BIP-39 into several parts or groups and restore them whenever you need to. This is an open-source project, and you can check it out for more info and instructions on their site and GitHub page:

That's a nice find. Did you have a look at the code? Is it trustable? Before I would use it, I would want to inspect it myself to verify it doesn't have some shady parts. As the old mantra in crypto goes: don't trust, verify! (Considering my rather low coding skills it'll take me quite some time for verification.) Next is that the app and GUI need to be fully able to be build from the Github code, ideally the builds are reproducible. Not sure if reproducibility of compiled apps is currently possible (so far I didn't have time to look and check). I won't run untrusted or unverified code/apps on any of my systems that come close to some of my crypto stuff. It's good more tools show up dealing with SLIP-39. Let's see how this tool stands the test of time.

This is open source tool, so anyone can check the code before using it. If you want more information about the project than better ask developer Perry Kundert, but I expect this toll will be more useful in future when more wallets adopt SLIP39.

I was recently reading about SLIP39 and something caught my attention: that converting a BIP39 mnemonic to a SLIP39 requires nothing less than 59 words. This seemed weird as hell, why does it need to store 512 bits, so I've then read the specs. Somewhere around the end it was mentioned that SLIP39 actually encodes the BIP32 master seed. But BIP39 uses some good 2048 rounds of PBKDF to derive the 512-bit seed from the whatever mnemonics. So then it hit me: SLIP39 skips PBKDF completely and uses the entropy itself as the BIP32 seed! Now, the big question: wasn't the PBKDF itself a very convenient way to harden attacks, as it slows down brute-force attempts? WHY was this step removed for SLIP39? It seems to me, that a 20-word SLIP39 is much weaker than a 12-word BIP39, because, even though they are both 128-bits of real entropy, BIP39 would be ~2048 times harder to brute-force.

Hm, that's a good opportunity to actually look up the details: https://github.com/satoshilabs/slips/blob/master/slip-0039.md A 128-bit entropy is encoded in multiple 200-bit (Shamir Secret Sharing) shards. The individual shards contain a lot more information, making it possible to easily spot if shards belong together and also use a significantly more sophisticated checksum (the last three words of every shard). See https://github.com/satoshilabs/slips/blob/master/slip-0039.md#format-of-the-share-mnemonic for more details. Also the wordlist of SLIP39 is half the size of BIP39, more carefully chosen (first four letters identify each word uniquely), therefore every word encodes only 10 bits instead of 11 bits in BIP39. So, sort of naturally SLIP39 is therefore quite more verbose. Regarding what SLIP39 tries to achieve, I don't mind it. Regarding your claim that SLIP39 uses less PBKDF2 computational work, I think you're wrong if I understand the SLIP-0039 part correctly about Encryption of the master secret: Because there are four iterations of the Feistel thing, I understand it that SLIP39 actually uses 4x2500=10,000 rounds of PBKDF2. In above PBKDF2 footnote 6 link this is clearly stated: From my understanding after briefly looking at SLIP-0039, I think you're wrong on both parts. Nope! Any single 20-word shard doesn't reveal anything of the encrypted secret therein. And you're wrong on the amount of PBKDF2 rounds that are actually used by SLIP39 massaging the master secret to get an encrypted master secret which is packed into SSS. Hm, is it possible that you deduced your critisism based on this? I would say this is a special case, but to understand the consequences in more depth I would need more time and look at the actual steps taken. There's really more to look into and not possible by my "brief glance" at SLIP-0039. Also SSS needs to be very carefully implemented to not fuck up badly. And that's not easy to spot and judge for non-cryptographers. I'm happy to be corrected if I'm wrong.

Cricktor explained things much better than me, so I won't go into details, but you should know that same trezor developrs who created BIP39 also created SLIP39. Brute forcing SLIP39 is practically impossible with current technology, and from my research entropy is the same for SLIP39 and BIP 39 with 12 words. Only using BIP39 with 24 words have higher entropy, but that is overkill in my opinion.

Nice find but I doubt most persons will be trying it out here actually. Basically most of the time people don't bother changing wallets. You can find a particular holder using one wallet for over 5 years some without even bothering to update since they have to re verify the PGP keys if they do and they're probably lazy to. SLIP-39 even if it's nice has a lower user count compared to BIP39 because of mostly compatibility issues since there are fewer softwares out there that support slip39.

The issue wasn't about SLIP39 needing more words due to a smaller dictionary or error correction. FWIW it might as well encode in base 2 and have a triple-sized redundancy. Answer this: if the master secret is encrypted, but the master secret is actually the BIP-32 master seed of the HD wallet, does not that mean that the encryption itself has nothing to do with the master seed security? What is the real purpose of the mentioned encryption? If it's just about having the SLIP39 SSS backups, it does not actually affect at all the seed's entropy, or am I wrong? Why would it be a special case? SLIP39 simply encodes the (whatever-encrypted) master seed. So here's what I get from all this (correct me if I am wrong): BIP39 security: - generate entropy (128 or 256 bits) - encode entropy (12 / 24 words) == MNEMONIC phrase - DONE - BIP32 master seed: PBKDF2 the encoded entropy lots of times, end up with 512 bits (master seed) - brute-forcing the wallet requires doing PBKDF2 SLIP39 security: - generate entropy (128 or 256 bits) - directly use it as BIP32 master seed (since this is what a BIP39 + PBKDF2 phase ends up with as well) - "reverse-encrypt" (?) the master seed -> for SSS backups maybe? - brute-forcing the wallet requires no PBKDF2 (am I wrong on this?)

Not sure when I have the time and understanding to dig through the reference implementations. I'm missing quite some details from the SLIP-0039 text. From where and how do you come to the conclusion that a generated entropy (commonly 128 or 256 bits) is directly used as BIP32 master seed? (Do you mean by BIP32 master seed what is BIP39 Seed in https://iancoleman.io/bip39/ or Seed Entropy, 64 bytes, in below diagram?). I'd love to have a diagram for SLIP-39 like this for BIP-39: The source once was (unfortunately now not working anymore as the Github repo seems to have been deleted): https://raw.githubusercontent.com/EAWF/BTC-Toolbox/3938785f186c76598989cc0aa017ad351483d3b1/Images/KeyDerivationTechnicalOverview.png It was added to the repository with this commit: https://github.com/EAWF/BTC-Toolbox/commit/3938785f186c76598989cc0aa017ad351483d3b1 -- But it was removed by the uploader for a slightly insignificant reason, some surviving image copies in Reddit show that it's uploaded by the same user. Link to the commit that deleted it: https://github.com/EAWF/BTC-Toolbox/commit/f75e2b352ec9facc8d2da52b5ec303fb280c3298 I don't believe that generated (random) entropy with too small size (128 or 256 bits) is used in SLIP-39 directly as BIP32 master seed or Seed Entropy (512 bits) according to above diagram. But right now I can't prove it as I still don't see the "big picture" and data flow of SLIP-39 fully. Encryption and decryption of the so-called EMS (Encrypted Master Secret) uses 10,000 rounds of PBKDF2 in SLIP-39. PBKDF2 in SLIP-39 uses deliberately HMAC-SHA-256 (256 bits size) and as far as I understand it, combine a L and a R parts (see my previous post)  which are mangled in these four rounds of Feistel encryption. The concatenation of L and R in whatever state gives a 512 bits blob that I assume is used similarly to the Seed Entropy before it is broken up into a Master Secret Key (256 bits) and Master Chain Code (256 bits), likely similar to the end of the BIP32 Root Key Derivation in above diagram. I could be wrong of course. Because the SLIP-0039 text isn't very clear about data flow, quite disappointing for my taste, I think we have to dig a bit through the reference implementations linked in SLIP-0039. I don't believe so, but atm I can't point to the exact spots in the SLIP-39 implementation. You must have some "entropy stretching" involved, because how do you want to get from 128 bits of (random) initial entropy to something similar or equal to Seed Entropy (512 bits) and finally a Master Secret Key and Master Chain Code, each 256 bits size.

This is definitely a very good find mate. This is a solid example of how backup schemes are maturing beyond “write down 24 words and pray." The SLIP-39’s group and threshold design is particularly interesting for distributing trust across people and locations. That said, we mustn't forget that complexity can be a double-edged sword. From your experience, where do users most often misconfigure SLIP-39 setups? And do you think the added security outweighs the increased risk of human error compared to simpler BIP-39 backups?

Because, uhm, it says clearly that what gets encoded is the BIP32 seed (the result of 2048 PBKDF2 rounds on the encoded entropy, e.g. 512 bits, which means: it also uses the 128 or 256 initial entropy bits as the master seed for BIP32 HD wallet). So, I've read the spec again, and at this point I'm gonna stick to my initial statement, unless proven wrong: SLIP39 security, given the same entropy level, is much worse than BIP39 security. The PBKDF2 done in SLIP39 (those 10.000 rounds) are only meant for deriving the key required to decrypt the backups. They have nothing to do with deriving the master seed. Hence. the attack on the master seed is performed DIRECTLY in case of SLIP39, which is bad news in case brute-forcing becomes viable.