Al autenticar ciphertexts, ¿qué debe ser HMACed?

15

Algunos han argumentado para usar AES-256-CTR con HMAC-SHA- 256 para el cifrado autenticado sobre modos específicos de AEAD como EAX y GCM.

Sin embargo, al hacer esto, ¿qué debería ser HMAC? ¿Y cómo? Específicamente:

  1. ¿Debe usarse una clave diferente de la clave de cifrado para firmar los textos cifrados?
  2. Si es así, ¿debería haber una clave de firma única para cada clave de cifrado única?
  3. Si es así, ¿es aceptable que las dos claves se almacenen junto a una otra (por ejemplo, como una clave "virtual" más larga?
  4. ¿Solo el texto cifrado (y los datos asociados opcionales) deben ser HMAC'd?
  5. ¿Debe el nonce ser parte de la HMAC?
  6. ¿Debería la clave encriptación formar parte del HMAC (asumiendo claves de encriptación y firma por separado)?
  7. ¿Cómo deben componerse entre sí el texto cifrado, los datos asociados y, potencialmente, otros componentes del HMAC? ¿Adjuntar? XOR? HMACs anidados?
pregunta Stephen Touset 21.09.2012 - 01:26
fuente

1 respuesta

13

El MAC está allí para detectar la alteración de los datos en los que está interesado, es decir, el resultado del descifrado. Así que tienes la siguiente opción:

  • o bien calcula HMAC sobre los datos de texto sin formato (es decir, antes del cifrado al cifrar, después del descifrado al descifrar);
  • o calcula el HMAC sobre los datos encriptados (es decir, después del cifrado al cifrar, antes del descifrado al descifrar).

En el segundo caso, debe incluir en la entrada HMAC todo que afecte el proceso de descifrado, es decir, no solo el resultado del cifrado en sí, sino también el IV que se utilizó para ese cifrado. y, si el protocolo general admite la agilidad del algoritmo, también debe ingresar la especificación del algoritmo de cifrado (de lo contrario, un atacante podría alterar el encabezado de su mensaje para reemplazar la etiqueta que dice "AES-256" con la etiqueta que dice "AES -128 "y, sin saberlo, descifrarías con el algoritmo incorrecto).

Para seguridad , la segunda opción (cifrar luego MAC) es mejor; vea esta pregunta en crypto.SE para detalles (para resumir, cuando el MAC se calcula sobre los datos encriptados, no puede filtrar información sobre los datos de texto sin formato y, como se verifica antes de intentar descifrar, protege contra los ataques de texto cifrado seleccionados). SSL usa MAC-then-encrypt y ha sido el origen de muchos problemas (todos los "ataques oracle de relleno" y también el llamado ataque BEAST se hubieran evitado con cifrar y luego MAC).

En cuanto a las claves, idealmente, la clave de cifrado y la clave MAC deben derivarse de una clave maestra con una PRF . En palabras sencillas: hash tu clave maestra K con SHA-512; La primera mitad del resultado será la clave de cifrado, la segunda mitad será la clave para HMAC.

Pero, realmente, debe utilizar EAX o GCM . Hacen todo correctamente y (eso es un punto importante) tienen requisitos muy ligeros en la selección IV: solo necesitan un IV no repetitivo, por lo tanto, pueden usar un contador simple, mientras que el CTR hecho a mano necesita rangos IV no superpuestos rangos (una IV con selección aleatoria uniforme es correcta, pero la aleatoriedad es un requisito difícil) (y CBC es aún peor, necesita aleatoriedad impredecible ). La única justificación para no usar EAX o GCM en un sistema nuevo (donde no está limitado por la compatibilidad con versiones anteriores) es una posible no disponibilidad de una implementación de EAX o GCM. Yo diría que, incluso en este caso, sería mejor adaptar un código AES-ECB a una implementación de EAX.

    
respondido por el Thomas Pornin 21.09.2012 - 14:30
fuente

Lea otras preguntas en las etiquetas