@nullius

Interesting!


You are right; the method does break the BIP39 checksum. However the mnemonic itself provides a sort of redundancy in that words can still be identified with misread or misspelled letters; such is the reason mnemonics are used in the first place. And of course you would double triple check S can be recreated from A and B before using the wallet; thus guaranteeing your shares are recorded correctly.


Why would electrums wordlist-independant seed version system make index arithmetic a worse idea? It would work just the same?


I think the real value in the one-time-pad scheme is that it's simple enough to be done with paper and pencil. Towards that end it makes sense to do wordlist arithmetic than bitwise XOR. There are less operations overall and thus less opportunity for error, believe me, I tried! Plus the method could be described to and executed by my Grandmother, an important consideration when she may be the benefactor of my coin and required to perform a recovery procedure in the event of my untimely death.


If you have an air-gapped computer with no malware that you can trust then maybe SSS is superior (favourable scaling) and maybe it's easier to XOR (native machine instruction). But you need a trusted computer and trusted software - difficult and expensive to ensure - even for IT professionals. And further this completely defeats the purpose of a hardware wallet because you have to enter into a computer your private key or seed to be XOR'ed or SSS'ed. A big no-no for cold storage.


It's trivial to guarantee that "you never XOR the same values with anything else"; thus the scheme is provably secure; so what's the problem? What do you mean by "it severely reduces availability"? Why do you think SSS would be safer?


The biggest problem I see with a software based solution (air-gaps, linux, XOR, /dev/urandom, easyseed, SSS, dd, Ian Coleman) is there is no standard for the method. Its right there on Ian Colemans implementation. From https://iancoleman.io/shamir39/: "There are no alternative implementations, meaning you are totally dependent on this tool if you use it. That is a dangerous situation to be in." And how can I ensure Ian's implementation is secure? How can I guarantee it will be available and secure into the future? How can I guarantee the same to my Grandmother? These are difficult questions to address and can require complex maintenance procedures to guard against software and data rot.


Thanks for the discussion. But my recommendation is - KISS - Keep It Simple!

@hatshepsut93:

Your method does seem viable. So long as your key is kept secret from the bad guys seed B will reveal no information about seed A. It reminds me of the "optional passphrase" feature of the BIP-0039 standard as described here: https://github.com/bitcoinbook/bitcoinbook/blob/second_edition/ch05.asciidoc#optional-passphrase-in-bip-39 and here: https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb

OPs method and yours could be combined such that:

(A + B) % 2048 = S; decoy seed with small amount

and

S + "secret key passphrase"; as per BIP-0039 leads to the main wallet

Terrible advice! Do not do this! It will vastly decrease the security of your wallet!

They do not have the same security profile. Your method reveals half the information of your seed, the OP's method does not. In fact it can be shown that seed A and seed B as described by OP are both random numbers and reveal absolutely no information at all.

To see this consider a simpler case where we have a three index dictionary {0, 1, 2} and our seed is only one number.

Let S be our seed chosen randomly, then:

S = 0 with 1/3 probability; S = 1 with 1/3 probability and S = 2 with 1/3 probability.

We chose A the same way:

A = 0 with 1/3 probability; A = 1 with 1/3 probability and A = 2 with 1/3 probability.

Note that since A is chosen randomly it reveals zero information about S.

B is calculated from S and A as per the scheme: B = (S - A) % 3

So consider the three cases for S:

Case: S = 0 then:

B = (S - A) % 3  = (0 - 0) % 3 = 0 with 1/3 probability (A = 0 1/3 of the time)
B = (S - A) % 3  = (0 - 1) % 3 = 2 with 1/3 probability (A = 1 1/3 of the time)
B = (S - A) % 3  = (0 - 2) % 3 = 1 with 1/3 probability (A = 2 1/3 of the time)

Case: S = 1 then:

B = (S - A) % 3  = (1 - 0) % 3 = 1 with 1/3 probability
B = (S - A) % 3  = (1 - 1) % 3 = 0 with 1/3 probability
B = (S - A) % 3  = (1 - 2) % 3 = 2 with 1/3 probability

Case: S = 2 then:

B = (S - A) % 3  = (2 - 0) % 3 = 2 with 1/3 probability
B = (S - A) % 3  = (2 - 1) % 3 = 1 with 1/3 probability
B = (S - A) % 3  = (2 - 2) % 3 = 0 with 1/3 probability


So we see no matter the value for S; B = 0 with 1/3 probability; B = 1 with 1/3 probability and B = 2 with 1/3 probability. Thus with no knowledge of A, B is indistinguishable from a random number and like A reveals zero information about S.


Your method of dividing the secret in two halves does reveal information about the seed. Consider a similar example of a four digit pin:

If I want to brute force crack the pin I have to try all combinations which is 10*10*10*10 = 10^4 = 10,000 tries. However if I discover half, I only need to crack the remaining two digits, thus I need only 10^2 = 100 tries. A factor of 100 speed up from the brute force method!

This method does work with with 2 of 3; You perform the method 3 times and divide the encryption seeds like this:

Alex: A1, A2
Bob: B1, A3
Charlie: B2, B3

IMO this is a better method that SSS. SSS relies to heavily on non standard software, must be done on a secure computer and the resulting shares are difficult to record. SSS is better suited for n of m where m is large as this method does not scale favourably; You need to create a share for each subset of m of size n, which grows exponentially as m increases.

http://users.telenet.be/d.rijmenants/en/secretsplitting.htm
https://bitcoin.stackexchange.com/a/65434/69224