# Weakness of XORing random bytes with secret key

Side A generates 16 (high quality) random bytes and performs XOR with a 16-byte secret key, then data transfers to side B, where the same secret key is used to recover the original 16 random bytes.

Is there, by chance, a way to guess the secret key by intercepting the XORed data between sides?

• If you already have a 16 byte shared secret key between Side A & Side B, then what is the need for the new 16 byte random bytes? What will it be used for? Aug 1 at 9:38
• @user93353 the purpose is to send session key from A to B (for subsequent AES-GCM transfers). Aug 1 at 9:43
• Your method will work as long as you use the original shared secret for only one session key. For encrypting each session key, you will need a new shared secret. XORing with a shared key is called as OTP (One Time Pad) - it is secure only if you use the shared key for XORing only once. Aug 1 at 10:25
• let's say u have known one bit and another random bit, chances of guessing correct output bit is 50%. so XOR good enough when one of the bitstream is completely random. Now as you're trying to send session key, As there are few methods to do this, one of them is to generate a common secret (key) using DH at server and client , and generate common session key to encrypt the session using any of encryption algorithm.
– SSA
Aug 1 at 12:21
• Err, isn't this upside down? What is the purpose of $E_k(bytes)$ when $bytes$ are truly random? What is the geographical distance between A & B? Because the ideal solution is to pre-share the OTP which has been done for thousands of years. Aug 1 at 13:23