OpenVPN dhparam

16

Uno de los pasos para configurar OpenVPN es ejecutar el comando openssl dhparam -out dh1024.pem 1024 . La página de manual me dice que este valor 1024 se refiere al número de bits.

  • ¿Por qué se sugiere el valor 1024 en los ejemplos?
  • ¿Debo usar un valor mayor como 4096 ?
    • ¿Qué valor debo usar, cuántos bits son suficientes, por qué?
    • Las claves RSA de 1024 bits ahora se consideran débiles, y a menudo se sugiere usar 2048 bits o más. ¿Este tipo de situación se aplica también a este archivo dhparam?
  • El comando para generar este archivo parece tardar ~ 10 horas en el dispositivo I que usaré como servidor OpenVPN. ¿Es seguro generar este archivo en una máquina más rápida y transferirlo? ¿Debería tratarlo como la mayoría de las claves privadas y mantenerlo solo en ese host? ¿Qué tan secreto debe ser este archivo?
pregunta Zoredache 14.09.2013 - 02:21
fuente

2 respuestas

10

Mucho de esto ha sido abordado antes. Consulte mi respuesta y La respuesta de Thomas a una pregunta relacionada para obtener más información sobre los parámetros DH y DH.

Los parámetros son solo números primos, no claves. No necesitan ser únicos o secretos, pero tampoco deben ser diseñados especialmente por un atacante. La longitud del bit se refiere al tamaño del prime no es una clave , por lo que no es directamente comparable con RSA. Tenga en cuenta que una clave RSA de 2048 bits se compone de un par de números primos de 1024 bits, por lo que está en el mismo nivel con respecto a la factorización con una primacía DH de 1024 bits frente a una clave RSA de 2048.

Como señala la respuesta de Thomas en el enlace anterior, el número no tiene que ser único ni secreto, y de hecho su biblioteca crypto puede proporcionar un DH primo que funcionará bien (suponiendo que confíe en la fuente de la biblioteca). O puedes generar uno tú mismo.

Detalles adicionales a la luz de los descubrimientos recientes

En primer lugar, el consejo sobre el tamaño primordial sigue siendo en gran medida correcto: 512 es demasiado pequeño, y 1024 es probablemente lo suficientemente bueno (se aplican algunas advertencias) mientras que 2048 es definitivamente seguro.

Además, sin embargo, se demostró un ataque de precomputación tal que, si conoce los números primos con anticipación, puede hacer la mayoría del trabajo de descifrar un intercambio de DH dado de antemano. Es un montón de cálculos y toma una gran cantidad de tiempo calcular todos los vectores posibles para un conjunto dado de números primos, pero si se usa un solo conjunto de números primos en todas partes, entonces hay un incentivo para gastar tiempo y dinero porque el resultado ser tan ampliamente útil.

Esto significa que usar los mismos números primos que todos los demás es una responsabilidad, porque es más probable que su atacante haya realizado la precomputación. Por lo tanto, es probable que desees generar tus propios números primos únicos para mantenerte fuera del grupo de ataques. Además, si usted mismo es un objetivo tan atractivo que un adversario está dispuesto a gastar millones por mes para atacarlo (por ejemplo, objetivos del tamaño de Facebook), entonces puede justificar la rotación de sus números primos con regularidad.

En cuanto al costo y el esfuerzo necesarios para realizar esta precomputación, el trabajo para los primos de 512 bits puede ser realizado por un individuo dedicado, para los primos de 1024 bits por un estado-nación, y los primos de 2048 bits quizás por un avanzado civilización extraterrestre.

    
respondido por el tylerl 14.09.2013 - 04:38
fuente
4

La seguridad de DH se basa en la dureza del logaritmo discreto . Para un primer p elegido al azar, esa dureza aumenta con el tamaño de p , utilizando los algoritmos más conocidos. Por alguna posibilidad semi-monstruosa, sucede que el algoritmo más conocido para logaritmo discreto tiene mucho en común con el mejor algoritmo conocido para la factorización de enteros ( GNFS ) y el mismo costo de ejecución asintótico. Por lo tanto, un módulo principal de 1024 bits para DH proporciona un nivel de seguridad que es aproximadamente equivalente al de una clave RSA de 1024 bits.

Si observamos los detalles, un módulo de 1024 bits es un poco más fuerte que una clave RSA de 1024 bits, porque a través de GNFS para logaritmo discreto y GNFS para factorización son muy similares, su paso final ( el álgebra lineal en una gran matriz) es más difícil para la DL (el cuello de botella es el tamaño de la matriz; para la factorización, los elementos de la matriz son bits individuales, mientras que para la DL son enteros modulo p , es decir, mil veces más grandes) . Hasta la fecha, el RSA-1024 aún no se ha roto, y el DH de 1024 bits aún más.

Sin embargo, romper el DH de 1024 bits no es completamente irreal; se necesitaría una cantidad no despreciable de dólares (miles de millones) y la construcción de una máquina dedicada para fines especiales y el tiempo de funcionamiento aún se contaría en meses o incluso años. Pero eso es factible sin invocar la ayuda de conceptos de ciencia ficción (extraterrestres útiles "muy avanzados") o teología (deidades útiles). En ese sentido, sí, debes tratar de usar un módulo más grande.

No desea utilizar un módulo sobredimensionado porque el costo de la CPU de uso aumenta considerablemente con ese tamaño ( debería aumentarse de forma cuadrada, pero para algunas implementaciones es bastante cúbico, es decir, tiene un costo de 4096 bits 8 veces más que 2048 bits). 2048 bits están bien.

Un problema adicional y bastante desconcertante es que hay algunas implementaciones generalizadas de SSL que no admiten módulos de DH mayores de 1024 bits. Si usa OpenVPN, entonces sabe que tanto el cliente como el servidor son OpenVPN, por lo que no debería tener problemas de interoperabilidad.

El primer p y el generador g no son secretos; También se pueden compartir. Consulte esta respuesta para más detalles. Puede generarlos perfectamente en alguna máquina y usarlos en otra. También puede configurar todos los dispositivos para que utilicen los mismos parámetros DH; esto no implica ningún problema de seguridad adicional.

La generación de los parámetros de DH con OpenSSL puede llevar mucho tiempo porque OpenSSL insiste, sin ninguna razón racional, en la generación de los llamados "primos seguros", es decir, un primer p tal que < em> (p-1) / 2 también es un primo. Esto es una exageración y multiplica el tiempo de generación por un factor enorme (varios cientos). Lo que se necesita para DH es que p es primordial y p = qr + 1 para algunos lo suficientemente grandes como q ; un q de 256 bits ya estaría bastante bien. Ir a un "primer seguro" (es decir, q de tamaño de 1023 bits para un p de 1024 bits) no hace que las cosas sean más seguras, a pesar del nombre (esto es una parte de tradición antigua que se transformó en un mito debido a una terminología deficiente).

Los "primos seguros" tienen una ventaja de rendimiento menor (en el uso, no en la generación) en que permiten el uso de g = 2 como generador; pero esa ventaja es leve (solo importa para la mitad del intercambio de claves DH, y se anula principalmente por optimizaciones basadas en ventanas en la exponenciación modular).

Si realmente desea generar parámetros DH en cada dispositivo (lo que no es útil), puede agregar el indicador " -dsaparam " a la línea de comandos para generar parámetros DH sin insistir en tener "primos seguros":

openssl dhparam -dsaparam -out dh2048.pem 2048

Esto debería ser mucho más rápido. Pero generar los parámetros DH en una PC y simplemente codificarlos en todos sus dispositivos es aún más simple y seguro.

    
respondido por el Tom Leek 04.11.2014 - 20:59
fuente

Lea otras preguntas en las etiquetas