The Collatz Conjecture is an iterative process with two equations whereby given any initial integer, the eventual result will be 1. No counterexample has been found since the conjecture was made in 1937 despite testing every positive integer up to and far beyond a trillion. The conjecture remains unproven. It is also impossible to predict how many iterations it will take for any starting value to converge to 1.
I believe cryptographically secure random numbers can also be made through an iterative process. Alternating the natural logarithm and sine seem to work particularly well as they consistently produce a decimal with at least 10 digits. Before explaining it further, I will give a brief overview of the one-time pad method of cryptography. This is the only encryption method which is theoretically unbreakable.
Here's how it works. First, a plaintext dictionary is made where each unique word is assigned a 4-digit code between 0000 and 9999. That gives a vocabulary of 10,000 words, which is more than enough for clear communication. In any language, a vocabulary of 6,000 words covers about 95% of what is written or spoken. When the message is being encrypted, a random 4-digit number from a pad is added to each code word. Because there are two unknowns (the code word and the random number) but only one "equation" (the encrypted message), there is no way for an interceptor to decode the message. The only times encrypted messages from one-time pads have been cracked happened when the same set of random numbers were used for multiple messages.
I don't know how the KGB generated its random numbers, but I suspect they started out with something like tables of square roots, trigonometric functions, or logarithms. Those were worked out to 4 decimal places in old reference books such as Machinery's Handbook.
The problem with trying to use an equation or a group of them to produce random numbers through iteration is if the number of digits being iterated is the same as the seed value, eventually the seed value will be produced by one of the iterations. The obvious solution to this is to make the seed value a different number of digits than the iteration values. Here are a few examples to clarify:
If I use the calculator on my phone take the sine, logarithm, or square root of almost any 2-digit number, I will get a 10-digit decimal. I can use the first 8 digits to make two 4-digit code groups and use the last 2 digits to iterate the process.
sin(10) = 0.1736481777
sin(77) = 0.9743700648
sin(48) = 0.7431448255
I get the following as random numbers: 1736, 4817, 9743, 7006, 7431, 4482.
If I iterate further, I get stuck in a loop of sin(42), sin(64), and sin(63). This pattern, I suspect, plays out for every function similar to the Collatz conjecture. It probably also plays out for any combination of functions.
For the purposes of cryptography, it doesn't matter if a function or set of functions gets stuck in a loop so long as that takes several hundred iterations to happen.
If I start with a 3-digit seed value, and alternate ln and sin, I get something like this:
ln(123) = 4.8121843554
sin(54) = 0.8090169944
ln(44) = 3.7841896339
sin(39) = 0.6293203910
With this method, it is impossible for the iteration to produce the seed value because the number of digits is different. It is possible, even likely, that this set of equations will get stuck in a loop after enough iterations. A computer program would be useful for checking that. Thus, to send an encrypted
message using this system, all the two communicants need are a shared code group dictionary, seed value, set of equations, and their phone calculators.
It would take some work to identify which combinations of equations and seed values produce the most random numbers before getting stuck in a loop. Here again computers would be useful. Finding the right combination of equations and seed values would be akin to the search for large prime numbers.
Even if the nature of the encryption algorithm was public knowledge, this method would still require a brute force attack to break. An attacker would need to try different equations and different seed values. The number of possibilities for both are very large. For example, both the functions above could be multiplied by some constant or have some value added. That would introduce even more unknowns.
I used to believe any code produced by a machine could be broken by a machine. Some algorithms really have the secret sauce. In short, one-way functions exist.
