SLIP-39 from BIP-39

[dkbit98]

I found one interesting python SLIP-39 project that makes it easy for everyone to generate and backup mnemonics in SLIP-39 format that is compatible with Trezor hardware wallets.
It's also possible to convert your existing BIP-39 backup to a much more robust SLIP-39 backup, while keeping all your wallets and addresses.
This would be very useful in case if you have hardware wallets that don't support SLIP-39, like Trezor One for example.
With this app you can break your BIP-39 in multiple parts or groups and recover them when you need it.



This project is open source and you can find more details with instructions on their website and github page:
https://slip39.com/
https://github.com/pjkundert/python-slip39

[Cricktor]

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.

[dkbit98]

That's a nice find. Did you have a look at the code? Is it trustable?

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.

[kTimesG]

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.

[Cricktor]

...

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.

The last three words of the mnemonic form a checksum and contain no information.
...
This implements a Reed-Solomon code over GF(1024) that guarantees detection of any error affecting at most 3 words and has less than a 1 in 10⁹ chance of failing to detect more errors. More details about the properties can be found in the Checksum Design appendix⁵. The customization string is processed by feeding each character's US-ASCII value into the checksum calculation prior to the data.

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:

The master secret is encrypted using a wide-blocksize pseudorandom permutation⁷ based on the Luby-Rackoff construction. It consists of a four-round Feistel network with the key derivation function PBKDF2⁶ as the round function. This scheme is invertible, which means that the creator of the shares can choose the master secret, making it possible to migrate a BIP-32 wallet from BIP-39 mnemonics to the new secret sharing scheme. The master secret is first split into two equally long parts, where L is the first n/2 bytes of the master secret and R is the last n/2 bytes of the master secret, and processed as follows:

Code:

  L = MS[:len(S)/2]
  R = MS[len(S)/2:]
  for i in [0,1,2,3]:
      (L, R) = (R, L xor F(i, R))

The encrypted master secret is then EMS = R || L.

The i-th round function F(i, R) is defined as follows:

Code:

F(i, R) = PBKDF2(PRF = HMAC-SHA256, Password = (i || passphrase), Salt = (salt_prefix || R), iterations = 2500 << e, dkLen = n/2 bytes)

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 ⁶ link this is clearly stated:

...
The total number of iterations in PBKDF2 was chosen to be at least 10000, i.e. 2500 iterations in each of the four rounds of the Feistel-based encryption function. A larger number of iterations in PBKDF2 would currently impact the user experience in hardware wallets. The creator of the shares is free to choose a larger number of iterations, theoretically as high as 327 million, making the format more future-proof and more suitable for a wider range of environments.

SLIP39 skips PBKDF completely and uses the entropy itself as the BIP32 seed!

From my understanding after briefly looking at SLIP-0039, I think you're wrong on both parts.

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.

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?

SLIP-0039 can be used to back up any master secret S which satisfies the length constraints described above. However, any application implementing SLIP-0039 for backing up a BIP-0032 Hierarchical Deterministic Wallet MUST use the BIP-0032 master seed as the SLIP-0039 master secret S. To clarify, this is the initial generated seed byte sequence of 128-512 bits, which is used as the input to HMAC-SHA512 for deriving the BIP-0032 master node.

This specification is required to ensure that SLIP-0039 backups created in one wallet can be restored in any other wallet that implements SLIP-0039.

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.

[dkbit98]

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.

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.

[Mia Chloe]

~snip

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.

[kTimesG]

So, sort of naturally SLIP39 is therefore quite more verbose. Regarding what SLIP39 tries to achieve, I don't mind it.

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.

Regarding your claim that SLIP39 uses less PBKDF2 computational work, I think you're wrong

The master secret is encrypted using a wide-blocksize pseudorandom permutation
^{...
This scheme is invertible, which means that the creator of the shares can choose the master secret, making it possible to migrate a BIP-32 wallet from BIP-39 mnemonics to the new secret sharing scheme.}

Because there are four iterations of the Feistel thing, I understand it that SLIP39 actually uses 4x2500=10,000 rounds of PBKDF2.

SLIP39 skips PBKDF completely and uses the entropy itself as the BIP32 seed!

From my understanding after briefly looking at SLIP-0039, I think you're wrong on both parts.

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?

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.

Nope!
Hm, is it possible that you deduced your critisism based on this?

SLIP-0039 can be used to back up any master secret S which satisfies the length constraints described above. However, any application implementing SLIP-0039 for backing up a BIP-0032 Hierarchical Deterministic Wallet MUST use the BIP-0032 master seed as the SLIP-0039 master secret S. To clarify, this is the initial generated seed byte sequence of 128-512 bits, which is used as the input to HMAC-SHA512 for deriving the BIP-0032 master node.

This specification is required to ensure that SLIP-0039 backups created in one wallet can be restored in any other wallet that implements SLIP-0039.

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.

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?)

[Cricktor]

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.

...
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?)

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.

- brute-forcing the wallet requires no PBKDF2 (am I wrong on this?)

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.

[Donneski]

I found one interesting python SLIP-39 project that makes it easy for everyone to generate and backup mnemonics in SLIP-39 format that is compatible with Trezor hardware wallets.
It's also possible to convert your existing BIP-39 backup to a much more robust SLIP-39 backup, while keeping all your wallets and addresses.
This would be very useful in case if you have hardware wallets that don't support SLIP-39, like Trezor One for example.
With this app you can break your BIP-39 in multiple parts or groups and recover them when you need it.



This project is open source and you can find more details with instructions on their website and github page:
https://slip39.com/
https://github.com/pjkundert/python-slip39

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?