BIP39-XOR 6.0.0 released

[Greg Tonoski]

I'm announcing the release of BIP39-XOR 6.0.0: "https://github.com/GregTonoski/BIP39-XOR/" and look forward to feedback.

[DaveF]

This, looks like an answer in search of a question.
Not saying your work is bad, but what issue does this really solve and if people start using it how long until someone comes back with the "I have this seed and I can't get it to work" questions.

I could be missing something, and if I am let me know.

-Dave

[Greg Tonoski]

Thanks for feedback.

The main issue that it solves is the storage of secret in an encrypted form. It is not secure to keep (copy of) secret BIP-39 in plaintext (written on a paper as an example). Instead, it could be encrypted with the BIP39-XOR.

There are also other use cases. I will elaborate on them in the future. They are discussed in https://bitcointalk.org/index.php?topic=5433064.0.

I agree that "I have this seed and I can't get it to work" questions may arise. They are already quite common even if BIP39-XOR isn't used. They are not caused by the tool itself so I think they are not an argument against the tool (and encryption).

[Charles-Tim]

What I think about this is that passphrase is very similar to encryption. Although, it is not encryption but word extension in a way your seed phrase can still be seen and not encrypted. Encryption will make the seed phrase not seen. But they are similar because if same characters are used to setup the passphrase or encryption, the same computational power is required to brute force both the passphrase or encryption. So if you use a strong passphrase, there should be no problem.

[Pmalek]

In these situations, it is also important to think about the heirs and those who will inherit your bitcoin. Especially, if they aren't that interested in the technology and only look at the financial value of the asset. I have never been a fan of overcomplicating things. Find good hiding places for your seeds and passphrases. That's good enough. Explaining to your family how to import a seed in plaintext is easier on their part than if they also have to remember how to decrypt it first. Plus, if you have to write down the decryption process, it kind of defeats the purpose of it. If someone finds your seed, they can also find the how-to-decrypt-the-seed guide.   

[Greg Tonoski]

What I think about this is that passphrase is very similar to encryption. Although, it is not encryption but word extension in a way your seed phrase can still be seen and not encrypted. (...)

It is important to consider the distinction that a "passphrase"/"13 word" is "hardcoded" (not designed to be modified) whereas XOR keys may be discarded or replaced with new ones.

[satscraper]

The main issue that it solves is the storage of secret in an encrypted form.

I support the idea to keep SEED in encrypted form but ^{(as I use digital media for this purpose)} I have chosen OpenPGP technique  to encrypt/decrypt my SEED ^{(see here)} and use for this the set of cloned  pgp hardware keys  which absolve me from the commitment to keep in memory decryption phrase. However I have encountered those users who use XOR for SEED encryption . Hope they will find useful  your BIP39-XOR implementation.

[DaveF]

What I think about this is that passphrase is very similar to encryption. Although, it is not encryption but word extension in a way your seed phrase can still be seen and not encrypted. (...)

It is important to consider the distinction that a "passphrase"/"13 word" is "hardcoded" (not designed to be modified) whereas XOR keys may be discarded or replaced with new ones.

If I have a good valid seed it will work. It's when people do things to it to make it more secure or less obvious what it is, is when we run into the 'I can't get it to work'
Since the XOR keys can be discarded / changed it's just IMO another thing to go wrong.

Not saying it's a bad idea, just have to find a way to make it less vulnerable to humans being idiots. Which as we know is the hard part of doing anything.

-Dave

[dkbit98]

The main issue that it solves is the storage of secret in an encrypted form. It is not secure to keep (copy of) secret BIP-39 in plaintext (written on a paper as an example). Instead, it could be encrypted with the BIP39-XOR.

It's not a bad idea but it adds additional complexity to everything, and that is not good for everbody.
Another interesting way of encrypting seed words is with Satochip Seedkeeper cards, but negative side is that it's not free like BIP39-XOR.
I wonder how your solutions could be integrated with hardware wallets, if you can say something about that.

[Greg Tonoski]

There isn't anything blocking anybody to implement XOR encryption and embed (integrate) it in a hardware wallet. As a matter of fact, it has been widely used in military grade applications for more than a century. There is (imperfect) attempt by the Bitcoin harwdare wallet Coldcard producer (SeedXOR) and unfinished one in SeedSigner firmware. I don't know about other instances.

XOR as a solution (technique) is more than 100 years old. It's not something invented by me.

[Forsyth Jones]

Indeed, keeping a mnemonic written down offline has been challenging if you are concerned about physical access to the mnemonic. There are several solutions that mitigate this problem, such as Seed XOR. Although I have not used it yet, I find the tool quite useful and, if used correctly. The most interesting thing is that the seed XOR presents good plausible deniability.

I have already discussed similar methods with good plausible deniability, such as deriving a hidden mnemonic through BIP85 and Seed-OTP. Although Seed-OTP encrypts the original seed with completely different words, it doesn't create a valid seed, presenting a lack of plausible deniability. I then proposed to modify the last word generated by seed-otp with the last word that presents a checksum for the encrypted seed.

Unfortunately, I can't say which of these options are the most cryptographically secure, although in digital security, the most recommended is to use what has already been audited and tested extensively by the community. The more public and accessible the encryption/backup method is, the greater the chance that it will be more easily used and accessible. It will all depend on the level of paranoia and the risk acceptance of each method.

The interesting thing is that all 3 methods have plausible deniability (if you also take into account my seed-otp approach by modifying the last word), if someone accesses the encrypted/decoy mnemonic, they will not be able to access the original wallet, even if it doesn't have a BIP39 passphrase.

And if the real wallet is protected by a BIP39 passphrase, even if someone gets both its encrypted/decoy mnemonic + passphrase, they will not be able to access the real wallet that contains the funds!