Diffie-Hellman y su uso TLS / SSL

Diffie-Hellman se utiliza en SSL / TLS, como "Diffie-Hellman efímero" (las suites de cifrado con "DHE" en su nombre; consulte el estándar ). Lo que rara vez se encuentra es "Diffie-Hellman estático" (suites de cifrado con "DH" en su nombre, pero ni "DHE" ni "DH_anon"): estas suites de cifrado requieren que el servidor posea un certificado con una clave pública DH en ella, que rara vez se admite por una variedad de razones históricas y económicas, entre las cuales la principal es la disponibilidad de un estándar gratuito para RSA ( PKCS # 1 ) mientras que el estándar correspondiente para Diffie-Hellman ( x9.42 ) cuesta cien dólares, lo cual no es mucho, pero es suficiente para disuadir a la mayoría de los desarrolladores aficionados.

Diffie-Hellman es un protocolo de acuerdo clave , lo que significa que si dos partes (por ejemplo, el cliente SSL y El servidor SSL) ejecuta este protocolo, terminan con un secreto compartido K . Sin embargo, ningún cliente o servidor llega a elegir el valor de K ; desde sus puntos de vista, K se ve generado aleatoriamente. Es secreto (solo ellos saben K ; los que escuchan a escondidas en la línea no) y compartidos (ambos obtienen el mismo valor K ), pero no elegido . Esto no es cifrado. Sin embargo, un K secreto compartido es lo suficientemente bueno para procesar terabytes de datos con un algoritmo de cifrado simétrico (el mismo K para cifrar en un lado y descifrar en el otro), y eso es lo que pasa en SSL.

Sin embargo, existe un conocido algoritmo de cifrado asimétrico llamado RSA. Con RSA, el remitente puede cifrar un mensaje M con la clave pública del destinatario, y el destinatario puede descifrarlo y recuperar M con su clave privada. Esta vez, el remitente puede elegir el contenido M . Entonces, tu pregunta podría ser: en un mundo RSA, ¿por qué nos molestamos con AES? La respuesta está en los siguientes puntos:

• Hay restricciones en M . Si la clave pública del destinatario tiene un tamaño n (en bytes, por ejemplo n = 256 para una clave RSA de 2048 bits), entonces el tamaño máximo de M es n-11 bytes. Para cifrar un mensaje más largo, tendríamos que dividirlo en bloques lo suficientemente pequeños e incluir algún mecanismo de reensamblaje. Nadie sabe realmente cómo hacerlo de forma segura . Tenemos buenas razones para creer que RSA en un solo mensaje es seguro, pero sutiles debilidades pueden estar al acecho en cualquier sistema de división y reensamblado y no nos sentimos cómodos con eso. Ya es suficientemente malo con cifrados simétricos , donde la situación matemática es más simple.

• Incluso si pudiéramos manejar la división y el reensamblaje, habría una expansión de tamaño. Con una clave RSA de 2048 bits, un fragmento de mensaje interno tiene un tamaño máximo de 245 bytes, pero produce, cuando está cifrado, una secuencia de 256 bytes. Esto desperdicia nuestra fuerza vital, es decir, el ancho de banda de la red. El cifrado simétrico solo incurre en una sobrecarga limitada (bueno, SSL agrega una sobrecarga proporcional al tamaño de los datos, pero es mucho más pequeño de lo que ocurriría con un protocolo solo RSA).

• En comparación con AES, RSA es tan lento como el infierno.

• Realmente nos gusta tener la opción de usar protocolos de acuerdo clave como DH en lugar de RSA. En épocas anteriores (antes de 2001), RSA estaba patentada pero no DH, por lo que el gobierno de EE. UU. Recomendaba DH. Hoy en día, queremos poder cambiar los algoritmos en caso de que uno se rompa. Para admitir protocolos de acuerdos clave, necesitamos un cifrado simétrico, por lo que podemos usarlo con RSA. Simplifica la implementación y el análisis del protocolo.

Consulte esta respuesta para obtener una descripción detallada de cómo funciona SSL .

Creo que ep de Security Now. 412 "SSL & Perfect Forward Secrecy" tiene lo que usted quiere.

Tal vez debería buscar leer su transcripción para 'Diffie', porque estos podcasts tienen mucho de noticias / cosas misceláneas antes de que lleguen al punto.

Cotización:

  

Pero muchos navegadores de hoy, y muchos servidores de hoy, admiten lo que se llama Diffie-Hellman Ephemeral, DHE. Efímero significa específicamente "sólo por el momento". Así que esto es DHE, Diffie-Hellman Ephemeral, es una tecnología que está desconectada (y esta es la clave, "desacoplada") de la autenticación del servidor. Y como acabo de decir con Diffie-Hellman, un tercero que observa el intercambio no tiene conocimiento. Esa es exactamente la protección que queremos en nuestras conexiones SSL contra el archivo a largo plazo. El archivado a largo plazo y la posterior revelación de la clave privada del servidor no brindan ninguna ayuda para romper la protección efímera de Diffie-Hellman.

Se refieren específicamente a por qué aún no está en uso completo:

  

Pero Microsoft no ofrece ningún Diffie-Hellman Ephemeral que [...] también tenga RC4, que es el cifrado [...]. Desafortunadamente todos son CBC, Cipher Block Chaining. Y ese es el protocolo de encriptación que es vulnerable al ataque de BESTIA. '

Aquí se refieren a las SSLLabs que describieron en ep. 395 (y 396).