¿Es SHA1 / PBKDF2-HMAC-SHA1 indisociable de los datos aleatorios?

3

Quiero asegurarme de que el resultado de PBKDF2-HMAC-SHA1 sea indisociable de los datos aleatorios (dados los parámetros aleatorios). Básicamente, PBKDF2-HMAC-SHA1 parece solo un SHA-1 hash más grande, lo cual es normal dado que la función pseudoaleatoria utilizada es SHA-1 como su nombre indica.

./pkcs5 -i 1 -s RANDOM_SALT -p RANDOM_PAYLOAD -l 20
c8ddde91936a728445e238badde1ef7e94de5b36

Herramienta utilizada: dzmitryk / pkcs5.c

Tenga en cuenta que está impreso en formato HEXADECIMAL, por lo que la salida realmente se ve como datos binarios aleatorios. ¿Existe alguna prueba científica de que SHA-1 no pueda diferenciarse de los datos aleatorios?

& La misma pregunta para SHA-256.

¿Por qué estoy preguntando eso?

Debido a que Plain dm-crypt tiene varias desventajas comparado con LUKS:

  • La contraseña no se puede cambiar sin volver a cifrar todo el disco
  • Solo se puede usar una contraseña
  • La clave de cifrado del disco se deriva de la contraseña sin ningún tipo de sal
  • Una partición de dm-crypt sin formato puede, por casualidad, parecer un sistema de archivos no cifrado, y tiene la posibilidad de ser escrito accidentalmente.

Pero LUKS tiene un defecto importante: es no denegable . Entonces, al tratar de alcanzar este objetivo denegable, las personas usan claves USB con archivos de clave no cifrados (horrible) o encabezados LUKS separados (no se pueden negar si el oponente encuentra la clave USB ...). Hay algo malo en esos enfoques.

Así que estoy tratando de mantener lo mejor de encabezado LUKS y hacer un "No es NO LUKS " encabezado que sería indisociable de los datos aleatorios (por lo tanto, no se puede usar), que contiene solo:

  • Las cargas clave de claves encriptadas LUKS encriptadas - resultado de AES tan aleatorio
  • Las sales LUKS - puro aleatorio
  • El resumen de la clave maestra LUKS - resultado de en PBKDF2-HMAC-SHA1

Todo lo demás (modo de cifrado, longitud de clave, etc.) usaría los valores predeterminados para ser codificado en el comando GRUB cryptomount o fácilmente parametrizable desde la línea de comandos.

EDITAR: Preguntas relacionadas sobre la criptografía StackExchange:

pregunta KrisWebDev 02.04.2016 - 01:04
fuente

1 respuesta

4

¿Hay alguna prueba científica, lo que significa información teórica segura? No, sin embargo, no existe una forma conocida para distinguir la salida de un buen hash criptográficamente seguro de datos aleatorios de la misma longitud. Alguien puede adivinar que algo es SHA-1 si es de 160 bits, porque la mayoría de los fragmentos de 160 bits de apariencia aleatoria tienden a ser compendios de SHA-1, o algunas veces RIPEMD-160, pero no tiene nada que ver con el contenido del digerir, sólo el tamaño.

Tenga en cuenta que en el futuro, es posible que se descubran nuevas técnicas matemáticas (¿se inventaron?) que encuentran un sesgo en los resúmenes SHA-1 o SHA-256. Puede variar desde tan académico como para ser casi tonto ("después de 10 91 plaintexts conocidos, luego con 10 91 operaciones y 10 91 memoria, puede calcular lo que será el sexto bit con una probabilidad 0.05% mayor que la posibilidad ") de ser absolutamente devastador (" se puede lograr un ataque previo a la imagen en SHA-256 con un valor de $ 5000 en hardware de consumo y un programa de 300 líneas C en un par de semanas "). Si bien obviamente esto último es mucho menos probable, ambos pueden suceder. Simplemente no podemos saber cuál será y no tenemos forma de predecirlo. Sin embargo, es probable que pueda estar seguro sabiendo que para la gran mayoría de los ataques de distinguibilidad de aleatoriedad (la capacidad de determinar cuándo los datos pseudoaleatorios no son realmente aleatorios) requiere un número realmente vasto de muestras, probablemente mucho más de lo que desea Cifre siempre en su vida.

Hay algunas excepciones, como RC4 que tiene un sesgo en los primeros bits, sistemas de cifrado con un tamaño de bloque de 64 bits como Blowfish y CAST5 que muestran una capacidad de distinción después de varios gigabytes, y sistemas de cifrado en modo xts-plain que toman una Algunos terabytes de datos se cifran con la misma clave para causar problemas, pero no son la regla.

Si aún está preocupado, debe saber que el kernel de Linux, que se basa en la seguridad de miles de millones de dispositivos en todo el mundo, genera aleatoriedad al mezclar un grupo con SHA-1 y exportar los valores hash a /dev/random y /dev/urandom , los cuales producen datos aleatorios excepcionalmente de alta calidad. Si SHA-1 no fuera extremadamente confiable, no se usaría de manera ubicua (tenga en cuenta que el SHA-1 que se encuentra al final de su vida útil para la protección contra colisiones en certificados no tiene ningún efecto sobre su capacidad de parecer aleatorio). En caso de que se lo pregunte, no hay ninguna razón de seguridad que utilice la mezcla hash en lugar de un cifrado de flujo. Usó SHA-1 para sortear leyes de restricción de exportaciones ahora obsoletas, y simplemente se atascó. Otros sistemas como OSX y FreeBSD usan Yarrow, OpenBSD usa ChaCha20, etc., pero SHA-1 es igual de seguro, por lo que sabemos. ¡Sólo mucho más lento para mezclar!

¿Por qué no solo usas TrueCrypt? Admite la negación plausible, que parece ser lo que está buscando, y tanto cryptsetup como el criptomontaje de GRUB2 lo soportan. Cryptsetup lo convierte de forma nativa en mapeos dm-crypt, al igual que LUKS.

    
respondido por el forest 02.04.2016 - 02:20
fuente

Lea otras preguntas en las etiquetas