¿Por qué la dh keylength debe coincidir con la longitud rsa en tls?

En el conjunto de cifrado "DHE_RSA", la seguridad es relativa tanto a la ofrecida por Diffie-Hellman como a la ofrecida por RSA. "En general", la seguridad general será la del más débil de los dos; entonces:

• es perjudicial si la clave DH es más débil que la clave RSA, porque entonces se reduce la seguridad general (en comparación con lo que ofrece solo la clave RSA);
• es dañino si la clave DH es más fuerte que la clave RSA, porque no obtiene seguridad adicional real (está limitada por la clave RSA), pero aún tiene que pagar por la clave extra grande (mayor mensajes, mayor costo computacional y pérdida de interoperabilidad con clientes limitados).

Sucede que DH y RSA parecen ofrecer una resistencia similar cuando se usan con claves de tamaños similares, es decir, DH módulo a 1024 bits primo puede decirse que es algo tan fuerte como RSA con un módulo de 1024 bits (pero módulo no primo, por supuesto). Así que esto da la regla de que la clave DH y la clave RSA deben tener la misma longitud.

Cuando miras los detalles, las cosas son menos claras:

• En un conjunto de cifrado DHE_RSA, DH y RSA se utilizan para diferentes propósitos. RSA es para una firma y su objetivo de seguridad se limita al presente. Supongamos que haces una conexión SSL hoy. El atacante lo registra. Luego se dispone a romper la conexión. Cinco años a partir de ahora, después de extensos cálculos y gracias a las mejoras tecnológicas, el atacante logra romper la clave DH: el atacante puede descifrar la conexión registrada y conocer sus secretos. Sin embargo, suponga que en lugar de concentrarse en DH, el atacante rompió la clave RSA del servidor. El atacante entonces ... no tiene nada! Romper la clave RSA le da poder para suplantar al servidor para una futura conexión, pero no le ayudará en nada con el descifrado de las conexiones anteriores. Mientras tanto, renovó el certificado de su servidor al menos una o dos veces, con una nueva clave cada vez, por lo que todos los esfuerzos del atacante fueron en vano.

  Por esta razón, la seguridad de RSA y la seguridad de DH en un conjunto de cifrado "DHE_RSA" no se pueden comparar fácilmente; no tienen el mismo alcance o nivel objetivo, y, en general, la seguridad de RSA es menos importante que la de DH.

• DH y RSA tienen una seguridad comparable para la misma longitud de módulo solo en un sentido aproximado. El mejor algoritmo conocido para romper RSA es el Tamiz de campo de número general , y el mejor algoritmo conocido para romper DH también es GNFS. Sin embargo, para módulo grande (por ejemplo, 1024 bits o más), el cuello de botella de GNFS es la fase de "álgebra lineal", que es la última en el algoritmo: es un cálculo matemáticamente trivial en una matriz de tamaño extremadamente no trivial. Esto es muy difícil de calcular en paralelo y requiere una máquina con una enorme cantidad de RAM muy rápida. De hecho, no existe una computadora que esté a la altura de 1024 bits RSA o DH (se puede imaginar una máquina dedicada sin romper las leyes de la física, pero costaría un centavo bastante).

  Resulta que la variante GNFS que rompe DH tiene el mismo paso de álgebra lineal, pero con una matriz "más grande"; no con más elementos, pero los elementos ahora son enteros modulo p (el módulo principal) en lugar de simples bits. Esto significa que la matriz para romper DH es mil veces más grande (conceptualmente) que la matriz para romper RSA con un tamaño de clave similar. Esto implica que, en la práctica, 1024 bits DH es más difícil de romper que 1024 bits RSA.

  (También en la práctica, 1024 bits DH y 1024 bits RSA no se rompen dentro del contexto económico-tecnológico actual, por lo que cualquier comparación de robustez debe considerarse con un grano de sal; un algoritmo no puede ser menos quebrantado que no quebrantado. )

• No necesariamente puedes elegir el módulo DH como quieras. Las implementaciones existentes pueden ser limitadas, por una variedad de razones históricas. Algunos clientes pueden tener problemas para usar un módulo DH de más de 1024 bits, incluso si no tienen ningún problema con una clave RSA de 2048 bits. La igualdad de solidez y el equilibrio de seguridad son cosas buenas, pero los datos deben fluir de todos modos. El hecho de no establecer una conexión es muy seguro pero no muy útil.

Entonces, si bien un módulo DH sistemático de 2048 bits no afectará a nada en términos de seguridad, y solo incurrirá en gastos generales moderados (sobre un DH de 1024 bits, esto significa 250 a 500 bytes adicionales por apretón de manos completo y algo de CPU adicional, pero nada crítico), puede romper la compatibilidad con los clientes antiguos existentes, por lo que esto requiere pruebas. Al menos, desde el punto de vista del estándar , 2048 bits DH está bien, independientemente del tamaño de cualquier RSA Clave involucrada en la mezcla.

"Obviamente, uno no quiere que DH sea el eslabón más débil de la cadena. Usar AES-256 y solo asegurar el intercambio de claves con DH-512 es estúpido, por supuesto". Exactamente. DH y RSA son diferentes, pero el algoritmo más efectivo para forzarlos es el mismo (vea la respuesta de Tom Leeks), por lo que sus niveles de seguridad son similares. (DH es en realidad un poco más fuerte). Lo más obvio es hacer que tus parámetros DH y tus claves RSA sean del mismo tamaño.

"¿Hay alguna otra razón para hacer coincidir las longitudes de clave?" No, pero ya tienes todos los motivos.

"Especialmente, ¿hay algo en los protocolos que requiera esto?" No, no tienen tienen para coincidir. Puedes hacer lo que quieras. TLS no le importa. De hecho, muchas los sitios web utilizan claves RSA de 2048 bits pero, lamentablemente, siguen utilizando DH de 1024 bits. (Apache reparó esto recientemente, finalmente.)

"Si siempre uso el DH-2048 (y todo lo demás es comparativamente seguro o más débil), ¿esto afectaría algo (excepto el rendimiento)?" Bueno, en una configuración segura, todo lo demás será comparativamente seguro (RSA) o strong (AES). Si estás usando algo más débil, debes parar. :-) Para responder a tu pregunta, sin embargo, creo que estaría bien.

En cuanto al rendimiento, la mayoría de los clientes son compatibles con ECDHE, que no es mucho más lento que no -PFS intercambio de claves . El DHE clásico es significativamente más lento y empeora a medida que aumenta el tamaño del parámetro, pero no hará una gran diferencia si la mayoría de sus clientes no lo usan y su terminador SSL no se está ejecutando sobrecargado.

Tenga en cuenta que algunos clientes, en su mayoría Java, son incompatibles con los parámetros de DH superiores a 1024 bits. Si realmente necesita compatibilidad con ellos, podría tener sentido sacrificar algo de seguridad y usar 1024 bits DH, que todavía es seguro, apenas. Sin embargo, sería mejor resolver el problema de otra manera. Las versiones más nuevas de Java admiten ECDHE, por ejemplo.

Editar: El punto señalado por CodesInChaos y Tom Leek, de que su clave RSA solo tiene que permanecer segura durante un año o dos hasta que caduque su certificado, y romperla solo le permite hacerse pasar por usted, pero que su clave DH tiene que permanecer segura durante décadas, hasta que ya no te importe si tus datos se descifran, es muy bueno. Probablemente sea más importante que lo que dije, así que lo copiaré y lo pegaré aquí. :-D

Editar: Por cierto, advierto contra que excedan 2048 bits. Estarías entrando en un reino de problemas de compatibilidad de clientes menos estudiados. Firefox, por ejemplo, solía tener un límite de alrededor de 2200 bits (en realidad). (Probablemente podrías preguntarle a la comunidad de GnuTLS. Tienen experiencia con DH extraordinariamente grandes).