# Reusing one-time-pad with random plaintext

I understand that by definition one-time-pad keys cannot be reused but I was thinking about the case where it is used to send random data and couldn't find anything on the subject so here is my idea:

Sending y-bits of data using x-bits of random data as a key where y > x.

Step 1: Both parties agree on a x-bits key (With DH or a safe communication). EDIT: This is only so users can remotely agree on a key, they could also physically share a key.

Step 2: Either agree on a pseudo random data generator before hand or submit an array of random bits to the receiver(The size depends on the algorithm used on Step 4). EDIT: This data doesn't need to be a secret.

Step 3: I xor the bits generated on Step 2 with the key to get another random array.

Step 4: Use the result of Step 3 on a PRNG or hash function to add more security. Without this step a many-time-pad attack would be possible (Or "easy" at least).

Step 5: xor y with the data to be encrypted to obtain the cipher version.

With this, as long as the algorithm use in Step 4 is random the key can be reused without any worries. The only problem is that one could brute-force it. But since the key doesn't have a size limit all we would need to do is to use a key with a decent size (256 or 512 bits).

Could this be a replacement for AES? If I'm not mistaken only a brute force attack can find the plain-text without the key. Considering that Steps 2 & 4 add enough randomness.

A PRNG is basically a really slow stream cipher; the random data can be thought of as a key stream. So what you just did is defining a stream cipher using whatever primitives the PRNG is based on.

Adding an additional hashing method - basically another deterministic algorithm - doesn't do much if the PRNG is strong; the PRNG may even be used by the PRNG itself. As it is deterministic it will certainly not protect you against replay.

Choosing a random hash method goes against Kerchhoff's principle. There aren't enough hash methods to provide security. If you can configure them somehow then the configuration parameter acts as a key.

• I was trying to compensate for a weak PRNG. The data on Step 2 doesn't need to be a secret and doesn't need to be dynamic either. Step 4 was to just remove data leakage but would just increase the complexity. I don't see where my description goes agaisnt Kerchhoff's principle but I guess it doesn't really matter. And "You need to know a lot more to start creating secure algorithms, or even to describe them well."...well I gotta start somewhere, I don't really understand what you were trying to tell me with that. Give up or maybe that I'm stupid? Commented Jan 26, 2015 at 4:19
• Never give up. Maybe reevaluate now and then. But do try to study the subject, this was more meant as an incentive to study the subject than to put you off. There are hundreds if not thousands of proposals. If you cannot describe them well or show a security reduction than your proposal has a snowballs chance in hell, even if it is good. Commented Jan 26, 2015 at 8:52
• "well I gotta start somewhere" Yes and no. A good start is cryptanalysing existing schemes to get a hang of things. Reading up on various methods to attack schemes helps as well. Designing your own scheme is like the top of the art - nothing to start with, if you are actually serious about it. And another step before designing anything is: Learn how to write up proofs of security, get familiar with known techniques and security definitions
– tylo
Commented Jan 26, 2015 at 10:48

This question is not really well defined. If by "Would this actually work?" you mean "Will this be as good as using a one time pad of length y" then the short answer is No. Anything susceptible to a brute force attack is not as secure as a one time pad.

What are you trying to achieve? If you already agreed on a key of 512 bits and assume this is the difficulty of brute forcing your algorithm, why not use any common symmetrical encryption algorithm such as AES? It seems you are attempting to design a symmetrical encryption algorithm. This is a great exercise to do, and there are many considerations to be made. For an introduction to some of these considerations, but without too much delving into the theory, I highly recommend the book Cryptography Engineering.

To go into specifics, I'll address a few issues:

Step 1: A one time pad is agreed upon by physically giving 2 or more parties the same key (or by using leveraging quantum key distribution (QKD), but we'll leave this aside for the moment). Any other type of key exchange is only as secure as the key exchange protocol itself.

Step 2: By random generator, you must mean pseudo-random generator (PRNG), for two reasons:

1. If two generators generate the same string, they are definitely not random (again, excluding QKD).
2. If you have a truly random generator, there is no need for this scheme, as you can already generate a one time pad of arbitrary length.

So we have now established that the security of the bits in step 2 is at most that of the pseudo random generator. The word security can have different definitions, and is commonly expressed in number of bits, a system with 128 bits of security is as secure as a 128 bit random key, i.e. to brute force it you would need to do on the order of 2^128 computational steps.

Step 3: This would not be necessary. If step 2 gave you a truly random array, this would be no more secure. If step 2 gave a pseudo-random array, this would only add a little more security to the randomness by mangling it with x. But as x is reused (because it is shorter) it could be brute forced.

Step 4: This again is only as secure as the PRNG used (hash functions and AES are not truly random)

• I guess my question is: Could this be used to replace AES? Considering the possibility that AES is broken. On Step 1 I want to give the user the option to agree without physical communication, which can also be done to increase security. Step 2: I see your point. But on my scheme they wouldn't need to be secret because of step 3. Step 4: I know that you can always map input to output and use a truth table to derive a function for them. But the idea was to add so much complexity to the mathematical relation that the brute force is the only option. Commented Jan 24, 2015 at 15:34
• Could it replace AES? No. From a first glance, this is just a stream cipher, which is slower than a block cipher. This is quite bad from a performance point of view, and if AES is broken: Usually stream ciphers are faster than block ciphers - that's one of the reasons why they are used. And anyway: Before any symmetric scheme is actually usable, it has to withstand years of cryptanalysis.
– tylo
Commented Jan 26, 2015 at 10:42