¿Cifrar correctamente usando AES-256 en modo CBC?

Question

¿Cifrar correctamente usando AES-256 en modo CBC?

#1 de Ángel (3 votos)
#2 de dave_thompson_085 (2 votos)

3

Para el propósito de la herramienta Estoy escribiendo actualmente , necesito realizar algún cifrado / descifrado AES en alguna entrada. Es como una tubería: usted alimenta sus datos, ejecuta el algoritmo y lo pasa al siguiente modificador.

Estoy acostumbrado a openssl enc -aes-256-cbc para cifrar y descifrar todo. Mi comprensión de esto es que primero deriva la clave que ingresa usando algún tipo de pbkdf-sha1 con unos 8 bytes generados salt , luego derive el iv del derived key + salt .

Obviamente, solo funciona con OpenSSL ya que no pude encontrar ningún estándar sobre cómo comunicar, o escribir en un archivo, los parámetros iv y salt . Esperaba algún tipo de RFC (como para los parámetros de curva elíptica) pero no hubo suerte.

Mi idea es tener un encabezado de 64 bytes: salt + iv primero en el archivo, luego va seguido por los datos cifrados. Usaré salt con pbkdf2-sha256 para derivar la clave.

Los encabezados no tienen una longitud fija, al ajustar los parámetros correctos al iniciar el programa, se establecerán salt y iv en los valores correctos.

No quiero cometer ningún error. Me sorprendió cómo podría ser el enlace más débil y lo fácil que es recuperar una contraseña de una derivación de clave errónea y / o generación IV.

Estoy bastante seguro de que cada implementación de aes hace rodar su propio protocolo sobre parámetros. Y creo que es triste.

Por supuesto, usaré crypto/aes de Go y su pbkdf2 , tomando siempre la fuente aleatoria de crypto/rand y no math/rand .

Para resumir:

¿Hay algún estándar para tener parámetros AES como salt y iv ?
¿Debo generar el iv o derivarlo del salt || dk ?

EDIT

Olvidé mencionar que iba a utilizar PKCS 5#2.0 que especifica cómo derivar la clave, pero esta pregunta fue más hacia las mejores prácticas en el almacenamiento de iv y salt para una compatibilidad más amplia.

cryptography aes

pregunta tehmoon 28.11.2017 - 23:27

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography aes

¿Los conmutadores de Cisco son vulnerables al salto de VLAN? Verificar la firma S / MIME sin certificado incluido

score 3 · Answer 1

En primer lugar, el salt no es un parámetro AES. Aquí tienes dos primitivas diferentes:

Tendrías:

pbkdf(salt, password) devuelve aes_key
aes(iv, aes_key)

El tamaño IV debe coincidir con el tamaño de bloque que está utilizando (por lo general, de 128 bits, ya que es el estándar, aunque otros tamaños de bloque son posibles ).

Genere un nuevo iv aleatorio para cada archivo que desee cifrar.

Cada implementación de AES debe proporcionar el mismo algoritmo. La forma en que elige guardar los datos en el disco es lo que difiere.

Una solución común sería simplemente agregar todo:

file_password_salt || file_iv || file_contents

Sin embargo, una solución más segura para el futuro incluiría algún parámetro que apunte al tamaño de los campos y al algoritmo utilizado. O, al menos, un número de versión (por ejemplo, v1 PBKDF1 con SHA1 y AES-128, es posible que en unos pocos meses desees usar Argon, con Camellia ...).

Luego, puede decidir utilizar un formato que ya utilizan otras herramientas para que sea compatible con ellas. Por ejemplo, ¿copiar lo que hace OpenSSL (ver esa cadena "SALTADA"?), O hacer que genere un envoltorio zip sobre el contenido de aes.

score 2 · Answer 2

Near cross-dupe enlace

openssl enc deriva tanto la clave como la IV de pw y salt, según pero modificado desde PKCS5 v1 , vea (mi) enlace - pero no tome eso como un ejemplo a seguir.

Además de los CMS basados en ASN.1, que son varios RFC (ver enlace anterior), el formato OpenPGP (con su propia codificación) admite el cifrado basado en contraseña y es RFC 4880 , y los estándares para el cifrado y la firma XML son publicados por w3.org en un proceso abierto similar a los RFC pero no bajo IETF. Tanto PKCS7 / CMS como PGP se diseñaron originalmente para el cifrado de clave pública (realmente una clave pública híbrida más simétrica) y la firma de clave pública (ídem), pero se agregaron opciones para el cifrado basado en contraseña (más simétrico).

Si necesita una operación de canalización / transmisión, será más difícil agregar (o incluir) la autenticación, lo que probablemente lo dejará abierto a ataques activos.