# Re-using parts of a one time pad to encrypt a new one?

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.

-

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.

-
I should have worded it better I think. Using regular one time pads, you, as well as the person you're sending the message to, need a lot of them to keep sending messages (entire books). Using this method, you can send a message, and attach a new pad to it. This means that you can keep sending messages, without the requirement of having tons of random numbers stored. You basically use half of the message for plain text and half (or even less, it shouldn't matter) to transmit the new pad, thereby avoiding insecure forms of communication. –  Pluto Oct 3 '13 at 14:29
@Pluto: if you ever attempt to transmit $N$ bits of total data using $<N$ bits of shared pad total, you're effectively using a two-time pad; stirring in extra 'temporary pad' (which is not already shared between the two parties) does not change this. See J.D.'s response for his working out one specific case. –  poncho Oct 3 '13 at 14:37

The scheme you describe is perfectly secure, so long as you are only sending a message as long as the pre-shared key. So basically it's an inefficient way to do a One Time Pad. Let's see what happens when you try to send 768 bits of message when you only have 512 bits of pre-shared key:

Let $A$ and $B$ be the two blocks of pre-shared key material (each block is 256 bits). Let $M_0$, $M_1$, and $M_2$ be the three blocks of message you want to send (totalling 768 bits). Let $C, D$, and $E$ be random blocks.

First Message consists of three blocks:

1. $C_0 = M_0 \oplus A$,
2. $C_1 = B \oplus C$
3. $C_2 = B \oplus D$

Second Message consists of two blocks:

1. $C_3 = M_1 \oplus C$,
2. $C_4 = D \oplus E$

Third message consists of one block:

1. $C_5 = M_2 \oplus E$

Now with simple algebra...

$C_1 \oplus C_2 \oplus C_3 \oplus C_4 \oplus C_5 = M_1 \oplus M_2$,

...you are back to the problem with a two-time pad (using it uncovers a simple function of the unencrypted message).

You could of course just send $M_0$ and $M_1$, and this would be secure -- but in that case there is no reason to muck about with extra random blocks, as you can just use $A$ and $B$ straight-forwardly.

-
I get the problem with it, but that's not what I meant to change, in reality, if the preshared key would be too short, you would first transmit the first 256 bits of the message, get a new 512 bit random number, and transmit the remainder. It's basically a way to use the pad as a tunnel through which to share new pads, without having to have either a lot of pads or requiring to use other channels to share new ones. The reusing just allows for a n-bit pad to transmit an n-bit new pad AND a 1/2n-bit message (or more than 1/2, you just need to re-use the pad multiple times to encrypt the new one) –  Pluto Oct 3 '13 at 14:42
@Pluto -- if you are transmitting a 512 bit message, and have 512 bits of pre-shared key, you can of course securely send that message. You may also generate additional 512 random bits and send those along as well, in whatever complicated fashion you like. But those additional random bits are useless -- you can't (for example) use those new 512 random bits as key material for future messages, as I showed in my worked example above. They do nothing but waste time and space. –  J.D. Oct 3 '13 at 15:07