¿Puede un usuario verificar la calidad / seguridad de los parámetros de módulos SSH pregenerados?

2

Muchos tutoriales sobre cómo mitigar el Logjam recomiendan regenerando los módulos Diffie-Hellman. Esta es una operación intensiva de recursos, especialmente para grupos de bits altos.

Esto me hizo pensar si tenía sentido construir un pequeño servicio que ofreciera archivos de moduli para descargar, regenerados semanalmente. OpenSSH ofrece una forma de verificar la seguridad de los números primos generados con la opción -T del ssh-keygen util , por lo que un usuario debe poder verificar que los números primos son seguros. Esto lleva mucho menos tiempo que generar una gran cantidad de candidatos y verificar los números primos seguros en ellos.

Ahora mi pregunta es: ¿es este procedimiento realmente suficiente para verificar que un archivo de módulo externo no ha sido "bloqueado" de alguna manera? ¿Podría un atacante poner valores especialmente diseñados allí, permitiéndoles romper el intercambio de claves, sin que un usuario se dé cuenta?

    
pregunta tarleb 13.01.2016 - 10:59
fuente

2 respuestas

1

Gracias a @StackzOfZtuff por los artículos vinculados. Usando esos, esto es lo que he juntado hasta ahora:

Los parámetros generados pueden probablemente ser confiables siempre y cuando se regeneren con frecuencia. Para una mayor seguridad, uno tendría que revisar los parámetros reutilizados, lo que podría ser una señal de que algo sospechoso está sucediendo. Todavía es más seguro generar parámetros en la propia máquina.

Como su nombre indica, los primos seguros funcionan bien al generar grupos DH, ya que garantizan un cierto tamaño del grupo resultante. Por lo tanto, los números primos deliberadamente malos, que resultan en tamaños de grupo reducidos, no son un problema con el esquema descrito en la pregunta.

El único ataque posible que veo es que la entidad generadora podría elegir grupos específicos y precomputar tanto como sea posible para resolver el problema del logaritmo discreto utilizando el tamiz de campo natural . Esto haría mucho más sencillo para un atacante romper cualquier DH que use ese grupo. Naturalmente, el paso de precomputación es computacionalmente costoso, por lo que el atacante querría reutilizar cualquier grupo roto tanto como sea posible. Esto podría detectarse mediante el seguimiento de los grupos anteriores.

En lugar de hacer comprobaciones para grupos recurrentes, probablemente solo sea más sencillo calcular los propios parámetros. El uso de parámetros de DH generados por otros, sin ninguna garantía de nothing-up-my-sleeves , requiere cierta confianza en la entidad que proporciona esos nuevos grupos, independientemente de si los números primos subyacentes son seguros o no.

    
respondido por el tarleb 03.02.2016 - 23:07
fuente
0

Aparte de los riesgos de que los parámetros DH de los grupos puedan ser manipulados, esto tampoco tiene sentido si evalúa los costos para un atacante.

Si asume que alguien con una gran cantidad de poder de computación apunta directamente a su servicio, es de esperar que no utilice los parámetros que acaba de descargar en algún lugar.

Si teme una orientación menos específica, como la NSA probablemente no lo hará, pero si no es demasiado costoso revisar su tráfico, es posible que lo hagan solo para asegurarse de que no es un Commu Terrorista, entonces esto aumentaría el riesgo. Si solo genera parámetros que usa, solo pueden rastrear sus datos. Si usa parámetros que utilizan 10000 personas porque los cambian automáticamente semanalmente, acaba de hacer que la ruptura de estos parámetros sea 10000 veces más valiosa para el atacante .

Entonces, si asumes que x personas usan tus parámetros semanales cambiados, el incentivo para que alguien los rompa es casi igual a los parámetros de ruptura que solo usas pero cambias solo cada x semanas.

Así que simplemente use sus propios parámetros y cámbielos no semanalmente.

    
respondido por el Josef 30.11.2016 - 08:39
fuente

Lea otras preguntas en las etiquetas