<p><em>Disclaimer: I'm not a &quot;security expert&quot;. You should neither trust me nor anyone else claiming they are one. Sticking to established standards and not rolling your own crypto will always be the safer option and I would personally recommend just that (e.g. a standard 2/3 multi-sig).</em></p>
<p>On your first question: I see no reason why the checksum in <code>B</code> would be a security compromise here. The checksum itself depends on the full entropy and knowing it does not reveal information about <code>A</code>. There are some other things to consider though.</p>
<p>Knowing the checksum would make guessing the &quot;other half&quot; easier or at least <em>not as hard</em> if we look at complexity <em>per guess</em>. Normally, the known-plaintext is whether an address contains balance and/or has been used, which requires a full derivation from mnemonic down to standard paths (i.e. lots of operations). If the checksum is known, the known-plaintext is the checksum itself, only requiring a quick check to see if there's a match.</p>
<p>However, if the attacker obtains <code>B</code> the search space is much bigger, requiring in the order of 2<sup>132</sup> guesses since there are only 124 of 256 entropy bits in <code>B</code>. The advantage of less complexity per guess would be completely negligible.</p>
<p>Furthermore, the attacker has no way of knowing which backup they obtained in the first place. There is no way of statistically determining whether the last 8 bit are checksum or not.  This will leave them with an average search space in the order of 2<sup>128</sup>. They're also left with the risk of having obtained Backup <code>X</code>, which would require a different approach thus further complicating things.</p>
<p>Summarizing the scenarios:</p>
<ol>
<li><p>If the attacker, for whatever reason, knows that backup <code>B</code> contains the checksum and which of the three backups they obtained:</p>
<ul>
<li>Attacker obtains <code>A</code>: 124 bit of information missing. This is the weak point of the strategy, but is of no benefit to the attacker as long as they can't be sure about it.</li>
<li>Attacker obtains <code>B</code>: 132 bit of information missing.</li>
<li>Attacker obtains <code>X</code>: 128 bit of information missing.</li>
</ul>
</li>
<li><p>If the attacker does not know which backup contains the checksum (which is most likely the case):</p>
<ul>
<li>On average 128 bit of information missing.</li>
</ul>
</li>
</ol>
<p>Any of these scenarios provide sufficient security (i.e. time to move your funds) should one backup get compromised. I would not recommend going down the rabbit hole of your alternative proposal as, <em>in my personal opinion</em>, its complexity and additional risks (e.g. not being able to carry out on paper) outweigh any advantages gained.</p>
<p>Please let me know if I got something wrong!</p>
<hr />
<p><sub>I don't want to go off topic, but always like to remind people that their relatives/heirs may need to recover without any knowledge in the future. You should document and/or communicate your backup strategy in some way or another. This is less of an issue with standard methods as <em>others</em> can help more easily.</sub></p>

CC BY-SA 4.0
2023-01-13T04:48:23.690Z
You've convinced me to go with something standard. 2/3 multisig isn't quite what I want since I don't want to have to sign each transaction multiple times, but [SSKR](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-users.md) seems like a serious attempt at a standard for 2-of-3 using Shamir Secret Sharing (that apparently makes some important improvements to SLIP-0039).
satsflat
CC BY-SA 4.0
2023-01-13T09:47:26.790Z
But how do you create the shares safely? If you can't do it "on paper", that's a compromise IMO. I don't know how you manage your keys, but if you use a hardware wallet, you would reduce the security of your keys to the security of the device you created the shares with.
sutterseba
CC BY-SA 4.0
2023-01-14T04:20:14.617Z
I agree it is a compromise. I would imagine running `seedtools-cli` on a live boot of Tails with no network connection. H/T [this page](https://blog.lopp.net/how-to-back-up-a-seed-phrase/)
satsflat
CC BY-SA 4.0
2023-01-02T13:40:46.497Z
2023-01-02T13:40:46.497Z
sutterseba
<p>One way to create a distribution, 2-of-3 backup of your seed phrase ABC is to store the following in three separate places:</p>
<ul>
<li>AB</li>
<li>BC</li>
<li>CA</li>
</ul>
<p>Any two of these lists is sufficient to reconstructed the entire seed phrase. <a href="https://github.com/julianbuettner/seed-phrase-raid-5" rel="nofollow noreferrer">Seed Phrase Raid-5</a> is a nice improvement on this technique. In the example given above, an attacker who uncovers one of the three records (say, AB) already has 2/3 of the full seed phrase. The innovation of Raid 5 is to divide your seed phrase into only two pieces and compute <code>X = A ^ B</code> (XOR). Then if you lose either A or B (but not both) and still have X, you can get the lost piece back with a simple XOR.</p>
<p>The easy way to generate A and B for this purpose is simply to chop your 24 word seed phrase in half, and this makes recovery the original full seed phrase a trivial concatenation if you have both A and B. However:</p>
<ol>
<li>Neither A, B, nor X will in general have a valid checksum (if you care)</li>
<li>A and is completely random, while the entire checksum for the 24 word phrase gets put into B (since the checksum is in the last word of the original seed phrase)</li>
</ol>
<p><strong>My question is, does #2 matter?</strong> It's only 8 non-random bits in B, yet cryptology seems full of examples where little cracks like this end up having big implications.</p>
<p>It might be tempting to say that we are simply stuck no matter what the answer, but there is an alternative: to compute the 256 bit entropy from the original seed phrase and divide it into two 128 bits pieces, e1 and e2. Then we let:</p>
<ul>
<li><code>A = mnemonic(e1)</code></li>
<li><code>B = mnemonic(e2)</code></li>
<li><code>X = mnemonic(e1 ^ e2)</code></li>
</ul>
<p>Now A and B both contain 128 random bits, B contains no checksum information about A, and as a bonus A, B, and X are all valid 12 word seed phrases. However, the mnemonics A and B can no longer be used to reconstruct the original seed phrase via simple concatenation. You have to convert them to entropy and concatenate the entropy instead.</p>
<p>For example, <a href="https://github.com/julianbuettner/seed-phrase-raid-5" rel="nofollow noreferrer">https://github.com/julianbuettner/seed-phrase-raid-5</a> considers the seed phrase <code>patient wall rural drink sleep school scatter twin sibling jeans panda frog believe bright major bonus autumn initial regular soul weird baby ecology average</code>. If we simply XOR on by word basis, we get X = <code>remember turkey desk foil setup rebel input cave direct grit sunny fancy</code>. However, if we can the more complicated approach of cutting the entropy in half we get</p>
<ul>
<li><code>A = patient wall rural drink sleep school scatter twin sibling jeans panda fruit</code> (note this differs from the original starting in the final word, where the checksum information lies)</li>
<li><code>B = mule fade anchor cover rail strong win hollow test much love abstract</code>. Note this looks nothing like the second half of our original seed phrase</li>
<li><code>X = core polar remove income knock blood depth maple blouse trade brand friend</code></li>
</ul>
<p>The second approach is more complicated and cannot be carried out on paper. <strong>Does it offer a meaingful security advantage over the first?</strong></p>

<security><mnemonic-seed><backup><seed>
Is spitting a BIP39 seed phrase in half meaningly less secure than splitting the entropy in half?
satsflat
# Is spitting a BIP39 seed phrase in half meaningly less secure than splitting the entropy in half?

(Asked by: username_0 on 2022-12-30)

One way to create a distribution, 2-of-3 backup of your seed phrase ABC is to store the following in three separate places:

* AB
* BC
* CA

Any two of these lists is sufficient to reconstructed the entire seed phrase. [Seed Phrase Raid-5](https://github.com/julianbuettner/seed-phrase-raid-5) is a nice improvement on this technique. In the example given above, an attacker who uncovers one of the three records (say, AB) already has 2/3 of the full seed phrase. The innovation of Raid 5 is to divide your seed phrase into only two pieces and compute `X = A ^ B` (XOR). Then if you lose either A or B (but not both) and still have X, you can get the lost piece back with a simple XOR.

The easy way to generate A and B for this purpose is simply to chop your 24 word seed phrase in half, and this makes recovery the original full seed phrase a trivial concatenation if you have both A and B. However:

1. Neither A, B, nor X will in general have a valid checksum (if you care)
2. A and is completely random, while the entire checksum for the 24 word phrase gets put into B (since the checksum is in the last word of the original seed phrase)

**My question is, does #2 matter?** It's only 8 non-random bits in B, yet cryptology seems full of examples where little cracks like this end up having big implications.

It might be tempting to say that we are simply stuck no matter what the answer, but there is an alternative: to compute the 256 bit entropy from the original seed phrase and divide it into two 128 bits pieces, e1 and e2. Then we let:

* `A = mnemonic(e1)`
* `B = mnemonic(e2)`
* `X = mnemonic(e1 ^ e2)`

Now A and B both contain 128 random bits, B contains no checksum information about A, and as a bonus A, B, and X are all valid 12 word seed phrases. However, the mnemonics A and B can no longer be used to reconstruct the original seed phrase via simple concatenation. You have to convert them to entropy and concatenate the entropy instead.

For example, <https://github.com/julianbuettner/seed-phrase-raid-5> considers the seed phrase `patient wall rural drink sleep school scatter twin sibling jeans panda frog believe bright major bonus autumn initial regular soul weird baby ecology average`. If we simply XOR on by word basis, we get X = `remember turkey desk foil setup rebel input cave direct grit sunny fancy`. However, if we can the more complicated approach of cutting the entropy in half we get

* `A = patient wall rural drink sleep school scatter twin sibling jeans panda fruit` (note this differs from the original starting in the final word, where the checksum information lies)
* `B = mule fade anchor cover rail strong win hollow test much love abstract`. Note this looks nothing like the second half of our original seed phrase
* `X = core polar remove income knock blood depth maple blouse trade brand friend`

The second approach is more complicated and cannot be carried out on paper. **Does it offer a meaingful security advantage over the first?**

**Tags:** security, mnemonic-seed, backup, seed


---

## 1 answers

### Answer by username_1 on 2023-01-02. Score: 1

*Disclaimer: I'm not a "security expert". You should neither trust me nor anyone else claiming they are one. Sticking to established standards and not rolling your own crypto will always be the safer option and I would personally recommend just that (e.g. a standard 2/3 multi-sig).*

On your first question: I see no reason why the checksum in `B` would be a security compromise here. The checksum itself depends on the full entropy and knowing it does not reveal information about `A`. There are some other things to consider though.

Knowing the checksum would make guessing the "other half" easier or at least *not as hard* if we look at complexity *per guess*. Normally, the known-plaintext is whether an address contains balance and/or has been used, which requires a full derivation from mnemonic down to standard paths (i.e. lots of operations). If the checksum is known, the known-plaintext is the checksum itself, only requiring a quick check to see if there's a match.

However, if the attacker obtains `B` the search space is much bigger, requiring in the order of 2132 guesses since there are only 124 of 256 entropy bits in `B`. The advantage of less complexity per guess would be completely negligible.

Furthermore, the attacker has no way of knowing which backup they obtained in the first place. There is no way of statistically determining whether the last 8 bit are checksum or not. This will leave them with an average search space in the order of 2128. They're also left with the risk of having obtained Backup `X`, which would require a different approach thus further complicating things.

Summarizing the scenarios:

1. If the attacker, for whatever reason, knows that backup `B` contains the checksum and which of the three backups they obtained:

   * Attacker obtains `A`: 124 bit of information missing. This is the weak point of the strategy, but is of no benefit to the attacker as long as they can't be sure about it.
   * Attacker obtains `B`: 132 bit of information missing.
   * Attacker obtains `X`: 128 bit of information missing.
2. If the attacker does not know which backup contains the checksum (which is most likely the case):

   * On average 128 bit of information missing.

Any of these scenarios provide sufficient security (i.e. time to move your funds) should one backup get compromised. I would not recommend going down the rabbit hole of your alternative proposal as, *in my personal opinion*, its complexity and additional risks (e.g. not being able to carry out on paper) outweigh any advantages gained.

Please let me know if I got something wrong!

---

I don't want to go off topic, but always like to remind people that their relatives/heirs may need to recover without any knowledge in the future. You should document and/or communicate your backup strategy in some way or another. This is less of an issue with standard methods as *others* can help more easily.

> **Comments:**
> **username_0**: You've convinced me to go with something standard. 2/3 multisig isn't quite what I want since I don't want to have to sign each transaction multiple times, but [SSKR](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-users.md) seems like a serious attempt at a standard for 2-of-3 using Shamir Secret Sharing (that apparently makes some important improvements to SLIP-0039).  
> **username_1**: But how do you create the shares safely? If you can't do it "on paper", that's a compromise IMO. I don't know how you manage your keys, but if you use a hardware wallet, you would reduce the security of your keys to the security of the device you created the shares with.  
> **username_0**: I agree it is a compromise. I would imagine running `seedtools-cli` on a live boot of Tails with no network connection. H/T [this page](https://blog.lopp.net/how-to-back-up-a-seed-phrase/)  

---

