1
$\begingroup$

This question might be uncannily similiar to this one posted over 6 years ago, but the structure is completely different.

It's written nearly everywhere that OTPs are incapable of sustaining more than their length of data - but I have yet to find an answer besides "reusing them makes cryptanalysis possible" in several different ways.

Suppose Alice and Bob wanted to maintain a OTP-based connection, but are unable to physically exchange entropy besides an initial file. Luckily, Alice has her own entropy source. What Alice and Bob could do is use the initial OTP to send two bits of data at the cost of one bit of entropy. The order of entropy and starting offset could be negotiated beforehand using typical OTP, but let's assume for simplicity's sake that you're sending 2 payload bits in series - and XORing them with an entropy "key" bit, and that the offset Alice picks is also taken from her entropy source.

A meddling Eve, if she knows how this protocol works, could only tell one of two metadata possibilities as a fact:

  1. that any two linked data bits are the same (ambiguous between 00 and 11)
  2. that any two linked data bits are different (01 and 10)

However, Eve should be unable to determine which of the 2 ambiguous combinations is the correct combination... right? After all, Eve could pick up on patterns of the metadata, but not before Alice and Bob notice.

The data transferred this way (which could be even more entropy - Eve doesn't know which part of the data is which!) would be protected by the initial challenge, and by the entropy of the initial OTP. Knowing all this, we can finally rephrase the question:

Is it possible to perform a cryptanalysis on a hybrid OTP described above, and if it is, what would be an efficient attack vector?

Would it be instead preferable to perform an RSA/Diffie-Hellman key exchange over the initial OTP?

$\endgroup$
6
  • $\begingroup$ The 3rd paragraph not clear. It seems, however, like PSK-based protocols? $\endgroup$
    – kelalaka
    Mar 16, 2021 at 20:19
  • $\begingroup$ In hindsight, I should have made it clearer. There is a shared secret which the two parties extend with their own entropy. $\endgroup$
    – BasedUser
    Mar 16, 2021 at 20:56
  • $\begingroup$ So what is the entropy here? $\endgroup$
    – kelalaka
    Mar 16, 2021 at 20:58
  • $\begingroup$ I would rather prefer ECDHE with xChaCha20_poly1305. $\endgroup$
    – kelalaka
    Mar 16, 2021 at 21:07
  • $\begingroup$ What does an "OTP-based connection" mean? What does "OTPs are incapable of sustaining more than their length of data" mean? $\endgroup$
    – Patriot
    Jul 31, 2021 at 2:10

1 Answer 1

1
$\begingroup$

This does not look like OTP, but like PSK with conflicting extra steps.

Alice has her own entropy source.

And by definition, Bob does not have this same entropy source, so what Alice have is a random number generator. And since she cannot tell Bob if the bit is 0 or 1, Bob have no way to decrypt anything. And if she can tell, Eve can know too. And if Eve cannot know the content of the message, why don't use this secure channel to send the message instead of entropy?

A meddling Eve, if she knows how this protocol works

Eve always knows the protocol, the algorithm, all obfuscations, she only needs the key. That's the Kerckhoffs's principle.

The data transferred this way (which could be even more entropy - Eve doesn't know which part of the data is which!) would be protected by the initial challenge, and by the entropy of the initial OTP.

Likewise Bob cannot decrypt anything because he does not have access to Alice's entropy source.

Would it be instead preferable to perform an RSA/Diffie-Hellman key exchange over the initial OTP?

Absolutely! Diffie-Hellman is used by every single bank out there for a reason. OTP can be unbreakable if done right, but is so cumbersome that isn't practical and that's why is rarely used in the real world. IfDiffie-Hellman is good enough to banks protect themselves, is good enough for you, Bob, Alice, and for me.

$\endgroup$

Your Answer

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