Lo siento, llegué tarde a esta discusión (qué ¿Tiene 3 1/2 años de edad ahora?), pero tengo un renovado interés en la generación de PRN y fuentes alternativas de entropía. El desarrollador de kernel de Linux, Rusty Russell, recientemente tuvo una discusión sobre su blog en fuentes alternas de entropía (que no sea /dev/urandom
).
Pero no estoy muy impresionado con sus elecciones; la dirección MAC de una NIC nunca cambia (aunque es única de todas las demás), y el PID parece demasiado pequeño como un tamaño de muestra posible.
He incursionado con un Mersenne Twister (en mi caja de Linux) que está sembrado con el siguiente algoritmo. Estoy pidiendo cualquier comentarios/feedback si alguien está dispuesto e interesado:
- Crear un buffer de serie de 64 bits + 256 bits * número de
/proc
Archivos continuación.
- Coloque el valor del contador de marca de tiempo (TSC) en los primeros 64 bits de este búfer.
Para cada uno de los archivos siguientes /proc
, calcular la suma SHA256:
- Crea un hash SHA256 de todo este búfer. NOTA: Pude (y probablemente debería) utilizar una función hash diferente completamente independiente de las funciones SHA; esta técnica se ha propuesto como una "salvaguarda" contra funciones hash débiles.
Ahora tienen 256 bits de con suerte aleatorios (suficientes) Datos de la entropía a sembrar mi Mersenne Twister. Uso lo anterior para rellenar el comienzo de la matriz MT (624 enteros de 32 bits) y luego inicializo el resto de esa matriz con el código del autor MT. Además, I podría usar una función de hash diferente (por ejemplo, SHA384, SHA512), pero necesitaría un búfer de matriz de tamaño diferente (obviamente).
El código original de Mersenne Twister requería una sola semilla de 32 bits, pero creo que es terriblemente inadecuado. Ejecutar "simplemente" 2^32-1 MT diferentes en busca de romper la criptografía no está más allá del ámbito de la posibilidad práctica en este día y edad.
Me encantaría leer los comentarios de nadie sobre esto. La crítica es más que bienvenida. Defenderé mi uso de los archivos /proc
como los anteriores porque están cambiando constantemente (especialmente los archivos /proc/self/*
, y el TSC siempre produce un valor diferente (resolución de nanosegundos [o mejor], IIRC). He ejecutado Diehard tests en esto (por una suma de varios cientos de mil millones bits), y parece estar pasando con gran éxito. Pero eso es probablemente más testimonio de la solidez del Mersenne Twister como PRNG que a la forma en que estoy sembrando ella.
Por supuesto, estos no son totalmente inmunes a que alguien los piratee, pero simplemente no veo todos estos (y SHA *) siendo hackeados y roto en mi vida.
[RFC 1149.5 especificó 4 como el número aleatorio estándar vetado por IEEE.] (Https://imgs.xkcd.com/comics/random_number.png) –
[Nueve. Nueve. Nueve. Nueve. ....] (http://dilbert.com/strips/comic/2001-10-25/) Ese es el problema con la aleatoriedad, nunca se puede estar seguro. – tvanfosson