¿Es posible encontrar el algoritmo para un generador de números aleatorios estudiando las secuencias que produce?

En aras de la brevedad, no hablaremos ni de la semilla, es decir, el número que se le da al algoritmo para arrancar su proceso de generación pseudoaleatorio, ni del entorno en el que se ejecuta, y del cual puede extraer algo de aleatoriedad (tiempo, temperatura de la CPU, etc.). Solo hablaremos de un generador pseudoaleatorio determinista. Solo hay una cantidad finita de información en el algoritmo. Puede más o menos (descartando una gran cantidad de detalles importantes) asignarlo al tamaño (en, por ejemplo, MB o kB) del archivo de programa.

Por lo tanto, el generador de números pseudoaleatorios solo puede generar una cierta cantidad de números aleatorios antes de comenzar a revelar información sobre sí mismo.

La noción matemática que vincula la salida de un programa a lo que informalmente podemos llamar su verdadero contenido de información se denomina complejidad de Kolmogorov. Kolmogorov complexity - Wikipedia

La forma en que medimos la información contenida en, digamos, la salida de un programa está fuertemente ligada a su aleatoriedad, se llama entropía o información de Shannon: Entropy (information theory) - Wikipedia

Desea tener un programa cuya salida tenga mucha entropía, es decir, que sea aleatoria, pero no desea almacenar esta salida como está en el disco (esto sería un pad de una sola vez, es un medio irrompible de cifrado pero requiere el tránsito de una gran cantidad de datos secretos), desea almacenar un programa que lo calculará en tiempo de ejecución.

El problema es que existe un límite inferior en la complejidad de Kolmogorov de una verdadera cadena aleatoria, que es más o menos la longitud de la propia cadena. Esto es salvo algún caso patológico donde el entorno de ejecución se define como que contiene la cadena aleatoria que desea generar. No hay forma de minimizar la complejidad de Kolmogorov en general.

Es por eso que no puede comprimir un archivo dos veces, por ejemplo.

Tenga en cuenta que la salida de un programa no necesita repetirse. Por ejemplo, podría generar los dígitos de pi o de cualquier número irracional y nunca repetirlo, pero la complejidad de Kolmogorov de pi es finita: puede escribir un programa que genere dígitos de pi, y este programa cabrá en una cantidad finita de memoria .

Cómo adivinar realmente la estructura del algoritmo es otra lata de gusano. El enfoque ingenuo está vinculado a uno de los problemas fundamentales de la informática: el problema de detención: si intenta enumerar todos los programas de tamaño razonable y ejecutarlos para ver si su salida coincide con la de su algoritmo misterioso, encontrará que algunos programas nunca terminan. Y algunos otros terminan después de un tiempo reaaaaaaaaally. El problema es que la cantidad de tiempo que tiene que esperar antes de poder detener un programa porque nunca terminará es literalmente incontestable, se llama número de castor ocupado: Busy beaver - Wikipedia

Nunca sabrá si tiene el algoritmo que busca y simplemente no es lo suficientemente paciente para obtener la respuesta, o si solo está viendo un bucle sin fin ...

En la práctica, sin embargo, existe una variedad de ataques: puede intentar aprender a predecir el resultado con técnicas de aprendizaje automático, puede intentar obtener información sobre la implementación probable utilizando pistas (qué algoritmos se usan comúnmente, qué sistema se está ejecutando encendido, puedo cronometrar la ejecución del algoritmo ...).

Todos esos ataques de canal lateral son la razón por la que los sistemas de cifrado son muy difíciles de implementar en la práctica, ya que el más mínimo error puede hacer que todo se caiga.