¿Por qué se definieron los conjuntos de códigos CBC_SHA256 como TLS_RSA_WITH_AES_128_CBC_SHA256?

3

Tengo entendido que:

  1. En TLS, la función hash solo se usa en la construcción HMAC.
  2. SHA-1 es seguro cuando se usa en HMAC.
  3. TLS 1.2 cambió el PRF utilizado para derivar las claves simétricas a no más débil que SHA-2, independientemente del conjunto de cifrado, por lo tanto, en TLS 1.2, la función hash nombrada en el conjunto de cifrado se usa solo para HMAC durante la transferencia de datos en masa.
  4. TLS_RSA_WITH_AES_128_CBC_SHA256 no parece más seguro que TLS_RSA_WITH_AES_128_CBC_SHA, pero tiene más sobrecarga de ancho de banda (12 bytes adicionales en cada registro, que puede tener hasta 16 KB de longitud).

¿Es correcto lo anterior? ¿Cuál fue la justificación para definir los conjuntos de cifrados SHA-2 de CBC en TLS 1.2? ¿Fue una cobertura contra la ruptura catastrófica de HMAC_SHA1 pero de tal manera que deja intacto a HMAC_SHA256?

Si mi análisis es correcto, ¿significa que no tiene sentido apoyar a TLS_RSA_WITH_AES_128_CBC_SHA256? ¿Es este el razonamiento detrás de Android 5 y Golang que no admite CBC_SHA256?

Nota: sé sobre PFS y AEAD, esta es una pregunta sobre los méritos de CBC_SHA256 frente a CBC_SHA.

    
pregunta Z.T. 22.03.2015 - 00:40
fuente

1 respuesta

1

He leído el historial del trabajo en esta parte de la especificación TLS.

Eric Rescorla (coeditor de TLS 1.1, 1.2 y 1.3) publicado el 31 de diciembre de 2007 en la lista de correo del grupo de trabajo IETF TLS sobre un elemento de trabajo denominado "Número 66: conjuntos de cifrados basados en HMAC-256" para el próximo borrador de TLS 1.2 (denominado RFC4346-bis, es decir, una revisión de TLS 1.1, ahora conocido como RFC 5246).

El creador de la idea es desconocido.

La razón para agregar las nuevas suites de cifrado es porque es extraño que TLS 1.2 cambie el PRF a SHA-256 y luego no permita que SHA-256 para la autenticación de encriptación masiva.

La idea fue apoyada por Uri Blumenthal (MIT Lincoln Lab) diciendo que SHA-1 tiene puntos débiles y que no hay necesidad de esperar a que se rompa antes de definir los reemplazos.

Nikos Mavrogiannopoulos (autor de GnuTLS) apoyó la idea de igualar la fuerza criptográfica de los primitivos (especialmente de AES-256).

Pasi Eronen (Nokia, muchos trabajos sobre EAP) sugirió los nombres de algunas de las nuevas suites de cifrado.

Luego se habló sobre el tamaño correcto de la función hash para que coincida con cada cifra entre MIURA Fumiaki (Nippon Telegraph y Telephone), Florian Weimer (BFK, Red Hat, recientemente trabajó en la reparación de Shellshock), Ken Peirce, quien sugirió use la métrica de "bits de seguridad" de NIST para resolver el dilema, Jeffrey A. Williams y Bodo Möller (recientemente trabajado en la reparación de Heartbleed) que proporcionaron enlaces y explicaciones de que la "seguridad de MAC de 128 bits debería ser perfectamente adecuada incluso para aplicaciones que requieren 256 bits seguridad de encriptación ".

La especificación de TLS se actualizó (presumiblemente por Eric Rescorla) con las nuevas suites de cifrado y se publicó en draft 8 que salió a la venta el 25 de enero de 2008.

El registro de cambios del borrador 8 se lee, en parte: "Se agregó soporte para los conjuntos de cifrado SHA256", sin justificación.

En la versión final de la especificación, en la lista de cambios desde TLS 1.1, dice "Conjuntos de cifrado HMAC-SHA256 agregados", de nuevo, sin fundamento. La lista de conjuntos de cifrado en el apéndice C se mantuvo sin cambios desde el borrador 8.

    
respondido por el Z.T. 13.04.2015 - 23:58
fuente

Lea otras preguntas en las etiquetas