¿Por qué se reutilizan los números primos en los intercambios de claves Diffie-Hellman?

Question

¿Por qué se reutilizan los números primos en los intercambios de claves Diffie-Hellman?

#1 de Makif (1 votos)
#2 de Mortesil (0 votos)

1

Al leer sobre el ataque Logjam , aprendí que los intercambios de Diffie-Hellman a menudo * dependen de la misma clave particular de 1024 bits . Entiendo que cuando se inventó DH, incluso las claves de 512 bits se consideraron seguras durante las próximas décadas. Pero, ¿nunca se les ocurrió a los diseñadores, oa muchos de los programadores que han trabajado en implementaciones de DH a lo largo de los años, que reutilizar los mismos números primarios podría conducir a una vulnerabilidad final (catastrófica)?

¿Me estoy perdiendo algo con la dificultad computacional? Generar su propio p y g una vez, en la configuración inicial del servicio, debería ser suficiente y debería garantizar la inmunidad de cualquier falla con los números primos estandarizados.

*: como en, dos tercios de las implementaciones mundiales actuales a menudo.

attacks cryptography vulnerability diffie-hellman

pregunta detuur 12.07.2016 - 21:52

fuente

2 respuestas

Lea otras preguntas en las etiquetas attacks cryptography vulnerability diffie-hellman

¿Conviértase en administrador de dominio controlando una OU en Active Directory? Seguridad de un servidor de respaldo

score 1 · Answer 1

Puede ver las siguientes preguntas sobre las dificultades para generar sus propios parámetros de cambio de clave DH y también usar los parámetros estándar de grupo DH: ¿Es más seguro generar sus propios números primos Diffie-Hellman o usar los definidos en RFC 3526? y ¿Dónde hago? ¿Obtener números primos para Diffie-Hellman? ¿Puedo usarlos dos veces?

Para Diffie-Hellman simple, lo que necesitas es p , q y g , como   que:


p es un número primo suficientemente grande (2048 bits son más que suficientes hoy en día);

q es más pequeño, pero aún lo suficientemente grande (por ejemplo, 256 bits), valor principal que divide p-1 ;

g es un generador de un subgrupo módulo p con un pedido que es un múltiplo de q .

En la mayoría de las situaciones, no es fácil, y tampoco es aplicable, crear un grupo de intercambio de claves DH antes de que se produzca el intercambio de claves real. Tenga en cuenta que, logjam explota los primos pequeños utilizados en los grupos DH (512 bits). Creo que, debería estar seguro si usa un grupo DH con una p de 2048 bits, incluso si otros también usan el grupo.

score 0 · Answer 2

El número de dos tercios al que se refiere es específico de los servidores VPN que usan IPsec. Apostaría a adivinar que esto es un resultado de que los administradores y las personas de seguridad de Sys no se toman el tiempo de modificar más la configuración predeterminada en su servidor de lo que es absolutamente necesario durante la configuración.

O bien, podría ser un problema con la implementación específica de IPsec, ya que corresponde a un subconjunto específico de servidores VPN, por ejemplo, si esos dos tercios es la forma en que Cisco lo implementa en sus dispositivos VPN o ASA (ya que son probablemente el líder mundial en VPN implementadas por hardware), o cómo alguna versión de Linux lo implementó en sus compilaciones de servidor, o Windows Server, etc. En cualquier caso, parece que puede ser más un problema de implementación que un problema real con DH o IPsec en sí mismo, ya que ambos han sido examinados exhaustivamente por los especialistas en seguridad y criptografía durante años. DH es solo el algoritmo, siempre que se suministre con un número primo de X bits, el algoritmo realizará su trabajo. IPsec es un framework usado para implementar seguridad. La implementación es lo que realmente elige y suministra el número primo al algoritmo, a través del marco.