# Why not use an algorithm's code rather than data itself for one time pads?

Instead of using actual data for one time pads, what would be different if the code for an algorithm was exchanged so that to acquire the pad one would execute the algorithm and use its output? Why is this not being used?

An algorithm would be much shorter and could generate a significant amount of chaotic information. There are so many examples of deterministic unpredictability from fractals (discrete maps) to cellular automata to irrational digit sequences (differential equation zeros?) to CPU floating point operations to modular exponentiation. And many ways of combining these into more feedback loops.

Even if the output is not as cryptographically strong, aren't there deterministic operations that can ensure a certain level of strength? And couldn't a computer conceivably do the work of trying long and complex combinations of chaotic algorithms and classes of initial values until an algorithm does produce strong pads to settle on the pad you will use? There would be no point in an attacker guessing at the probability of kinds of initial values if he doesn't even know the combination algorithm used to generate the pad. It seems that there would even be safety from guessing from the code length and execution time, even if not padded.

-
The short answer is -- that's not a one time pad. You can use a car to get to work instead of a bicycle, but you can't use a car as a bicycle. –  David Schwartz Jan 1 '12 at 14:04
That's the best answer I've heard so far. Simplicity is powerful. –  jnm2 Jan 1 '12 at 23:25

Generating a pseudo-random stream from a key, and XORing that stream with the data to encrypt, is done on a regular basis. That's how most stream ciphers work, e.g. the well-known RC4, and also applies to block ciphers in counter mode. This is not "One-Time Pad", by definition, since OTP requires the key stream to be truly random (that's the condition from which the OTP unbreakability comes). Such stream ciphers still share with OTP the absolute necessity of never reusing a given keystream for two distinct messages, so the encapsulating protocol must take care to renew keys when needed. In SSL/TLS, a new session key is generated for each connection, so when a stream cipher is used (RC4), things are safe.

There are quite a few stream ciphers which have been seriously looked at by cryptographers, who found nothing bad to say about them; see the eSTREAM portfolio for a selection of those.

Chaos, fractals and so on, are not the right tool for cryptography. A chaotic system is just a producer of values which "jump around" in a seemingly random fashion. Statistical analysis tools could be defeated by a chaotic system. But statistical analysis tools are dumb: they are designed to analyze physical phenomena. For cryptography, we want to defeat an intelligent attacker who has a copy of the same software than the one you use, save for the keys themselves. For instance, a Linear Feedback Shift Register has very good statistical properties and produces bits which statistical tools will declare "plausibly random". But for a $n$-bit LFSR, it suffices to observe the first $n$ bits of output to learn the complete internal state, and predict all subsequent output with 100% accuracy (even if the LFSR structure -- the corresponding polynomial -- is unknown, $2n$ output bits are sufficient for that, with Berlekamp-Massey algorithm).

In short words, if you use fractals or a chaotic system in a homemade loop, you will make a cryptosystem apt to defeat a chimpanzee. We cryptographers usually aim a bit higher than that.

Also, secrecy of "the code" (i.e. software) is usually not assumed, because it is very hard to achieve. Software exists in some permanent storage, on a computer hard disk; there's source code somewhere; it is bulky. Keeping code confidential is hard, and even harder is knowing how much confidential it is. This is why cryptographers talk about keys: they split the "code" (e.g. a pseudo-random stream generator) into an algorithm, which is public and becomes software, and a key, which is a small sized parameter which concentrates confidentiality. A typical key is a sequence of, say, 128 bits, small enough to be handled and protected properly (it can even be remembered by a human, and typed back when it is needed -- thus, no need for storage on a hard disk).

-