¿Es la escritura de 'demo' una buena opción para el cifrado de archivos?

4

La utilidad de línea de comando scrypt (ver enlace ) es en realidad solo una demostración del algoritmo de hashing de contraseña de script. p>

Sin embargo, para la simple línea de comandos de cifrado de archivos, me parece que podría ser uno de los más seguros. Todas las utilidades de cifrado simétricas (gpg, openssl, ccrypt) dependen casi totalmente de la seguridad de la contraseña , el cifrado del archivo subyacente es casi irrelevante.

Por lo que puedo decir, la demostración de scrypt utiliza ssl para el cifrado real, ¿puede alguien confirmar esto por cierto?

Por lo tanto, me parece que scrypt es probablemente una buena opción para una herramienta de cifrado de archivos de línea de comandos fácil de usar. Estoy en lo correcto?

    
pregunta Chris Green 08.10.2015 - 11:04
fuente

1 respuesta

1

Antecedentes: el comando scrypt de Tarsnap usa el cifrado AES implementado por su propio jcpc / >. El algoritmo scrypt se utiliza como función de derivación clave .

Lo bueno: el algoritmo scrypt es una de las funciones de derivación de claves más seguras de la forma criptográfica, si no la que conocemos. Esto significa que durante un ataque de fuerza bruta con contraseña, el cálculo de la clave a partir de las posibles contraseñas será muy costoso. scrypt también usa un sal de 32 bytes al crear la clave. De scryptenc.c :

crypto_entropy_read(salt, 32)

Esto ofrece protección contra las tablas del arco iris.

Lo inusual: la implementación de scrypt AES se realiza a través de su propia libcperciva . Esta es una implementación personalizada escrita y nombrada por Colin Percival, el fundador de Tarsnap y autor del algoritmo Scrypt . Si bien las implementaciones de cifrado de cosecha propia generalmente se consideran menos seguras, una implementación scrypt de su autor, un autor bastante famoso, puede ser un contraejemplo. Por lo tanto, debe comparar las ventajas que el autor aporta a la implementación con el hecho de que la biblioteca no se usa comúnmente (es decir, tiene un bajo estadísticas de Github , una falta de visibilidad en OpenHUB , y solo 1K hits en Google ).

Resumen: Está claro que el uso del algoritmo scrypt con una sal fuerte como una función de derivación clave es una estrategia criptográficamente segura. Existe cierto riesgo por el uso de la implementación AES de cosecha propia, aunque esto se ve mitigado por la habilidad de su autor. Te quedan tres opciones que parecen opciones razonables:

  1. Si desea una herramienta de cifrado AES de línea de comandos que utilice la función scrypt para la obtención de claves, puede considerar escribir la suya utilizando una implementación AES bien probada.

  2. Puede usar el algoritmo de estiramiento de la tecla bcrypt , lo que lo hace más seguro al aumentar la longitud de la contraseña aleatoria que usas Esto significa que hay más para recordar, pero proporciona una cantidad de seguridad conocida y medible (en comparación con las incógnitas de libcperciva ).

  3. Puedes confiar en la implementación de Colin Percival y usarla como está. No soñaría con sugerir esto para la mayoría de las personas, pero no estamos hablando de la mayoría de las personas.

Nota: Gracias a @StephenTouset por señalar la notoriedad de Colin Percival.

    
respondido por el Neil Smithline 08.10.2015 - 18:11
fuente

Lea otras preguntas en las etiquetas