¿Es un buen material de clave efímera Diffie Hellman para ser utilizado como clave de algoritmo de cifrado simétrico?

1

Estoy diseñando un protocolo seguro (con fines académicos / de aprendizaje) y estoy en el punto en el que necesito (re) diseñar el paso de intercambio clave.

En mi implementación anterior, solía confiar en RSA para cifrar y luego firmar un par de claves AES generadas aleatoriamente que luego usaría para el cifrado de tráfico.

Me ha llamado la atención que el uso de Diffie Hellman para el intercambio de claves podría ser mejor para mis necesidades, pero no estoy muy cómodo usando un algoritmo que no entiendo lo suficiente, por lo tanto las preguntas:

Me gustaría usar EC-DHE y leí que la clave generada no fue aleatoria (léase: tiene alguna estructura, supongo que proviene de los conceptos matemáticos subyacentes). Siempre escuché que el uso de claves generadas aleatoriamente fue altamente recomendado para algoritmos de cifrado simétrico. Incluso si tengo la clave DHE resultante, no será "aleatorio". ¿Todavía está bien usarlo para ese propósito?

Entendí (corríjame si me equivoco), que en EC-DHE, la elección de la curva elíptica es básicamente una forma fácil de elegir los parámetros DH. ¿Hay algo que deba tener en cuenta al elegir la curva elíptica? ¿Debo dejar que los usuarios decidan qué EC pueden usar?

    
pregunta ereOn 04.03.2014 - 00:37
fuente

3 respuestas

1

DH (ya sea con curvas elípticas o no) da como resultado un secreto compartido . Ese secreto es un valor numérico con algunas propiedades algebraicas; Sin embargo, todo el secreto está contenido en él. Solo necesitas destilarlo, de la misma manera que conviertes las papas en vodka.

Suponga que está utilizando una curva elíptica de 256 bits, por ejemplo. Curva estándar del P-256 de NIST. Los elementos enviados a través del cable son puntos de curva, cada uno de los cuales es, formalmente, un par de coordenadas (X, Y) en un campo de 256 bits. El resultado de DH es otro punto de la curva y, según el estándar, la coordenada X de ese punto final es el secreto compartido. Es un valor de 256 bits. Con tal curva, se supone que ECDH ofrece "seguridad de 128 bits" (lo que es bueno), por lo que el secreto compartido de alguna manera contiene 128 bits de secreto. Ese secreto se "extiende" sobre los 256 bits reales. Así que también hay espacio para la estructura en ese valor de 256 bits.

El uso de los 256 bits resultantes "tal cual" generalmente se considera imprudente porque no es fácil determinar la extensión de esa estructura adicional, y cómo podría ser explotada externamente. Para convertir estos 256 bits en una secuencia de bits que puede truncar y dividir en claves para AES / HMAC / lo que sea, el método más simple es hacer hash con alguna función hash. Por ejemplo, aplique SHA-256 y obtendrá de nuevo 256 bits, que luego se pueden dividir y usar de manera segura como desee. Para un caso más genérico, use una función de derivación de claves .

En cuanto a la elección de la curva: dado que existen beneficios de rendimiento para codificar la curva exacta en las implementaciones, la mayoría de las bibliotecas existentes solo admitirán un puñado de curvas específicas. En SSL / TLS, cuando se usan curvas elípticas, el cliente envía una lista de designaciones simbólicas para las curvas que admite, y luego el servidor elige una de estas curvas. En la práctica, todo el mundo usa P-256. Por supuesto, en un protocolo personalizado, puede elegir alguna otra curva; incluso podría exigir que se usen curvas arbitrarias , dinámicamente, pero luego tendría que hacer provisiones para enviar los parámetros de la curva, y esto será una carga para las implementaciones ya que la mayoría de las bibliotecas de la CE no ofrecen soporte para curvas arbitrarias.

    
respondido por el Thomas Pornin 24.09.2014 - 13:07
fuente
0

La construcción de curvas elípticas es computacionalmente más costosa que la elección de los parámetros DH. Construir una curva elíptica no es una tarea trivial.

Recomendaría echar un vistazo a la siguiente pregunta y las respuestas: ¿Se pueden usar curvas elípticas personalizadas en implementaciones TLS comunes? .

Como se menciona en ese hilo, es probable que tenga problemas de compatibilidad e implementación si se aleja demasiado de algunas de las 'curvas con nombre' más aceptadas en OpenSSL. No sería práctico permitir que los usuarios especifiquen curvas arbitrarias.

    
respondido por el Lysimachas 26.07.2014 - 12:28
fuente
-1

En primer lugar, DHE / ECDHE permite que dos personas establezcan una clave secreta compartida, pero no se incorpora en la autenticación . Por lo tanto, DHE / ECDHE se debe utilizar junto con las firmas RSA (o DSS), por lo que el valor público transmitido a través del canal de comunicación estará firmado por la clave privada del RSA (o DSS). Para verificar la autenticidad, el destinatario "anulará" la clave pública del remitente.

Como puede ver en el artículo de Wiki para EC-DH, los parámetros serán los definidos son (p, a, b, G, n, h) donde:

  1. p - campo subyacente de la curva elíptica (por ejemplo, campo principal, campo binario
  2. a, b - coeficiente de la curva elíptica
  3. G: punto base de muestra (Gx, Gy)
  4. n - orden de grupo
  5. h - cofactor (donde h = #E (Field_p) / n)

Sin embargo, según mi comprensión de la práctica EC-DH, hay un conjunto de parámetros recomendados para diferentes suites . La referencia se puede encontrar en aquí por NIST.

En general, los parámetros utilizados son decididos por el servidor . Esto generalmente ocurre en el protocolo SSL / TLS.

    
respondido por el edmund2008 04.03.2014 - 06:08
fuente

Lea otras preguntas en las etiquetas