Cifrado y HMAC con la misma contraseña

Question

Cifrado y HMAC con la misma contraseña

#1 de Tom Leek (4 votos)

4

Necesito enviar mensajes cifrados autenticados usando una sola contraseña. Reutilizar la misma clave (derivada) para el cifrado de bloque y el HMAC no es una buena práctica, lo sé.

Mi idea inicial es derivar dos claves diferentes de la contraseña para aplicar un esquema de cifrado y luego MAC:

Key1 = PBKDF2 (passwd, SALT1, ITERATIONS1)

Key2 = PBKDF2 (passwd, SALT2, ITERATIONS2)

Deje que M sea el texto simple, el mensaje enviado es:

AES-CTR _Key1 (M) || HMAC-SHA256 _Key2 (AES-CTR _Key1 (M))

SALT1, SALT2, ITERATIONS1, ITERATIONS2 y el IV (contador) también se adjuntan.

¿Encuentra alguna vulnerabilidad en este esquema?

Me parece bien, pero me gustaría saber tu opinión.

Sé que AES en modo CCM (contador con CBC-MAC) es una alternativa.

cryptography encryption aes hmac pbkdf2

pregunta Winston Wolfe 24.10.2014 - 18:30

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption aes hmac pbkdf2

Almacenar la contraseña de un usuario de manera recuperable ¿Cómo cifrar el número de tarjeta de crédito para almacenarlo en la base de datos del servidor SQL de acuerdo con el requisito de PCI DSS?

score 4 · Answer 1

Aquí hay algunas debilidades (la primera es la más seria):

Si no incluye el cifrado IV en la entrada de HMAC, los atacantes podrían modificar el IV e inducir un cambio correspondiente en el mensaje sin ser detectado. Del mismo modo, el atacante podría modificar SALT1 o ITERATIONS1; la HMAC aún coincidiría, pero obtendría basura al descifrarla. Para cifrar y luego MAC, DEBE calcular el MAC sobre todo que contribuye al descifrado. En su descripción, la entrada HMAC debe ser una codificación de una estructura que contenga los datos cifrados en sí, pero también el IV, SALT1, ITERATIONS1 y cualquier identificador simbólico para los algoritmos utilizados (en caso de que quiera hacer algunas provisiones para la agilidad del algoritmo) .
PBKDF2 es una función de hashing de contraseña . Se hace lento con muchas iteraciones. Como la lentitud afecta tanto al atacante como al defensor, no se puede establecer el recuento de iteraciones arbitrariamente alto. En su descripción, el defensor debe usar dos invocaciones PBKDF2 en el uso normal, pagando ambas; mientras que el atacante puede ejecutar su ataque de diccionario en cualquiera de los dos. Entonces, el costo para el defensor es ITERATIONS1 + ITERATIONS2, mientras que el costo para el atacante es solo el menor de los dos. Esto es una ventaja para el atacante.
PBKDF2 no es el mejor en su clase; Se puede ejecutar de manera muy eficiente en una GPU. Bcrypt sería mejor (consulte esta respuesta ).
Confías en que PBKDF2 se comporte como una especie de "oráculo aleatorio" con respecto al valor de sal. Sucede que en el caso de PBKDF2, esto es plausible (PBKDF2 es una cadena de HMAC anidada, comenzando con la sal). Sin embargo, esta no es una propiedad muy estudiada y no puede contar con ella para cualquier esquema de derivación de clave basado en contraseña. Sería más seguro usar los primitivos criptográficos de la forma en que estaban destinados, porque la seguridad proviene del escrutinio, y el uso exótico del algoritmo no ha sido ampliamente revisado por los criptógrafos.

Un mejor esquema ejecutaría una función de hashing de contraseña (por ejemplo, bcrypt), con un sal y un recuento de iteraciones; y luego expandir el resultado con una Función de derivación de claves (una rápida, por ejemplo, < a href="http://tools.ietf.org/html/rfc5869"> HKDF ) en una secuencia de bytes que dividiría en una clave de cifrado y una clave MAC. Esto es, por cierto, cómo se hacen las cosas en SSL. Si tiene prisa y no desea implementar un KDF adicional, en muchos casos puede usar un hash simple: calcular SHA-256 en la salida de bcrypt, que produce 256 bits; Los primeros 128 bits son para el cifrado, la otra mitad para el MAC.

En general, , es preferible utilizar cifrado autenticado . CCM es un intento temprano en un modo AE; Las mejores opciones son EAX y GCM . Este último se está convirtiendo rápidamente en un estándar para tales cosas, y ha sido bendecido por el NIST. Es compatible con SSL / TLS (desde TLS-1.2) y está disponible en algunas bibliotecas generalizadas (por ejemplo, OpenSSL).