¿Cuáles son las implicaciones de usar los mismos parámetros DH en un servidor TLS?

6

Para un cifrado DHE, nginx codifica los parámetros Diffie-Hellman para que utilicen la base 2 y un cebado fijo de 1024 bits si no se configuran parámetros DH personalizados.

Estos parámetros son públicos (enviados en texto sin formato en el mensaje TLS ServerKeyExchange), ¿el hecho de cambiar el valor principal aumenta de alguna manera la seguridad de la conexión TLS? Me interesa el efecto de tener diferentes números primos, no el número de bits.

¿Hay otros efectos secundarios de cambiar los parámetros de DH, como problemas de compatibilidad con los clientes? ( Apache habla de problemas resultantes del uso de números primos más grandes en Java 7 y versiones anteriores , pero no puedo reproducirlos esto en OpenJDK 1.7.0_40.)

    
pregunta Lekensteyn 04.10.2013 - 18:15
fuente

2 respuestas

7

No se conoce ningún efecto secundario malo al compartir los mismos parámetros DH con otras personas / servidores. De hecho, este es el caso común en curva elíptica DH, ya que generar su propia curva es sustancialmente más difícil que generar su propio módulo principal para DH clásico, y la implementación habitual de curvas elípticas está vinculada a un determinado curva o un pequeño conjunto de curvas (porque es más fácil y más eficiente escribir de esa manera).

Ha habido cierta preocupación teórica acerca de cómo un atacante podría invertir mucho trabajo en "romper" logaritmo discreto módulo un cebado específico y luego reutilizando los cálculos intermedios para romper rápidamente muchas instancias de DH que funcionan en módulo ese cebado específico. En ese sentido, la reutilización de parámetros DH comunes puede implicar un poder adicional de molestia para el atacante. Pero este tipo de costo compartido no funciona para todos los algoritmos de ruptura de DL, y esto también supone que el atacante podría romper DL modulo el primo, es decir, que el primo era demasiado corto o "forma especial". Esta sería una razón mucho más urgente para no usar ese primer: no es que sea compartido , sino que es débil .

Por lo tanto, el uso de parámetros DH compartidos existentes no es un problema, siempre y cuando pueda asegurarse de que dichos parámetros no hayan sido "cocinados" especialmente para permitir una interrupción más rápida. Esto generalmente significa que el algoritmo de generación se ha especificado completamente y se puede verificar que se haya seguido fielmente (por ejemplo, vea estos ).

El uso de parámetros DH personalizados debe funcionar con todos los clientes, ya que no existe una ventaja de implementación para vincular una implementación a un módulo específico (al contrario de las curvas elípticas). Siempre que su módulo se ajuste a los requisitos de tamaño de una implementación específica, las cosas deberían estar bien (algunas implementaciones antiguas tienen problemas con tamaños que superan los 1024 bits; a otras no les gustará un módulo cuyo tamaño no sea un múltiplo de 32 o 64 bits ).

    
respondido por el Thomas Pornin 04.10.2013 - 18:26
fuente
5

Los números primos de 1024 bits están dentro del rango de cómputo para ser vulnerables a los ataques de precomputación de actores a nivel estatal.

enlace describe el problema y también el ataque de degradación del problema que se menciona en los comentarios sobre esta pregunta.

    
respondido por el Senji 22.10.2015 - 15:09
fuente

Lea otras preguntas en las etiquetas