# How secure is my OTP program?

I'm writing an One-Time Pad encryption program, because I got really interested in the idea of " encryption which has been proven to be impossible to crack if used correctly". I'm writing the program just for fun, as programming and cryptography is my hobby. Therefore, I don't expect the program to be used for highly vulnerable data. I just wonder how secure my program is, and what I can improve (considering that the hacker don't have any access to the key file).

The program starts off by:

1. Make a list of 50 numbers from the mouse movement coordinates at the start of the program.
2. The number list is then the seed to the ISAAC Random Number Generater (More info here)
3. A key file is generated based on the size of the file to be encrypted. The Key file is generated from random numbers from the ISAAC Generator
4. The File-To-Be-Encrypted and the generated Key File are XOR'ed and saved to a new file - The cipher file.
5. (deciphering) Happens by XOR'ing the Key File and Cipher File, and you get the plain text file.
-
You are implementing a "stream cipher" and not the One Time Pad. The OTP requires the full pad to be completely random, which is not the case here. –  MartinSuecia Jun 6 '12 at 8:30
Maybe see also Steven Bellovin about Frank Miller an OTP mice.cs.columbia.edu/getTechreport.php?techreportID=1460 –  user2262 Jun 7 '12 at 8:15

The perfect security of OTP hinges on the fact, that keys must be chosen truly at random and uniformly from the domain of all possible keys, i.e. all bitstrings of a certain length. The problem with your approach is that you use a pseudorandom number generator to generate the key.

It does not matter how good the generator is, because the entropy that can be used to generate the key is limited by the seed you use.

Let's, assume that the 50 numbers you use are really random and distributed uniformly -- and that is at least debatable for mouse movement. If you use 50 number in some range, lets say between $0$ and $x-1$, then for files of any size, you only ever produce at most $x^{50}$ different keys.

Obviously, for large enough files, this is much smaller than the total number of all possible keys and therefore, your perfect security does no longer hold.

An attack would for example consist of deciding which of two messages $m_1,m_2$ is encrypted in a ciphertext (your basic indistinguishability game). Keep in mind that for perfect security the runtime of the adversary is unbounded. That means that $\mathcal{A}$ could enumerate all $x^{50}$ possible keys and check if any of those decrypts the ciphertext to one of the two messages. This works basically, because the number of possible keys is much smaller than it should be and the chance that the ciphertext could also be decrypted to the other message is very small (for large enough messages).

-
Thanks for the nice and detailed answer. –  Janman Jun 6 '12 at 8:53
So if I understand this right, I have to make an infinite large list of numbers to use as a seed? That is no question a problem, even on the most high-end systems nowadays, so I guess that's no way around. Is there an efficient way to seed a RNG with enough numbers to actually make the algorithm secure? –  Janman Jun 6 '12 at 9:00
Well, if you already have enough random data, there is no need for a PRNG actually. What you might need is a randomess extractor, because the data you have is possibly not uniformly distributed. Also you do not need an infinite amount of random data, but if you want to generate a $\kappa$-bit key, you will need $\kappa$ bits of entropy. –  Maeher Jun 6 '12 at 9:08