it-swarm-es.com

La implementación de AES Crypt usa una contraseña 8192 veces para generar la clave. ¿Es esto necesario?

Estoy considerando encriptar algunos archivos pequeños (cientos de kb cada uno) usando la implementación de referencia Cripta AES . Mirando la fuente, parece que la clave de cifrado se deriva del IV y la contraseña al concatenar los dos en un búfer que luego se corta en hash repetidamente. Entonces el IV está actuando como la "sal" para el hash. Por repetidamente, quiero decir 8192 veces.

Entiendo que el beneficio de esto es aumentar el tiempo requerido para generar la clave, haciendo que sea más costoso realizar ataques de fuerza bruta para descubrir la contraseña. También entiendo que el inconveniente es que lleva más tiempo realizar las tareas legítimas de cifrado y descifrado para los usuarios reales. Además, como los usuarios y los atacantes compran máquinas más rápidas con el tiempo, el beneficio y el inconveniente tenderán a cero.

Entonces, mi pregunta es, dada la capacidad actual de la computadora, y suponiendo que un atacante motivado que no posee un clúster dedicado, ¿8192 iteraciones son insuficientes, excesivas o "correctas"? Además, me he perdido algo en mi análisis de esta generación clave: ¿hay alguna otra razón para elegir tantas iteraciones que la hagan una buena elección?

16
user185

El estándar de RSA para la criptografía basada en contraseña recomienda "al menos 1000" iteraciones, por lo que el factor parece estar en el estadio.

Con 8192 iteraciones, esencialmente aumenta el tiempo necesario para completar un ataque de fuerza bruta por un factor equivalente a agregar 13 bits de entropía a la contraseña o 2 caracteres alfanuméricos (con respecto a los ataques de fuerza bruta únicamente). Esta es una buena manera de pensarlo porque es independiente del aumento de la potencia computacional.

La pregunta es: dada la seguridad de las contraseñas que usted o sus usuarios usarán, ¿es factible forzarla? Si le agrega 13 bits, ¿es factible aplicarle fuerza bruta?

Si sus usuarios están usando contraseñas seguras, la respuesta es probablemente no a ambas. Si sus usuarios están usando una palabra de diccionario, 13 bits probablemente no sea suficiente para empujarlo a un territorio seguro. Sus respuestas a estas preguntas cambiarán con el tiempo a medida que las computadoras se vuelvan más poderosas.

18
PulpSpy

En caso de que la contraseña sea una palabra del diccionario, las tablas Rainbow se pueden generar de forma rápida y eficiente. Con las contraseñas saladas, aumentan los requisitos de tamaño/tiempo para generar tablas Rainbow útiles. Las iteraciones múltiples de hash (salt + pass) son una manera fácil de disminuir en gran medida la utilidad de las tablas Rainbow. Creo que el esquema MD5 salado de Apache lo hace 1000 veces. El número es completamente arbitrario, solo está elevando significativamente el listón de la cantidad de hardware que tendrías que arrojar al problema para derrotar el mecanismo de hash. Usar un mejor mecanismo de hashing (y eso significa ir más allá de SHA-1, tenga en cuenta que eso ya ni siquiera está en NSA's Suite B ) es una forma. También hay algoritmos que le permiten elegir cuánto tiempo quiere que se demore en hacer algo, que abordaría directamente el 'avance lento de la velocidad de derrota criptográfica' como resultado de la Ley de Moore.

5
Marcin

Si elige paquetes de cifrado, recomendaría GPG o PGP sobre AES Crypt. GPG y PGP han recibido muchas investigaciones cuidadosas de la comunidad de criptografía. Hasta donde yo sé, AES Crypt no lo ha hecho. Por lo tanto, confiaría en GPG o PGP más que en AES Crypt.

En cuanto a la cantidad de veces que se debe iterar el hash de contraseña, eso se basa en cuánto tiempo está dispuesto a esperar durante el cifrado/descifrado y qué tan rápida es la función de hash. Primero, decida cuánto tiempo está dispuesto a esperar: digamos, 100 ms. Luego, elija una serie de iteraciones que harán que el proceso de hash iterado tome 100 ms en las computadoras que usa. Hecho.

Como @PulpSpy ha explicado con precisión , si itera el hashing N veces, esto aumenta la entropía efectiva del secreto en aproximadamente lg (N) bits, donde lg representa el logaritmo de base-2. Por ejemplo, 8192 = 2 ^ 13 iteraciones corresponden a 13 bits más de entropía efectiva. No es fácil traducir esto en una longitud efectiva de frase de contraseña. (Al contrario de lo que escribió @PulpSpy, 13 bits de entropía no se traducen directamente en 2 caracteres, ya que no todos los caracteres de cada frase de contraseña tienen la misma cantidad de entropía. Como explica correctamente @nealmcb, la entropía por carácter de una frase de contraseña varía, pero es probable que normalmente esté en el rango de 1-2 bits por carácter, por lo que esto podría corresponder a un aumento en la longitud de la frase de contraseña en algún lugar cercano a los 8 caracteres).

Por último, le advertiré que elegir su clave criptográfica a partir de una frase de contraseña generalmente se considera una práctica arriesgada. Las frases de contraseña elegidas por humanos a menudo no proporcionan suficiente entropía para proteger contra ataques de fuerza bruta en el cifrado. Por lo tanto, no recomiendo frases de contraseña elegidas por humanos para medidas de alta seguridad (o, si debe usar una frase de contraseña elegida por humanos, use un software que lo ayude a elegir una frase de contraseña de alta entropía). El mejor software criptográfico tiende a utilizar una aleatoriedad verdadera para sus claves criptográficas siempre que sea posible, en lugar de frases de contraseña elegidas por humanos.

3
D.W.

El número de iteraciones debe ajustarse dependiendo de su potencia disponible, de modo que el tiempo de procesamiento aún se ajuste a la difícil restricción de la paciencia limitada del usuario; aún desea que el número sea lo más alto posible.

Con las matemáticas: si procesar una contraseña lleva tiempo [~ # ~] t [~ # ~] en su sistema (por ejemplo, 1 segundo), pero el atacante está listo para gastar T ' para descifrar una contraseña (por ejemplo, 3 semanas) y tiene acceso a máquinas que, en conjunto, son [~ # ~] p [~ # ~] veces más poderoso que el tuyo, entonces el atacante tiene la ventaja de un factor T '* P/T sobre ti. La defensa contra eso es la entropía de la contraseña: si una contraseña tiene entropía e bits, entonces el atacante es (en promedio) derrotado si y solo si T '* P/T <2e-1. Suponiendo [~ # ~] t [~ # ~] = 1 segundo, T ' = 3 semanas, y P = 100 (el atacante tiene cinco PC con alguna GPU, por un presupuesto inferior a 3000 $), luego el la contraseña debe tener entropía de al menos 27.4 bits. Probablemente desee tener un poco de margen de seguridad y optar por 30 bits. Usted puede , como individuo informado, elegir una contraseña que sea más segura que eso (hay un poco de discusión sobre ese tema en esta pregunta ); pero parece bastante optimista esperar que la mayoría de los usuarios también lo hagan.

En las ecuaciones anteriores, el número de iteraciones se usa para alterar [~ # ~] t [~ # ~] . Si bien el número apropiado depende en última instancia de su potencia disponible y paciencia promedio del usuario, es probable que las 8192 iteraciones sean demasiado pequeñas; según su descripción del proceso de transformación de la contraseña (hashing repetido; esto parece una versión reducida de PBKDF2 ), el número de iteraciones en una PC típica debe contarse en millones .

Hablando de eso, una técnica personalizada de procesamiento de contraseña debería ser una fuerte advertencia roja: esto no es bueno. Es mucho mejor confiar en algoritmos estandarizados probados como PBKDF2 o bcrypt (este último debe preferirse ya que reduce el "factor de potencia de procesamiento" [~ # ~ ] p [~ # ~] de un atacante que usa GPU - vea esta respuesta para más detalles).

3
Thomas Pornin

No es "necesario", pero dificulta el descifrado de contraseñas. Se llama "fortalecimiento de clave": es lógicamente como agregar dos caracteres (símbolo de número superior/inferior) al final de la contraseña. Es bastante común. Por ejemplo, el WPA que protege su punto de acceso cambia la contraseña 4000 veces).

2
Robert David Graham