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?

  • $\begingroup$ 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? $\endgroup$
    – user93353
    Commented Aug 1, 2021 at 9:38
  • $\begingroup$ @user93353 the purpose is to send session key from A to B (for subsequent AES-GCM transfers). $\endgroup$ Commented Aug 1, 2021 at 9:43
  • 1
    $\begingroup$ 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. $\endgroup$
    – user93353
    Commented Aug 1, 2021 at 10:25
  • $\begingroup$ 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. $\endgroup$
    – SSA
    Commented Aug 1, 2021 at 12:21
  • $\begingroup$ 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. $\endgroup$
    – Paul Uszak
    Commented Aug 1, 2021 at 13:23

1 Answer 1


If the pre-shared secret is used only once, then it cannot be decrypted (and we don't even need to assume the message is random). So this would be a one-time pad and is information-theoretically secure even against an adversary with infinite computing power.

If, however, we do this again with another random message and the same key, an attacker can trivially XOR the two cipher texts and get the XOR of the two plain texts. This is already serious leakage, but if the two plain texts were chosen randomly, recovering them could be a challenge.

When the plain texts are not random, several techniques attack such a two-time pad, the leading of which is crib dragging.

For random plain texts, the question is: what will you do with them next? Although just sending random data in itself isn't terribly useful, if it's later used again, this may create an attack vector where knowing the XOR of two plain texts could be valuable.

In the comment, you suggest the plaintext will be used as the key for AES GCM, so it opens up a theoretical attack vector where we know two keys are related and probably will also have plaintext-ciphertext pairs for these related keys. I'm unaware of a practical related-key attack on full-length AES, but it definitely weakens the cipher.

An active attacker could go one step further and, after the first such XOR-based key exchange, set the second key to be a key with an arbitrary relation to the first.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.