# How safe is XOR with multiple independent but non random keys?

I will approach the question from practical side. All the examples are not real, but for illustration purpose only.

I have a message, the secret Bitcoin key, which I want to store safely.

MESSAGE = KwjwmREseNZmZ8yeNKrurN6qPuh9FhrLAefYa2nTLafLkGmWW9ta

To do this I come up with 4 keys which look independent, somewhat private, and can be recovered.

Key 1 is a set of last words from page 100 and up in my favorite book to match the message length:

KEY1 = help knows the at sortes state the citizens color science costs unfairness

Key 2 is the Merkle Root from Bitcoin blockchain block number 121047, which could be my 2 kids' birthdays 121 and 047 (for the day number within year easily available at blockchain.info)

KEY2= 1b28458e4191e60f4553357cb7b54a9cc15ea0a27e8f5df27dab6d3aab3d3be4

Key 3 is the name of the file of my main wedding photograph, stored in my albums, mail, and shared with friends.

KEY3= IMG_20170511_144510.jpg

Key4 is another Bitcoin address generated solely for the purpose of being a key, two copies will be stored in home safe and safety deposit box in the bank

KEY4= L1jkNAKpG1hu7omtYW6fFFDGw1AaYrdkiUr4NpBANziKVHdZgx8v

The keys are not re-used anywhere. KEY3 is replicated to match the length of the message. The message and all keys are XORed (byte by byte) to get the secure code.

The question is: How safe is the resulting code? Can I store it online? Can security hold if 1 or 2 keys (but no more) are compromised?

I understand that there might be no correct answer, but would appreciate any thoughts if I miss some vulnerabilities. Should I have more keys? What kind of keys would help? Can I mix in more plain text keys?

If you ask why not to use a password with good encryption, it is trickier for me to verify the program doing the encryption, while doing XOR is trivial in HTML with few lines of JavaScript on any old offline smart phone (to be destroyed afterwards), and will be trivial in the future.

Thanks.

PS. I can try to figure out how to post the HTML doing the job if anyone is interested.

• Seems to me that verifying a program would be a lot easier to verify a new cryptographic protocol, especially that protocol amounts to the one above. Jun 25 '17 at 19:54
• I'm having trouble following your scheme and for those unfamiliar with Bitcoins, is BITCOIN = MESSAGE ⊕ KEY1 ⊕ KEY2 ⊕ KEY3 ⊕ KEY4 correct? Jun 25 '17 at 21:21
• The MESSAGE = "Bitcoin Private Key" which is essentially an account itself. It allows to generate many public keys (addresses) to receive Bitcoins, and sign transactions to spend funds from those addresses later. If compromised, removing funds from ALL related addresses is trivial Jun 25 '17 at 22:18
• Still confused. How can BITCOIN = KEY1 ⊕ KEY2 ⊕ KEY3 ⊕ KEY4 if at least one of the keys is not calculated by xor rather than picked? It's not mathematically possible. Is key 4 not a real Bitcoin address and you calculated it? Jun 26 '17 at 2:31
• @PaulUszak the bitcoin key is given (it is the message). He/she wants to set c = KEY1 ⊕ KEY2 ⊕ KEY3 ⊕ KEY4 ⊕ MESSAGE and then store c. Jun 26 '17 at 8:50

How safe is the resulting code? Can I store it online?

Very unsafe. No matter how you come up with these keys (passphrases, really), it will have extreme biases. These biases are going to be enough to make some pretty good guesses about your plaintext. This is what makes RC4 insecure in the WEP protocol, and RC4's biases are comparatively minor.

This also has the problem that passwords in general have, which is that you as a human can't accurately remember complex passwords. You'll have to either write them all down (in which case they can be discovered) or use some scheme which actually lowers their strength (your keys 1 through 3).

Can security hold if 1 or 2 keys (but no more) are compromised?

For every key that is discovered, the biases of the other keys become more apparent. If 2 keys are discovered (particularly keys 2 and 4) it becomes pretty much a puzzle you find in a newspaper to solve.

My advice is to stick to known algorithms. If you need to encrypt something with a password, use something like bcrypt to expand your password into a high-entropy key, then use that key to encrypt with something like AES in a good mode like CTR.

Your scheme is extremely secure because the keys are fairly random. But you have to realise what your five true keys are:-

Key1: last words from page 100 in your favourite book
Key2: my 2 kids' birthdays
Key3: main wedding photograph
Key4: "L1jkNAKpG1hu7omtYW6fFFDGw1AaYrdkiUr4NpBANziKVHdZgx8v"
Key5: there are 4 keys that need to be xored together


This is partially a book cipher, and partially just pointers and aid memoirs to key material. There is a slight decrease in security from perfect because the keys are not entirely random. Pattern of life analysis might help to narrow down the search field to your favourite things. And clearly key 4 has to be written down. But you could be cunning and have it tattooed on your cat's back under the fur. The actual character sequences are fairly irrelevant and just form part of the working.

There is a similar idea posed here that uses the digits of pi as a stream cipher /OTPish thingie. There similarly the true key is the offset from zero.

A major source of security comes from the fact that no one will know how many keys there really are. And best of all, you don't have to write down keys 1 - 3 or 5. I don't believe that it's possible to quantify the security level here in bits. Just assume it's unbreakable.

• Thanks for the comment. One particular convenience of XOR is that order of keys is not important. All keys and the message can be XOR in any combination with the same result (provided keys a brought to message lengths) . So let the attacker worry about fifth Master key Jun 27 '17 at 12:44
• Paul, I would appreciate if you take a look at crypto.stackexchange.com/questions/48692/…, thanks Jun 28 '17 at 14:18
• @Evgeny Only if you send cookies or up vote... Jun 28 '17 at 14:49