# Protecting data through an XOR operation with sufficiently long keys

Suppose two parties S and D would like to protect a communication channel. Therefore, S and D exchange two sufficiently long key sequences SB und DB of random bits over a secure channel [e.g not over the internet]. After this exchange, both know each other's keys.

For example, S and D might (physically) exchange 64 GByte USB-Sticks which contain the other's key sequence.

If S wants to send a message M to D, S actually send M `xor` SB*.

• If SB and DB contain enough entropy [thus are based on a good random source],
• and SB and DB are sufficiently long
• would this technique protect the message M against third parties?

How would a third party compute the keys SB and DB?

Doesn't this sound much line a one-time pad?

While I used `XOR`, I actually mean a simple mathematical (e.g. bitwise op + addition) operation. In general, I thought about the question, if strong cryptography with simple mathematics is possible.

• Smells like homework. – Lucas Kauffman Sep 8 '13 at 13:12
• @LucasKauffman I don't argue that this is a good idea. Just want to learn why it is not. – SteAp Sep 8 '13 at 13:16
• That's exactly what a one-time pad is. – user10211 Sep 8 '13 at 13:17

What you are describing is one-time pad.

Assuming that you each bit of the key is used only once, the one-time pad is considered a perfect cipher. Of course, if you reuse any part of the key, the whole scheme becomes laughably weak.

The biggest weakness of the scheme is the difficulty of the key exchange method. The keys used in the one-time pad must be of the same or longer length as the message. If you have a secure method of transferring an arbitrary amount of information for use as key material, why not just use the same transfer method to transfer the actual message?

Also, the key material must be truly random.

• Thy for pointing out the case of multi-usage one-time pad. Because, e.g. people meet once a year at a conference at a company headquarter and the back to their respective subsidiaries. – SteAp Sep 8 '13 at 13:26

You also need authentication and integrity checking with a strong MAC which is sent with the ciphertext to prevent against bit-flipping attacks. Encrypt the MAC as well with some of the random data as well (using the same encryption process).

You'll need a way to keep in sync with the other user so you don't accidentally re-use random data. Think about how will you handle packet loss, loss of a message, or an attacker interfering. Check out the SSH protocol for some design clues. Once you've used part of the random data, it must be immediately deleted to prevent re-use. You should designate separate parts of the data for each party to send, that way both users don't accidentally send using the same random data.

Make sure your entropy is properly random. You definitely shouldn't blindly trust whatever the OS provides especially with Intel's new on-chip solution developed in collusion with the NSA and the NSA inserting backdoors into everything. Include some random user input too. You'll need a physical source of randomness probably, maybe a hardware solution and collect from multiple entropy sources. Be sure to run all entropy through a randomness extractor before you use it as well. For example, you would need to generate 128GB of entropy, then run it through Von Neumann Whitening process which will give you 64GB of usable entropy. Don't use a CSPRNG if you can help it, subtle patterns could reveal the seed used to generate the entire random data.

For 64GB that will take a while to create. If you really wanted to use a CSPRNG, potentially you could generate 3 long keys (1024 bits+). Run each through a separate CSPRNG algorithm to generate 3 separate outputs of 128GB. Then run the separate outputs through the entropy extractor giving you 64GB for each output, then finally XOR the outputs together (output1 XOR output2 XOR output3). The final output should be good for 64GB of secure random data and unpredictable for any attacker.

The beauty of the one-time pad is that the ciphertext can be decrypted to any plaintext of the same length. An attacker can try all the keys they want, it will just reveal all possible plaintexts. If you maintain proper key management (deleting keys after use) and other security around the implementation then you have plausible deniability. If an attacker forces you to reveal your key (with a rubber hose or wrench) then you no longer have the key to help them. And anything you sent could plausibly be changed to anything you want to say instead. There's a reason military and governments still use it. Once quantum cryptography key exchange becomes more widely available the one-time pad will be even more used. Until then, deal with the minor practical hassles and enjoy freedom and perfect secrecy.

There is another way to visualise a one-time-pad that can help expand your view of what symmetric data security is.

Consider a message P(plaintext) of length N(bytes):

• You can split this message (cryptographic mitosis actually) into two random secrets (A and B) of length N, using a random data source R(bytes) of length N. After the split, P and R can be discarded. Secrets A and B become the key/ciphertext of each other.
• The plaintext is simply regenerated by combining the two secrets A and B.
• Secret A or B can itself be split into more secrets of length N by using additional completely new random data (R2).
• Each secret piece A, B, C, D, E, F, ... etc. is:

• Equally necessary to produce the plaintext.
• Able to be combined in any order to arrive at the plaintext
• Is just as secure; regardless of knowing 1 of 10 secrets or 9 of 10 secrets.
• This means you can secure a secret by splitting it across multiple CDs or USB sticks; either hidden in different places or given to different people. A good random data source is only needed for the initial mitosis.

This is simply a different way to conceptualise the same one-time-pad encyption model; but a handy one as it highlights ciphertext and keys as utterly interchangible concepts for one-time-pads providing the attacker doesn't have every secret.

The usual constraints for one-time-pads apply.