[Feature] Add SeedXOR implementation

[kdmukai]

see: https://seedxor.com/

Concept by nvk/Coldcard. Split a 24-word seed into 2+ 24-word seeds via bitwise XOR. Each resulting seed is completely valid but the "true" wallet can only be recovered with all n seeds.

An interesting security option especially for our unique flow of scanning seed QR codes. After creating the 2+ new seeds as QR codes, scanning all n would take almost no additional time. Since each seed is valid in their own right, decoy funds can be deposited on them. This way if an attacker steals or forces someone to give up their seed, they'll only get the decoy funds without realizing that the main stash is XOR'ed with n+ other seeds.

Certainly not a mainstream use case, but adds a fascinating security wrinkle for the rare edge cases that might want it.

Coldcard implementation here:
https://github.com/Coldcard/firmware/blob/0661b80cbdd079816f138b6f1fd64955d5048d7c/shared/xor_seed.py

[david-bakin]

Not sure why you don't consider it a mainstream use case - it could be one as an alternative to seed words + passphrase - just depends on user's preference on how to handle 2-part secrets to access wallet - and as pointed out, works really well with SS (cross reference to #17, specifically this comment.

[openoms]

Agree with aiming to make the seed XOR usage more mainstream.
See how it is by far the simplest solution in creating a secure redundant 2of3 setup from a single key: https://github.com/openoms/bitcoin-tutorials/blob/master/backups/seedxor.md

[dipunm]

Seed XOR for me is interesting because for inheritance, most of the multi-part security management can be done offline without a computer at all, which has two benefits:

1. It is something that can be turned into a printable step by step guide for an inheritor to follow.
2. It avoids needing to discuss security tradeoffs about air-gapped computers, viruses, etc. until the last word (which is where you want to load the words into a wallet anyway)

Once the seed XOR stuff is done, you have a single key and no multi-sig complications which gives the inheritor the freedom to sweep the funds, and also the opportunity to learn to use Bitcoin from the shallow end of the pool.

Something like: https://www.dipunmistry.co.uk/secure-bitcoin-for-dummies/btc-vault/0.primer/ is what I have been thinking about.

That said, CREATING seedxors can take a while even with a guide like: https://github.com/dipunm/seedxor, it took me 45 minutes to trial run generating 2 backup keys that XOR to give me my private key.

I'd say that is where the most value comes from for a seed signer. Turn dice rolls (or PRNG) into SeedXOR sets in a provably fair way.

[jdlcdl]

I'm currently playing with this in it's own "more_entropy" branch over here

It's a new advanced setting, "more entropy" which enables a new button to press (under add passphrase) before a seed is finalized.
In this "More entropy" menu, I've added 4 reversible operations to be performed on the pending seed's entropy. They are:

• Invert bits (basically xor with 0xFFs)
• Reverse bits (all 128 or 256 bits in reverse order).
• Reverse bytes (all 16 or 32 bytes in reverse order, endian-ness toggle)
• Seed XOR (which currently only works if another seed is already loaded).

In each case, user is brought back immediately to Finalize the seed, and can view the new fingerprint. From there, onto Done, Set passphrase, or More entropy.

For the first 3 ops, you can do any number of them in any order and if you've done them an even number of times, you get to your original key. Same goes for Seed XOR, do it with the same key 2x and you're back to the start... but this is not the case when mixing with the other ops.

I figure it's 3 more bits of un-written entropy for the bit-fiddling ops plus 1 more bit for each printed seed-qr found on your body... more wrinkles for sure.

I'll chime in here again when I think this is close to ready.

(added) It might seem dangerous, but nobody is forced to use it. If you never use any of it (because nobody else supports it), a seedsigner user would still benefit 3 more bits of entropy per seed, w/ each xor, as long as the choices exist. ie: "Load A, reverse bits, finalize. Load B, invert_bits, xor A, reverse_bytes, reverse_bits, xor A, invert bits, finalize."

[jdlcdl]

I've made more progress on seed xor in my forked 'more_entropy' branch linked above.

For now, it's available when "more entropy" is enabled and visible when finalizing a seed via the "More entropy" link.
One of the options is SeedXor (if, and only if another seed of same mnemonic length has already been loaded). Selecting SeedXor shows the list of available seeds; user can go back or can apply xor, landing back in the "more entropy" screen... where they can reverse the process or seed-xor with other seeds, until they decide to finalize.

Still to do:
To tear seed xor out of my arguably cringy "More entropy" branch, into a seed_xor branch of it's own, and make it available in the seed finalization process, along with "Done", and "Set passphrase"; perhaps with it's own settings entry too? At the same time, I'll look to accomplishing it with as few changes to existing base classes as possible, unlike "more entropy" ;)

added: an image to run through reference coldcard test vector.

[dipunm]

This is amazing, thank you for working on this. I want to download this fork and test it but will likely not be able to get to it until next year. 🫡

[jdlcdl]

@dipunm, your feedback will be much appreciated.

I've had a humbling experience coming up to speed with git and github lately, but I'm trying to learn to use branches, and doing my best to reserve from pushing until each are in "non-crashing somewhat-working" order.

I keep an "integration" branch somewhat current when I've made meaningful progress on any of the other branches, treating integration as if it were a dev branch of multiple enhancements. Leaving this on my pi2 by default, I use it to remind me of all I have not finished, with hopes the bugs will nag me into eventual fixes, leading to "Done.". Currently it has "more_entropy", "screensaver_blankscreen", "prudently_paranoid_settings" and "kdmukai/initial_multilanguage". At the very top of each branch's README.md file, I've added notes to explain what each branch is about.

Thanks for chiming in with your encouraging words!

[added]: I admit that was an intentional shameless plug for my integration branch above. Of the first 3 branches integrated, they're me kicking the wheels, expressing ideas, and taking a shot at implementation... but to me and what I use them for, they're close enough to "Done." w/o external interest. The nagging issue that is most pressing in my mind is moving forward with Keith's multilanguage branch... so there, my interest in that matter has been stated!

[jdlcdl]

Since yesterday, I'm starting to reform my opinions on this. Thanks to hard lessons that we have yet to learn via lukedashjr as well as a share from keith in the telegram group that reads like "The tldr is: if you think SeedXOR is a good idea, wait until I tell you about multisig!".

Perhaps XOR or shamir is still interesting for splitting shares and storing them distanced for a single private key w/ a utxo that is held long term. I'm recently leaning hard against it for a bip39 seedqr/phrase that is used to create a bip32 hd wallet.

I had a great deal of fun playing with my more_entropy branch, because it's a way to have a recorded backup that is not the complete solution to spend funds. In a single screen, a couple clicks can alter the entropy of a seed in a way that it can easily be done by computer or by hand and it's reversible, but each mutation is really just a single bit (did the user rev-bits/rev-bytes/invert-bits or did they not). You can then SeedXOR (128-256 more bits) and do it again for 3 more bits, and on and on. BUT, simply adding a passphrase is even more efficient, and already a standard; from one keyboard screen, up up left left click buys us 6-7 bits per character and we only clicked 5 times... that's pretty hard to beat.

On SeedXOR, Keith opined that it might be the invention of the necessity to augment security of backups for seeds that are locked in a non-seedsigner hardware device, this makes perfect sense. But multisig m of n where m is greater than 1 seems much safer... hard to screw-up... and no more difficult (actually much easier) than SeedXOR. With SeedXOR, there are more ways to mess it up than to do it correctly:

• we can safely use different encodings for SeedXOR to do it right, but if we mix them up between seeds while doing it by hand, we'd get the wrong answer every time.
• we can be creative to achieve an ugly m of n with SeedXOR, but it's much easier to screw that up too, in a way that a normal user will fail to find the right seed but the sophisticated attacker would find it trivially.
• giving shares to multiple individuals who "feel safe" that their share is necessary to build the real seed and don't realize that the other individuals could simply backup the final seed or even an intermediate seed, then later remove their own share to learn the shares of the others.

Given the concerns relayed in my prudently_paranoid_setttings branch, I'm not even sure that there is a "right" way to do single-sig, or a "right" way to do 1 of n multisig... with or without a passphrase, and SeedXOR doesn't fix this without motivating a surprise attack with no motivation to keep the rightful owner alive/conscious.

[dipunm]

@jdlcdl it's a shame that you have found yourself disheartened by recent events (possibly other feedback too?)

I however stand undeterred by the SeedXOR idea. Multisig is getting easier to be honest, I agree that with little direction around how to use seed xor, it is easy to make mistakes, however multisig is not exempt from this at all.

SeedXOR does have benefits over passphrases:

• Higher likeliness of a high entropy nth part (of course I could create a seed of 10101010... And that would have low entropy but someone would be intentionally cheating... Low entropy passphrases are definitely more likely)
• Each part is a valid key (can be used to make decoy wallets)

Compared to multisig, on the seed signer the benefits are lower as the device has temporary memory, but IMO, SeedXOR is best used as a backup tool used with a single hardware wallet that stores the combined key in a secure element.

What happened to Luke is unfortunate, but not a reason to abandon single sig completely, nor a reason to stop innovating to improve the ways we handle it.

I am however biased as I have been spending a better part of a year thinking about SeedXOR and how it can be used in good self custody schemes.

Many will not want to use multisig, and options should exist for them. It isn't objectively proven that multisig is best for everyone. SeedXOR can make the trade off of an involved setup, but a simple usage (when used with a hardware wallet), and the benefit of no physical record of the key in its entirety (only copy exists on a security hardened device).

Even with a seed signer, it can still help to create multi-part emergency backups and inheritance setups while the owner holds a single copy of the combined key on their person or somewhere they consider to be safe without having to worry about losing or damaging it (because you have a multi-part recovery plan).

I agree that the options such as "reverse the bits" and so on are potentially risky as it is very easy to put yourself in a position where you have to remember the exact configuration and that is objectively bad -- not that the feature is objectively bad, just the situation itself. Time and time again we tell ourselves that "I'll remember" and forget the details at the best of times.

[jdlcdl]

it's a shame that you have found yourself disheartened by recent events (possibly other feedback too?)

I'm mostly disheartened as a result of the role-playing games that I imagine in my head when trying to put adversarial thought to whatever I'm planning to do. But it's only the lack of feedback that would add to this... never feedback that makes me question a previous lack of consideration. After imagining what might have happened to luke recently, single sig scares the hell out of me, whereas I would have argued in the past that depending on how it's done, it can be done right and it's not my job to tell others what they must not do. If we have just a bunch of private keys that are offline, future mistakes we make while signing on a utxo from some device that we're not aware is compromised won't put our other keys at risk, but with an hdwallet, this wouldn't be the case. I will not remove or fail to maintain what I have already completed of SeedXOR in my more-entropy branch, it remains in my integration branch too (shameless plug once again for blankscreen, multilanguage, paranoid-settings improvements which I'm still a believer of), and if there is interest from others then I most certainly would do the work to tear SeedXOR out into it's own branch... in the spirit of serving popular wants and needs... and I'll just include my current thoughts at that time so the user is aware of whatever my feelings have evolved to.

I am however biased as I have been spending a better part of a year thinking about SeedXOR and how it can be used in good self custody schemes.

I will admit that it was your video from a london meetup which introduced me to this concept, and inspired me... and that XOR has been a binary operation very close to my heart ever since I discovered its magic. I look forward to you sharing more of your thoughts on this.

Thank you for chiming in once again, and Happy New Year to you and yours!

[jdlcdl]

@dipunm I wrote:

if there is interest from others then I most certainly would do the work to tear SeedXOR out into it's own branch.

Today I checked my crystal ball... it's still cloudy, buses still exist and I cross the street frequently; tomorrow is not promised.

I've created a seed_xor branch in my repo here and this is a hat-tip to you, good sir!

You'd have to enable "Seed XOR" in advanced settings, then load at least one seed and finalize it.
Then, you'd need to load another seed of the same mnemonic length in order to have the option to "Seed XOR" just underneath "Add Passphrase" when finalizing.

At this time, you know my current feelings, so I have no intention to make this a pull request. Also, since I do not believe in asking permission, nor do I believe in begging forgiveness, for anything that it one's "right", consider this branch "out in the wild" if you want to pursue it. I'll certainly pay attention while I'm here and I'm always open to be persuaded.

This is a slightly less cringy implementation than more_entropy, but it still includes one new seed_xor() method in the models.seed.Seed class which would require careful peer review; at least it's not 5 new methods in that class plus 4 new helper functions in a new helper module. I thought of packing it all into the "view" but it felt more appropriate to be done in the "model".

Feel free to check it out.
... and while you're there, please take a look at "integration" too (hint hint hint hint hint) where my other hard work is featured... How's your french? Give it a shot please and let me know what you think. I'm chomping at that bit, for my own personal family/friend reasons.

;)

[dipunm]

Awesome. As I said, I would have time in the new year so I will find that time asap!

Hopefully I can get playing this weekend. Also my french is ... Non-existent 😅 sorry. Can't help there.