¿Cuánto tiempo / "entropía recolectada" debería generar un par de llaves RSA 2048bit?

Question

¿Cuánto tiempo / "entropía recolectada" debería generar un par de llaves RSA 2048bit?

#1 de Tom Leek (6 votos)
#2 de humanityANDpeace (2 votos)
#3 de David (1 votos)

4

El propósito de mi pregunta es tener una mejor idea acerca de la cantidad de tiempo razonable que debe tomar la generación del par de llaves pública / privada de RSA.

Para ser menos vago, permítame especificar la pregunta y definir que usaría estos comandos para generar el par de llaves en una computadora portátil con un kernel de linux reciente 3.2.xx.

$ openssl genrsa -out testkey.private 2048
$ openssl rsa -in testkey.private -pubout -out testkey.public

He cronometrado acerca de los comandos y, en promedio, esta operación está tomando alrededor de 0,5 segundos, lo que me parece muy rápido (de hecho, demasiado rápido).

Sé que soy consciente de (y también intenté expresar eso en el título de las preguntas) que no es simplemente el tiempo, sino la cantidad de entropía y su tasa de reposición que influye en el tiempo necesario para crear el par de llaves. Al menos, asumo que la entropía se usa para generar las claves (de lo contrario, las claves serían predecibles y, en consecuencia, inútiles, ¿no?).

En el mismo sistema que usa gpg --gen-key de OpenPGP "GNU Privacy Guard", que también puedo usar para crear un par de claves RSA de 2048 bits, por ejemplo, toma mucho más tiempo e incluso requiere para mover el mouse, etc.

Así que me pregunto cómo se está sumando. En esencia, la cantidad de entropía y, en consecuencia, el tiempo que debe tomar una generación de par de llaves RSA en un sistema moderno.

Estoy convencido de que no hay un tiempo estándar, pero seguramente se puede estimar en términos de "menos de 30 minutos" "más de 10 segundos".

Dado que hay almacenamientos de "entropía" en el sistema. Supongamos que están vacíos y, por lo tanto, el momento en el que busco la creación de un "par de claves de RSA 2048" implica "comenzar desde cero" en términos de almacenamiento de entropía ".

¿Por qué OpenPGP gpg tardaría unos 2 minutos en crear un par de llaves RSA 2048 y openssl se hará en medio segundo ...?

entropy rsa

pregunta humanityANDpeace 16.03.2014 - 15:05

fuente

3 respuestas

Lea otras preguntas en las etiquetas entropy rsa

¿Cuáles son los beneficios de un sistema de inicio de sesión de dos páginas para una aplicación web? Sin apretón de manos de Airodump

score 6 · Answer 1

Por seguridad, todo lo que necesita es que el proceso se ejecute con más o menos 128 de entropía como semilla inicial. Entropía aquí significa: lo que el atacante no sabe . En particular, no hay problema si la entropía de origen same se extiende con un CSPRNG en el producción de muchos pares de teclas.

El modelo principal es el siguiente: el sistema operativo mantiene un "grupo de entropía" interno que contiene al menos 128 bits de entropía. Un PRNG criptográficamente fuerte extiende esa agrupación interna en una secuencia arbitrariamente larga de bits pseudoaleatorios, que, por definición, es impredecible por el atacante, porque 2¹²⁸ es demasiado alto número para que el atacante ejerza fuerza bruta en el grupo, y "criptográficamente fuerte" realmente significa "no se puede hacer mejor que fuerza bruta". En un sistema Linux, esto se llama /dev/urandom .

(Nota: parte de ser "criptográficamente sólido" también incluye "seguridad de reenvío": obtener el contenido del grupo después de la generación de claves no debe permitir "rebobinar" el PRNG a su estado anterior a la generación Los buenos PRNG son seguros hacia adelante.)

Hay un mito común acerca de que la entropía se "usa" como si fuera algún tipo de combustible. Esto no es cierto, excepto en un sentido muy teórico que se aplica solo si usas la aleatoriedad solo para One-Time Pad , y tu atacante es Dios. Para todos los demás casos, incluida la generación de claves para "algoritmos normales" como RSA y no incurrir en ira divina, la entropía no se consume cuando se obtienen bytes de /dev/urandom . El comportamiento de /dev/random en Linux es, de hecho, muy defectuoso ( /dev/random de FreeBSD es mucho mejor). Esta página web explica bastante bien las diferencias entre /dev/random y /dev/urandom , y por qué /dev/urandom debería ser preferido Léalo todo.

La pregunta restante es entonces: ¿por qué GnuPG usará /dev/random y no /dev/urandom para la generación de claves? Bueno, hay razones históricas (GnuPG destinado a sistemas de apoyo con PRNG muy deficientes provistos por el SO) y la inercia general (una falta de voluntad común para cuestionar la "sabiduría establecida", incluso cuando dicha "sabiduría" es mítica); pero la principal razón es que es tu culpa . GnuPG hace criptografía como medicina: no solo debe proteger los correos electrónicos, sino que el usuario humano también debe estar convencido de que acaba de producirse una criptografía potente. Las pastillas funcionan mejor cuando tienen mal sabor; de manera similar, los usuarios quieren que la generación de claves parezca un esfuerzo costoso. Su propia pregunta es un testimonio de ese sentimiento: aunque en realidad no sabe exactamente lo que sucede dentro de un CSPRNG (eso es una cuestión para los criptógrafos), todavía cree que "0.5 segundos es demasiado rápido". GnuPG cumple con sus caprichos al hacer un gran espectáculo del proceso de generación de claves. Esto es todo teatro de seguridad y sucede porque usted lo quiere de esa manera.

score 2 · Answer 2

mediante la medición de las lecturas de gpg y openssl de la archivos /dev/random y /dev/urandom que parecen ser las fuentes de entropía / aleatoriedad utilizadas, parece que la respuesta es que

para un par de claves RSA de 2048 bits que necesitamos / usamos

300bytes "de /dev/random de aleatoriedad" en caso de gpg
32bytes "de /dev/urandom de aleatoriedad" en caso de openssl

La diferencia de tiempo (gpg ca. 30secs) vs (openssl ca 0.5secs) se explica por el hecho de que /dev/random está bloqueando cuando está agotado de aleatoriedad.

score 1 · Answer 3

Para agregar a lo que humanANDpeace dijo, / dev / urandom es un CSPRNG que usa el grupo de entropía interna del kernel (lo que se usa para / dev / random, también un CSPRNG que bloquea con una estimación de entropía == 0) pero extendido por una Algoritmo CSPRNG. Esto significa que leer desde / dev / random es muy lento a menos que tenga un RNG de hardware que lo alimente.

GnuPG usa la entrada de datos sin procesar de / dev / random para la generación de claves. Utiliza / dev / random porque quiere garantizar una entropía de muy alta calidad para las teclas, y / dev / urandom no es una buena fuente de entropía en algunos sistemas (o al menos no lo era, no estoy seguro de que esto sea así) verdadero).

OpenSSL, por otro lado, utiliza 32 bytes de / dev / urandom para generar su propio CSPRNG interno, luego genera los datos necesarios para la generación de claves desde allí. Esto explica las operaciones más rápidas.

A menos que se encuentre una debilidad en los datos aleatorios generados por / dev / urandom que no afecten también a / dev / random, las claves generadas de cualquier manera deben ser seguras. Se cree que / dev / urandom es criptográficamente seguro y se usa para muchas otras operaciones, por lo que una debilidad en él sería un gran problema.