¿Qué tan seguro es mi software para el cifrado de archivos con AES-256?

Question

¿Qué tan seguro es mi software para el cifrado de archivos con AES-256?

#1 de SEJPM (6 votos)

4

Estoy trabajando en un proyecto para crear software para el cifrado de archivos con AES en Java, su funcionamiento es bastante simple, pero me preguntaba si es realmente seguro.

El programa solicita al usuario una frase de contraseña para cifrar el archivo seleccionado, después de ingresar la frase de contraseña, se asegura con una función de derivación de claves PBKDF2 Con Hmac-SHA256, salt es un generador de números pseudoaleatorios para 8-byte SHA1 PRNG , las iteraciones son 100,000 y longitud de la clave es de 256 bits.

La clave segura generada se utiliza para cifrar el archivo. El vector de inicialización para el AES es un generador de números pseudoaleatorios de 16 byte SHA1 PRNG , el archivo ahora está cifrado.

Los primeros 16 bytes del archivo encriptado se guardan en el IV y durante los últimos 8 bytes para almacenar la sal de PBKDF2.

El salt y IV no se cifran junto con los archivos, pero se agregan más adelante. ¿Estas operaciones son seguras?

java aes file-encryption sha256 pbkdf2

pregunta Thealexzava 02.03.2016 - 14:18

fuente

1 respuesta

Lea otras preguntas en las etiquetas java aes file-encryption sha256 pbkdf2

¿Alguna vez puede obtener datos descifrados parcialmente de un algoritmo de descifrado? ¿Cuál sería un ejemplo simple de una función de encriptación asimétrica (función asimétrica)?

score 6 · Accepted Answer

Primero: Por favor, no lance su propio criptográfico.

Si está haciendo esto con fines de producción, le recomiendo encarecidamente que no lo use. Si desea mejorar sus habilidades de programación o este es un proyecto de investigación similar, está bien siempre y cuando no espere una gran seguridad (profesional) de él.

Ahora, a los puntos reales que se pueden mejorar en lo que dio aquí (en orden de aparición en la publicación):

PKCS # 5 PBKDF2 con HMAC - SHA-256 . Por favor. PBKDF2 es un antiguo estándar para derivación de clave basada en contraseña y debe reemplazarse por al menos bcrypt o aún mejor Argon2 . Consulte también nuestra respuesta canónica sobre el hashing de contraseñas .
100.000 iteraciones . Por favor, no codifique la cantidad de iteraciones, sino que la encuentre dinámicamente en tiempo de ejecución, dependiendo de lo que pueda hacer la CPU. Esto es especialmente cierto si no conoce su plataforma de destino exacta y si su software estará disponible durante algún tiempo. TrueCrypt también se refirió a este problema.
8 bytes salt . Si bien una sal de 8 bytes (= 64 bits) puede estar bien, una sal de 16 bytes (= 128 bits) es una mejor opción, para evitar ataques de precálculo en el rango limitado de sales.
SHA-1 -PRNG . No has dado ningún detalle sobre este. Esto se ve bien, pero debería actualizar si es posible (a SHA-256 o SHA-3 ), para evitar SHA -1, que aún está bien para ejecutar un PRNG, pero puede iluminar mal su herramienta para usar una herramienta antigua y " roto ".
16 bytes IV para AES . Tenga en cuenta que esta es la opción adecuada para CBC, CFB, CTR, OFB, ... (es decir, todos los modos de cifrado no autenticados ) por lo general, no es la opción adecuada para los modos de cifrado autenticados que requieren una fuente de 12 bytes para una seguridad óptima. Si puede garantizar claves únicas (lo que parece que puede), puede dejar que el valor predeterminado de nonce sea todo a cero.
AES / CBC / PKCS5Padding . Esta sería una buena opción (¡no es una buena!) Si tuviera algún medio para autenticar el mensaje (es decir, confirme que no se haya manipulado). No es así, por lo que la mejor opción sería utilizar un esquema de cifrado autenticado como AES-GCM , AES-CCM , AES-EAX , ...
Los datos asociados (sal + IV) . Primero, puede dejar que el valor predeterminado de IV a algún valor (¿todo cero?) Si los archivos permanecen pequeños (menos de 68 GB) y use AES-GCM. En segundo lugar, debe autenticar estos datos como "datos asociados" y agregar una etiqueta de autenticación (sin cifrar) al final del archivo (las bibliotecas decentes lo harán automáticamente). Si utilizara esto en su estado actual, un atacante (que conoce el primer bloqueo) podría cambiar la IV para que el usuario legítimo descifre un texto simple a elección del atacante. Además, desearía agregar los parámetros de derivación clave (como recuentos de iteraciones, parámetros de tiempo y espacio y otra configuración) a sus datos asociados para garantizar la adaptabilidad a largo plazo del formato.