# Extend OTP on random data?

If Alice and Bob both start with a shared OTP $P_0$, which is 256-bytes long, and Alice wants to send a 512-byte message, would it be secure to send the first 256 bytes with standard OTP ((a+b)%256 or the like), then generate another 256 bytes of true randomness ($P_1$), run that through the OTP and send the encrypted form of that. Repeat for the second block of 256 bytes and $P_1$, etc. Bob then decrypts the first 256 bytes with $P_0$ and gets $P_1$ from the second 256 bytes. Rinse and repeat, etc.

Is this secure from a passive Eve? If not, why not?

• No. $\:$ Bob can decrypt much more than 256 bits of plaintext with just 256 bits of key material, $\hspace{.86 in}$ so it can't be information-theoretically secure, and it's too simple for computational security. $\hspace{.95 in}$
– user991
Aug 2 '15 at 6:50
• I think we've answered this before somewhere. Aug 2 '15 at 12:05
• @MaartenBodewes: This seems related, at least. Aug 2 '15 at 12:25
• @IlmariKaronen Yeah, I remember that one, but it's not a real dupe. So I've answered. Aug 2 '15 at 20:15

No, that doesn't work. OTP is secure because knowledge of the plaintext doesn't give you any useful information about the key. This is because the bits of the key (e.g. $P_0$) are never used to encrypt anything else.

If you would somehow reuse the key then leakage of the plaintext would cause leakage of $P_0$. Leakage of $P_0$ directly leaks $P_1$. I.e. instead of perfect security the information encrypted by $P_1$ is now directly dependent on the security of the plaintext and $P_0$.

OTP is only perfectly secure as long as the bits in the key stream are independent of each other. OTP doesn't allow for shortcuts in that respect.

• Is it possible to allow key reuse in the OTP if, theoretically, you make sure that all keys are used an equal number of times(i.e. all keys equi-probable)? This is obviously close to impossible, but just curious, if this being impossible is why key reuse is not allowed? Aug 2 '15 at 16:19
• The key stream in OTP must be random. OTP is mainly a theoretical construct. If the key stream anywhere relies on previous data then it's not OTP but a stream cipher. There are pretty good stream ciphers out there and you can easily turn a block cipher into a key stream (e.g. CTR mode of operation). In that case you just need a key of around 128 bits and you'd be pretty safe. Aug 2 '15 at 18:52
• Why theoretical ? It lakes any sort of efficiency of course, but can be done in situations where the costs of losing security are beyond detrimental. I guess you can say theoretical if nothing in the world is truly random only impossible to model from our perspective Aug 2 '15 at 19:09
• Yes, precisely that and the fact that such a large key is very inefficient. Side notes: even though OTP is perfectly secure it still leaks the size of the plaintext and it doesn't provide integrity / authenticity either. Aug 2 '15 at 20:13
• It doesn't even provide non-malleability. $\;$
– user991
Aug 2 '15 at 21:48

If you use the OTP it has been used since its invention you will not get away with it. But there is a way that you can beat an attacker (Eve).

For the purpose of sending only text we will add a comma, full stop and a space character into an alphabet and randomise it. This will be the initial key that Alice and Bob share. The possible permutations for the randomisation are P29 = 29! = 29 x 28 x…..2 x 1. (Alphabet: P26 = 26! = 26 • 25 …….. 3 • 2 • 1 = 403,291,461,126,605,635,584,000,000)

This initial key needs to stay secret and only shared by Alice and Bob.

Below the image shows one of the possible permutations(P29); two messages we encrypted with two ciphers that displays the hex and decimal values we used to replace our text, a full stop and space characters.

Before Alice starts to encrypt her message she creates a pin number (we used 3 digits) that will be used to create the cipher. The first step she does is moving the starting point of her first permutation by using the first number of the pin.

1. STEP = EFWHAIJZK.LONPRQD GSTUVYXBMC, Position moved by 4 (T = 21)

Moving to the end of the string looking for the next character. When reaching the end she returns to the start of the string and moving again the position according to the next pin number.

2. STEP = FWHAIJZK.LONPRQD GSTUVYXBMC,E Position moved by 1 (H = 3, E = 26)

3. STEP = K.LONPRQD GSTUVYXBMC,EFWHAIJZ Position moved by 7 (space character = 10)

4. STEP = NPRQD GSTUVYXBMC,EFWHAIJZK.LO Position moved by 4

5. STEP = PRQD GSTUVYXBMC,EFWHAIJZK.LON Position moved by 1

6. STEP = TUVYXBMC,EFWHAIJZK.LONPRQD GS Position moved by 7

7. STEP = XBMC,EFWHAIJZK.LONPRQD GSTUVY Position moved by 4

8. STEP = BMC,EFWHAIJZK.LONPRQD GSTUVYX Position moved by 1

9. STEP = HAIJZK.LONPRQD GSTUVYXBMC,EFW Position moved by 7

10. Step = ZK.LONPRQD GSTUVYXBMC,EFWHAIJ Position moved by 4 (full stop = 1)

What Alice did is creating a string of random numbers which are as random as characters picked by an operator. Each number can represent any of the 29 characters in our randomised extended alphabet (1/29). Linguists too will have a problem to identify pattern that language holds since the randomization of our extended alphabet has destroyed them; and recording differences between characters doesn’t give anything away about the frequency of characters.

Now Alice can email her message and the pin code (of no use to an attacker without the correct permutation) and Bob can reverse it by using the pin code.

For a system that can encrypt text (no restrictions on languages), images, media files etc use a randomized ASCII (extended 256).

• Comments are not for extended discussion; this conversation has been moved to chat. Dec 17 '17 at 13:31