# XOR PSK with random buffer

I need some guidance here:

assuming I have the following:

(PreSharedKey of 32 bytes) XOR (one time Random Buffer of 32 bytes)

The only way to crack this should be brute forcing, correct? One of the issue in sending out the XORed value is to disclose the PSK length. At this point I could add some random bytes at the end of the XORed value to avoid this (the two ends knows the real PSK len). But does it make sense? Or it would be better to just increase the PSK (and the random buffer) length of the same number of bytes to get more security?

Sorry for the newbie question...

Thanks,

• Newbe questions are alright, but I'm not sure we can answer it as it stands. If you XOR something with a fully random value then nothing can be brute forced. Leaking the size of a key is generally not an issue. 32 bytes / 256 bits of key material should be plenty to secure anything, so extending it doesn't make sense. So all in all, I haven't got an inkling of what you are trying to ask or even protect. – Maarten Bodewes Feb 5 '20 at 0:06
• @MaartenBodewes I think the OP tries to send a 32 bytes random as AES-256 key. – kelalaka Feb 5 '20 at 17:29
• Well, you can only do that one time, as any key leaking will also expose all the other keys, so you might as well use just one key. And in that case, it might just as well be the pre-shared key itself. So I still don't get it. Of course, brute forcing something that is really an OTP makes no sense. – Maarten Bodewes Feb 5 '20 at 18:36

Assuming an adversary only gets to see $$K\oplus B$$ with $$K$$ being your PSK and $$B$$ being the one-time buffer, this is a one-time pad and an adversary cannot infer anything about the PSK they didn't already know. In particular an adversary cannot infer the concrete value. However this guarantee is void if the same buffer $$B$$ is used more than once - even with the same key as then the adversary knows the key has been re-used which you may or may not want to leak. And of course note that receiver of this value also has to know $$B$$ which at this point becomes a one-time-use PSK itself which begs the question why one doesn't use $$B$$ as the key directly potentially with a more standard symmetric key-exchange protocol to get a fresh session key - which can be as simple as encrypting a monotonic counter and a new key under the PSK.