0
$\begingroup$

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,

Improve this question
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 5, 2020 at 0:06
  • $\begingroup$ @MaartenBodewes I think the OP tries to send a 32 bytes random as AES-256 key. $\endgroup$
    – kelalaka
    Commented Feb 5, 2020 at 17:29
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 5, 2020 at 18:36

1 Answer 1

Reset to default
1
$\begingroup$

One of the issue in sending out the XORed value is to disclose the PSK length

This is only an issue if you consider the length of the PSK to be a secret and not just the value. In that case you probably should redesign your system to not depend on the length of the PSK being secret, e.g. by always sending an upper-length PSK and also sending the amount of bytes used if you need secret variable length.

The only way to crack this should be brute forcing, correct?

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.

Improve this answer
$\endgroup$

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.