Elección de una clave de cifrado de la salida de Diffie-Hellman

Question

Implementé Diffie–Hellman key exchange en Java con algunos grupos grandes desde RFC 3526. Mi salida es una gran cantidad de bytes. ¿Es seguro usar los primeros 448 bits (56 bytes) de la salida para una clave blowfish? ¿Debo transformar los bytes de alguna manera o elegir cualquier byte específico para la clave?

Answer 1

Desde un punto de vista teórico, no, no es seguro. No es que pudiera identificar un ataque real; pero la salida de un intercambio de claves Diffie-Hellman es un elemento de un grupo que consiste en elementos q y ofrece sqrt (q) seguridad como máximo. Truncar partes de la codificación de ese elemento no parece una buena idea ...

La forma "correcta" es usar una función de derivación de tecla unidireccional. En palabras simples, procese la salida Diffie-Hellman con una buena función hash como SHA-256 y use el resultado hash como clave. El tiempo Hashing será insignificante con respecto al paso Diffie-Hellman. Java ya incluye implementaciones finas de SHA-256 y SHA-512, y si buscas compatibilidad con implementaciones Java muy antiguas (por ejemplo, la JVM de Microsoft que viene con Internet Explorer 5.5), entonces puedes usar una implementación Java independiente de SHA-2 como el de sphlib. O posiblemente lo reimplemente de la especificación (eso no es difícil): FIPS 180-3 (a PDF file).

Si necesita más de 128 bits para su clave, esto significa que es un viajero en el tiempo desde el año 2050 más o menos; 128 bits son (mucho) más que suficientes para protegerlo por el momento, suponiendo que utiliza un esquema de cifrado simétrico adecuado.

Hablando de eso: Blowfish ya no se recomienda. Tiene bloques de 64 bits, lo que implica problemas cuando la longitud de los datos cifrados alcanza unos pocos gigabytes, un tamaño que no es tan grande hoy en día. Sería mejor utilizar un cifrado de bloque de 128 bits como AES. Además, en cualquier sistema de cifrado simétrico serio, necesitará una verificación de integridad con clave. Esto se puede hacer con un MAC (Código de Autenticación de Mensajes) como HMAC, construido sobre una función hash (luego, fácil de implementar, y hay una implementación Java en sphlib). O, mejor aún, use el AES en un modo combinado de encriptación/MAC que manejará los detalles engañosos para usted (porque el uso de un cifrado de bloque correctamente es no fácil); búsqueda CWC y GCM (ambas están libres de patentes, esta última ha sido aprobada por el NIST).

Answer 2

La solución que usted propone depende de si los bits más significativos de un intercambio de Diffie-Hellman son núcleo duro. Se conocen algunos pequeños resultados que muestran que los bits más significativos son impredecibles, pero no conozco un documento lo suficientemente fuerte como para mostrar que su enfoque es correcto.

Sin embargo, hay varias propuestas para obtener una clave de las claves Diffie-Hellman. P. ej. un buen documento es NIST SP 800-135. Hasta ahora, esto es solo un borrador y se puede encontrar en here. Sin embargo, revisa algunos estándares existentes. Por supuesto, usar un estándar siempre es preferible para desarrollarlo usted mismo.

Si bien la propuesta de Thomas Pornin parece razonable, no deja de ser una solución ad hoc. Y para estar seguro no deberías usarlo. Más bien usaría algo que se ha analizado (por ejemplo, el uso del esquema de derivación de claves en TLS versión 1.2).