El generador de números aleatorios de dos componentes

[Karl] necesitaba un generador de números aleatorios de hardware, pero había algunas necesidades: tenía que ser barato y bastante aleatorio. La generación de números aleatorios puede volverse bastante loca con los tubos Geiger, las bengalas y la descomposición radiactiva, pero se ha encontrado una solución mucho más pequeña en un microcontrolador AVR de 8 pines.

La solución utiliza AVRentropy, una biblioteca que utiliza el temblor del temporizador de vigilancia en los microcontroladores AVR para proporcionar números aleatorios criptográficamente seguros. Configurar el circuito fue fácil: el microcontrolador ATtiny45 se conectó a un convertidor USB a serie chino económico. Tres cables, y el circuito está completo. El código también era simple; es solo una llamada para inicializar la entropía y escribir los bits en el puerto serie.

Hay algunas desventajas en esta construcción. Debido a que la biblioteca de entropía tiene que esperar hasta que se recolecte suficiente entropía, solo puede producir alrededor de dos números de 32 bits por segundo. Eso es todo [Karl] necesario para su aplicación, sin embargo, y con un recinto hecho de corcho de vino y mármol, tiene el generador de números aleatorios más bonito y pequeño que existe.

  • si, eso es correcto dice:

    "números aleatorios criptográficamente seguros"

    • Leonardo dice:

      El tiempo es probablemente esencial.

    • toriobr dice:

      Sí, son seguros. El dongle solo envía números aleatorios generados por la MCU, y el código es lo suficientemente simple como para que casi todos lo lean.

      Después de Snowden, casi todo el mundo desconfía de todo lo relacionado con las criptomonedas, pero si no cree que esos números sean seguros, al menos diga por qué.

      • trui dice:

        No es absolutamente seguro, pero para la mayoría de los propósitos es bastante bueno. Es más fácil poner una puerta trasera en el programa para el que se utilizarán estos números aleatorios que piratear este dispositivo, especialmente porque es un dispositivo personalizado.

        Por supuesto, para la mayoría de los propósitos, un generador aleatorio de software simple en una computadora que usa entropía disponible libremente también es bastante bueno en casi todos los casos.

        • electrón excéntrico dice:

          Creo que en este caso el elemento de "seguridad" se relaciona con la generación de los números aleatorios en sí mismos (¿la secuencia es realmente aleatoria e impredecible? Generar secuencias realmente aleatorias es mucho más difícil de lo que podría parecer a primera vista) en lugar de la forma en que luego se tratan los números generados.

          • trui dice:

            Los números generados probablemente no sean realmente aleatorios e impredecibles. El oscilador RC que mueve el perro guardián no es completamente independiente del entorno y responderá a las fluctuaciones de temperatura/voltaje que un atacante puede controlar o leer. Además, con equipos bastante sensibles, las emisiones de RF se pueden detectar desde cierta distancia.

            Me doy cuenta de que la gente tiende a centrarse solo en una parte de toda la red de seguridad (el generador de números aleatorios), pero un sistema de seguridad completo tiene muchos más elementos. No tiene sentido preocuparse por números perfectamente aleatorios e impredecibles si se van a utilizar en un sistema con debilidades más fáciles.

          • afeitado_fuegos dice:

            Trui tiene razón, otro ejemplo que vi de cómo el uso de FPGA podría haber sido influenciado por calentarlo o dejar que se calentara por un uso difícil. También diría que debería haber un nivel de falla antes de que se usen esos números, y tal vez esa sea parte de la razón por la cual es un retraso. Prefiero el método Geiger o el método del ruido del amplificador (https://la-tecnologia.com/2012/09/12/generating-random-numbers-from-white-noise/) en el aspecto teórico.

        • walter anderson dice:

          Trui, como autor de la biblioteca en cuestión, puedo asegurarle que se ha demostrado que la biblioteca produce números criptográficamente seguros y verdaderamente aleatorios (distribución uniforme). Sin embargo, la seguridad depende en gran medida de la implementación física, por lo que el usuario final es responsable no solo de esto, sino también de la supervisión periódica para garantizar que la seguridad no se vea comprometida.

          • trui dice:

            Ah, pero ¿revisó el compilador para ver si reconoció que estaba construyendo la biblioteca e insertando una puerta trasera en sus archivos de objetos? (no tan lejos como puedas pensar, porque eso se hizo antes).

          • walter anderson dice:

            Una vez más, "la seguridad depende en gran medida de la implementación física, sin embargo, como usuario final, uno es responsable no solo de eso, sino de verificar regularmente para garantizar que la seguridad no se vea comprometida".

          • trui dice:

            Así es. Por lo tanto, el usuario final todavía tiene que verificar todo de principio a fin, incluida la biblioteca en sí, el kit de herramientas, la interfaz USB, la computadora y los detalles del hardware del reloj, que no son fácilmente accesibles para su inspección, además de asegurarse que el atacante no tiene forma de controlar o manipular dichas influencias externas. Dado que nadie hace todas estas cosas, no podemos asumir que es "completamente seguro". Por supuesto, podemos estar de acuerdo en que es "lo suficientemente seguro" para la mayoría de los propósitos típicos. Pero, de nuevo, se puede decir lo mismo de /dev/random.

          • walter anderson dice:

            Sí, todo eso me suena bastante mal. Parece que BT tampoco es para mí.

            Por supuesto, a menos que la NSA lo esté siguiendo (o tenga miedo de que lo esté), es probable que el dispositivo OP funcione bien tal como está. Más aún si solo lo usan en varias computadoras y, por lo tanto, no tienen que preocuparse demasiado por ese final.

            Y no todos los sistemas operativos que tienen /dev/random funcionan... y de los que sí lo hacen, esta biblioteca y dispositivo creado por el usuario es mucho más fácil para que ese usuario haga la verificación descrita anteriormente de lo que sería para la mayoría de los usuarios controlar ese /dev . / accidentalmente no comprometido ...

            Y, por supuesto, esta técnica no necesita una computadora en absoluto si la tarea puede ser manejada por unos pocos microcontroladores.

    • si, eso es correcto dice:

      Los "generadores aleatorios verdaderos" no son "generadores aleatorios criptográficamente seguros" porque con el "generador aleatorio verdadero" existe la posibilidad de obtener 0, 0, 0, 0, 0, 0, 0 en su salida y no lo hace. quiere eso para crypto.

      • walter anderson dice:

        Oportunidad, si. Extremadamente pequeño. Y dependiendo de para qué lo uses, realmente lo quieres. Criptográficamente seguro básicamente significa que no puede predecir el flujo aleatorio...

      • trui dice:

        Si tiene que preocuparse por obtener todos los ceros, no está usando suficientes bits.

  • hboy007 dice:

    He estado allí, hecho eso. Lo único que todavía me confunde es la distribución de código de una implementación simple (usando wdt y cristal de 8 MHz): http://abload.de/img/200kphasenoisehist2rq8x.png (200k valores de 8 bits recopilados y agrupados).
    Agregué algunas líneas para asegurar una distribución de código plano (no hace falta decir que esta medida no aumenta la aleatoriedad). Habrá que echar un vistazo más de cerca a AVREntropy.

  • cara de pedo dice:

    Amplificador operacional simple ajustado a ganancia loca y luego a entrada de línea digital. Hace un gran generador de números aleatorios reales.

    • SparkyGSX dice:

      Tal vez tal vez no. Para la mayoría de los propósitos, podría ser bastante aleatorio, pero para un generador de números aleatorios criptográficamente seguro, la distribución también debe ser aleatoria e, idealmente, debería ser imposible afectar externamente al generador de números aleatorios.

      Creo que su propuesta significa más o menos que es un amplificador que amplifica la señal de un circuito mal sintonizado (a diferencia de un receptor de RF altamente selectivo); esto significa que probablemente sería posible influir en la salida iluminando el circuito con una fuerte señal de RF.

      Es bastante fácil idear un circuito que pueda funcionar; es muy difícil demostrar que cualquier circuito funcione realmente como un generador seguro de números aleatorios.

    • fuente dice:

      tal vez, tal vez no, podría captar una estación de radio local o simplemente oscilar. La fuente de ruido simple habitual es un amplificador y un diodo genérico.

      • Greenaum dice:

        ¿Amplificador operacional en jaula de Faraday? ¿Con salida óptica?

        ¿Todavía no hay mucha buena entropía en el método anticuado de "presione muchas teclas" y mida el tiempo en microsegundos?

    • walter anderson dice:

      Es más complicado de lo que crees...
      http://code.google.com/p/avr-hardware-random-number-generation/

  • atomsoft dice:

    ¿Cómo es este "Generador de números aleatorios de dos componentes" si hay mucho más de 2 componentes? No intente escribir que la PCB (USB a UART) es un componente porque entonces puede hacer todo esto en 1 pcb y llamarlo un componente aleatorio 1 ... así que ... ¿alguna idea sobre eso?

    • mike lu dice:

      Es un RNG de salida UART. Los dos componentes son el microcontrolador y su derivación. USB a UART es solo un adaptador. Aunque su baja velocidad es casi inútil: simplemente digitalizar una entrada de sonido analógico no utilizada y usar los LSB le brinda 96 kbps o más. De hecho, asumo que un verdadero generador de números aleatorios de un solo componente sería un diodo zener integrado en un conector de 3,5 mm, que luego se conecta a la entrada del micrófono de una computadora u otro dispositivo.

      Dicho esto, he usado con éxito el ruido zener para generar números aleatorios. Combinado con LFSR para degradarlo, incluso pasará pruebas aleatorias.
      http://dangerousprototypes.com/forum/viewtopic.php?f=62&t=4632

      Si necesita una generación de números aleatorios criptográficos de muy alta velocidad, su mejor opción es usar ADC de alta velocidad para digitalizar el ruido, descartar algunos de los MSB y usar cifrado criptográfico y/o hash para depurarlo aún más. De hecho, algunos algoritmos de cifrado como AES son en realidad solo CSPRNG. Su salida es impredecible mientras la clave permanezca en secreto.

      • fuente dice:

        un truco para obtener un ruido blanco simétrico de zeners es usar dos y restar las salidas

    • ... dice:

      Debería preguntar a los 'editores' de HAD, el autor nunca afirmó que tiene solo 2 componentes.

  • zibri dice:

    Estoy de acuerdo.
    http://web.jfet.org/hw-rng.html

  • Josué dice:

    Pseudoaccidental...

    • Megol dice:

      No he mirado el diseño, pero es totalmente posible generar números aleatorios verdaderos a partir de una fuente de reloj. La idea no es para usar el reloj como tal sino para dibujar el temblor que depende de varios. cosas como el ruido térmico. Uno "solo" es asegurarse de filtrar los componentes deterministas para obtener una fuente aleatoria adecuada.

    • walter anderson dice:

      Lo siento, pero no, se probó (y gran parte se explica en el enlace de la biblioteca proporcionado)... Como autor, tuve dos implementaciones en uso constante durante más de 16 meses y todavía no ha fallado.

  • cuidado dice:

    Atmel ATSHA204: I2C o un chip de bus de cable que proporciona mucha autenticación y "TRNG", pero probablemente estará lleno de puertas traseras de la NSA, así que utilícelo bajo su propio riesgo 🙂

  • rj dice:

    Por favor por lo menos cuidar los datos a través de las pruebas más duras o difíciles antes de afirmar que son criptográficamente seguros. p.ej. Los LFSR producen promedios / autocorrelación / blancura / histogramas increíblemente hermosos y, sin embargo, son excelentes PRNG.

    • Megol dice:

      Si no confundo las pruebas (siempre es una posibilidad), incluso corriendo duro, no hay garantía de que el generador no tenga sesgos que debiliten la fortaleza criptográfica.

    • walter anderson dice:

      Como autor de la biblioteca, puedo asegurarle que el generador ha sido (todavía en curso) probado. En varios chips avr, por varias personas. Tengo dos implementaciones que han producido un flujo aleatorio durante más de 16 meses. Si tiene curiosidad, puede leer sobre esto en http://code.google.com/p/avr-hardware-random-number-generation/

    • walter anderson dice:

      Las pruebas básicas se usaron como pantalla, ya que los primeros informes de temblores que producen entropía para la serie AVR indicaron que algunos tipos de chips tienen problemas. Las pruebas más detalladas requieren múltiples muestras independientes del flujo de entropía y son mucho más complicadas para presentar los resultados. Diehard necesita 10 MB de datos para cada muestra y Dieharder necesita alrededor de 300 MB para cada muestra. La naturaleza de los verdaderos generadores de números aleatorios (a diferencia del PRNG para el que se diseñaron las pruebas anteriores) es que fallará en algunos de los componentes de la prueba ALGUNAS veces. Requiere muestreo múltiple y análisis estadístico para determinar si estas fallas son significativas... No es algo fácilmente transportable o escrito en una página Wiki... Todavía estoy probando los datos, y aún no ha fallado...

    • JGM dice:

      ++

      Además, Nist STS es otro buen recurso para ser implementadores de RNG. Si bien ninguna de estas herramientas le dirá que su RNG es seguro, ciertamente pueden decirle que su RNG está roto.

  • walter anderson dice:

    Por cierto, con solo 2 segundos de entropía de 32 bits, los dos dispositivos que tengo que han estado funcionando durante aproximadamente 16 meses solo produjeron alrededor de 320 MB de entropía cada uno. O suficiente para que una muestra muera... Ni siquiera puedes combinar las pruebas para varias muestras, porque no es realmente válido probar la validez de una sola fuente como esa.

  • BobC dice:

    Esto sería ideal en Digispark, sin necesidad de un dongle USB: http://digistump.com/products/1

  • Koplin dice:

    Hice mi propio RNG real a partir de una fuente de isótopos radiactivos de un detector de humo y una vieja cámara web.

    No soy el primero en hacer esto y no hice un protocolo de construcción, tuve la idea de esto

    http://www.inventgeek.com/Proyectos/alpharad/overview.aspx

    • mike lu dice:

      Si puede encontrar una manera de quitar el vidrio sin arruinar el CCD, obtendrá muchas más "manchas". El vidrio detiene las partículas alfa, por lo que es la radiación gamma desde abajo en la cadena de descomposición lo que hace que funcione.

      • Greenaum dice:

        Me recuerda al viejo truco del MIT (creo que en su momento) de apuntar una cámara (antes de que tuviéramos cámaras web) a la linterna. Haz un poco de matemáticas y obtendrás alguna oportunidad.

  • euler357 dice:

    Es de esperar que Diehard, ent, rngtest y otros probadores de números aleatorios muestren algunas fallas con un verdadero generador de números aleatorios. Si ve pasajes al 100 % con una secuencia larga, debe sospechar que la secuencia es pseudoaleatoria o está filtrada para eliminar estos casos. Por ejemplo, una de las pruebas es para una cadena larga de 0 o 1. Esto hace que sea estadísticamente probable que a estas cadenas se les dé un bloque bastante grande de números aleatorios.

    Hay una comparación de generadores de números aleatorios aleatorios en Wikipedia:
    https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators

América Aguilar
América Aguilar

Deja una respuesta

Tu dirección de correo electrónico no será publicada.