Decidí encriptar mi partición raíz con LUKS + LVM.
Mi configuración de ThinkPad:
- Samsung 830 128GB SSD
- Disco duro de 750 GB
- Core 2 Duo 2,5 GHz P9500
- 8 GB de RAM
Pero cuanto más leo, menos entiendo sobre esos dos temas siguientes:
1a. El cifrado
Iba a usar SHA1 en lugar de 2/512 (como algunos sugieren), debido a esa cita de las cryptsetuppreguntas frecuentes:
5.20 ¡LUKS está roto! ¡Utiliza SHA-1!
No, no es. SHA-1 se rompe (académicamente) por encontrar colisiones, pero no por usarlo en una función de derivación de clave. Y esa vulnerabilidad de colisión es solo para uso no iterado. Y necesita el valor hash literalmente.
Esto básicamente significa que si ya tiene una clave de ranura y ha establecido el recuento de iteraciones PBKDF2 en 1 (normalmente es> 10'000), podría (tal vez) derivar una frase de contraseña diferente que le da la misma ranura. llave. Pero si tiene la llave de ranura, ya puede desbloquear la ranura de llave y obtener la llave maestra, rompiendo todo. Básicamente, esta vulnerabilidad SHA-1 le permite abrir un contenedor LUKS con gran esfuerzo cuando ya lo tiene abierto.
El verdadero problema aquí es que las personas no entienden las criptomonedas y afirman que las cosas están rotas solo porque se utiliza algún mecanismo que se ha roto para un uso diferente específico. La forma en que se usa el mecanismo es muy importante. Un hash roto para un uso puede ser completamente seguro para otros usos y aquí está.
Lo que leí como "no tiene sentido usar nada más que SHA-1". Pero algunas personas me dicen que no es exactamente así. Entonces ya no sé qué pensar.
1b.
Además, no pude encontrar ninguna información sobre si el cifrado tiene alguna influencia en el rendimiento de lectura / escritura / búsqueda del disco una vez que el disco está desbloqueado y el sistema ha iniciado sesión.
Entonces, ¿la complejidad del cifrado afecta solo el "rendimiento" en la etapa de ingreso de contraseña, o también durante el uso normal del sistema?
2. El algoritmo
He estado leyendo sobre esto desde hace un par de días, pero cuanto más leo, más me confundo. Todo lo que leo dice que AES es el más rápido y Serpent es el más lento. Pero no según mi laptop:
$ cryptsetup benchmark
Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 344926 iterations per second
PBKDF2-sha256 198593 iterations per second
PBKDF2-sha512 129007 iterations per second
PBKDF2-ripemd160 271933 iterations per second
PBKDF2-whirlpool 134295 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 149.8 MiB/s 147.9 MiB/s
serpent-cbc 128b 51.0 MiB/s 196.4 MiB/s
twofish-cbc 128b 127.6 MiB/s 152.5 MiB/s
aes-cbc 256b 114.3 MiB/s 113.8 MiB/s
serpent-cbc 256b 51.2 MiB/s 198.9 MiB/s
twofish-cbc 256b 129.8 MiB/s 167.5 MiB/s
aes-xts 256b 153.3 MiB/s 150.6 MiB/s
serpent-xts 256b 176.4 MiB/s 184.1 MiB/s
twofish-xts 256b 160.8 MiB/s 159.8 MiB/s
aes-xts 512b 115.4 MiB/s 112.1 MiB/s
serpent-xts 512b 178.6 MiB/s 184.2 MiB/s
twofish-xts 512b 160.7 MiB/s 158.9 MiB/s
Entonces parece que Serpent no solo es el más rápido, sino que además es el más rápido con la clave más compleja.
¿No debería ser al revés? ¿Lo estoy leyendo mal o algo así?
fuente
Respuestas:
1a: realmente no importa tanto. cualquiera que sea el hash que utilices para la función de derivación de clave, LUKS se asegura de que sea computacionalmente costoso. Simplemente lo repetirá hasta que haya pasado 1 segundo en tiempo real.
1b: el método de derivación clave no influye en el rendimiento. el cifrado sí lo hace.
cryptsetup benchmarkte lo muestra2 - AES es el más rápido si su CPU es lo suficientemente moderna como para admitir instrucciones AES-NI (aceleración de hardware para AES). Si va con la serpiente ahora, es posible que no pueda utilizar el AES-NI de su próxima computadora portátil.
Tenga en cuenta que este punto de referencia no usa almacenamiento, por lo que debe verificar estos resultados con cualquier almacenamiento y sistema de archivos que realmente vaya a usar.
fuente