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.