@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!