Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

The main problem with OTP\'s is the fact that they can only be used once. Would

ID: 649397 • Letter: T

Question

The main problem with OTP's is the fact that they can only be used once.

Would it be possible to use a random number that's, say, 512 digits, then use 256 of those for the (non-random) message, the 256 remaining ones to send half of the new pad (to be able to send a message back), then re-use those last 256 to send the second half?

As far as I can see, the clear text is obviously obscured (exactly the same as a standard OTP), and the re-used part is also secure because of the fact that the encrypted information is random as well.

The big difference from a two / many time pad is that the re-used part never comes into contact with any predictable data; it's an entirely different part of the message. So, as far as I can see, you could say the OTP encrypts the 256 digits, just as well as the 256 digits encrypt the OTP (both are completely random). Therefore, there should be no difference between the security of this and the regular way of using OTP's. If you were to re-use the part of the pad that encrypted the plain text, you would be vulnerable with regards to a known plain text attack.

Of course, it's not that efficient, because if the random number that encrypted the first message is discovered, all future numbers can be discovered. But other than that it could be pretty fun.

Explanation / Answer

Let me get this straight; if you are sending a 256 bit message, and get a 256 bit reply, the obvious way using OTP would be the message to use up 256 bits of pad, and the reply to use up a separate 256 bits of pad, using a total of 512 bits.

Instead, you propose to use a total of 512 bits to send the message (and a temporary pad), the reply will then be encrypted using the temporary pad); this uses a total of ... 512 bits of pad.

Well, I don't see any reasons why this would be insecure (however, you appear to think you have a way to extend this to multiple messages; exactly how that would work is not obvious), however I also don't see any specific advantage over normal OTP; in both cases, you're using 512 bits of pad to transmit a total of 512 bits of message.