# How secure is my OTP program?

I'm writing a 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 are my hobbies. 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 won't have any access to the key file).

The program starts off by:

1. Making a list of 50 numbers from the mouse movement coordinates at the start of the program.
2. That number list is then the seed to the ISAAC Random Number Generator (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 Random Number Generator.
4. The file-to-be-encrypted and the generated Key file are XOR'ed and saved to a new file--the ciphertext file.
5. (deciphering) Happens by XOR'ing the key file and ciphertext file, and you get the plaintext 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
• @MartinSuecia And a stream cipher seeded only with 50 numbers from mouse movements. Even with high-resolution timestamps, it's rather weak. – forest Dec 15 '17 at 6:17

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.
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).
• 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