XOR cipher implements double lock protocol

Project 6, 2015	Research Experience for Teachers	Project 4, 2016

	Some Odd Ciphers

Background:

One of the weaknesses of the previous XOR approach is that a key must be shared by sender and receiver. To be shared, the key most probably must be generated at a location that is far from at least one of the parties. To do this, some secure channel is necessary. But secure channels are difficult to build. Hence, we look for encryption protocols where no key needs to be sent to some party. The double lock protocol below is a possible such protocol.

The double lock protocol works as follows: two parties, A and B, each have a key. Party A sends an encrypted message to B by XOR encrypting with its key. Party B XOR encrypts the encrypted message with its key and sends the double encrypted message to A. Party A XOR decrypts with its key and sends the result to B. Party B then XOR decrypts with its key to see the original message. An eavesdropper should not be able to decrypt easily and should not be able to get key information because it is never transmitted.

Not only does this protocol eliminate the problem of transmitting keys, it also eliminates the problem of the same plaintext message encrypting to the same ciphertext: since there is no need to transmit keys, new keys can be generated for each transaction. In the applet above repeatedly hit return on the plaintext Textfield - new keys get generated and the ciphertext is changed accordingly.

Instructions:

Enter a plaintext sentence in the textfield labeled "Message:" then hit return. A random key is generated for A and shown in the textfield labeled "Key A:". A random key is generated for B and shown in the textfield labeled "Key B:". The protocol above is followed and the results are shown at each step in various textfields down to the decrypted result at the bottom.

Question:

But, what is the terrible flaw that this protocol has?