¿Cómo determino qué cifrados y modos de cifrado puedo usar en dm-crypt / LUKS?

Estoy usando un sistema basado en Ubuntu, y tengo dificultades para determinar qué cifrados y modos de cifrado están disponibles para mí.

La página del manual cryptsetup dice:

"Consulte / proc / crypto para obtener una lista de las opciones disponibles. Es posible que deba cargar módulos criptográficos de kernel adicionales para obtener más opciones".

Mi / proc / crypto tiene muy poco. ¿Cómo averiguo qué módulos criptográficos de kernel adicionales están disponibles para cargar?

Hay muchos, muchos documentos y páginas de manual para leer, pero un documento que puede interesarle particularmente es la Especificación de formato en disco (PDF) de LUKS .

El apéndice B (que, naturalmente, está cerca del final) dice:

Registro de especificación de cifrado y hash

Incluso si los cifrado de renombre y cifrado en modo de cadenas no son interpretados por cualquier operación LUKS, deben tener el mismo significado para todas las implementaciones para lograr la compatibilidad entre diferentes implementaciones basadas en LUKS. LUKS tiene que asegurarse de que el sistema de cifrado subyacente pueda utilizar el nombre de cifrado y las cadenas de modo de cifrado, y como estas cadenas no siempre son nativas del sistema de cifrado, LUKS podría necesitar asignarlas en algo apropiado.

Los nombres de cifrado válidos se enumeran en la Tabla 1.

Los modos de cifrado válidos se enumeran en la Tabla 2. Por contrato, los modos de cifrado que usan IV y ajustes deben comenzar desde el IV / ajuste todo cero. Esto se aplica a todas las llamadas a las primitivas cifrar / descifrar, especialmente cuando se maneja material clave. Además, estos modos de cifrado de IV / ajustes generalmente cortan la secuencia de cifrado en bloques independientes al volver a colocar los ajustes / IV en los límites del sector. El requisito de IV / ajuste todo cero para el primer bloque cifrado / descifrado es equivalente al requisito de que el primer bloque esté definido para descansar en el sector 0.

La Tabla 3 enumera las especificaciones hash válidas para el campo hash-spec . Una implementación compatible no tiene que admitir todas las especificaciones de cifrado, modo de cifrado o hash.

Tabla 1: nombres de cifrado válidos

• aes - Estándar de cifrado avanzado - FIPS PUB 197
• twofish - Twofish: un cifrado de bloque de 128 bits - http://www.schneier.com/paper-twofish-paper.html     (ver más abajo)
• serpiente - http://www.cl.cam.ac.uk/~rja14/serpent.html
• cast5 - RFC 2144
• cast6 - RFC 2612

Tabla 2: modos de cifrado válidos

• ecb: la salida de cifrado se usa directamente
• cbc-plain: el cifrado funciona en modo CBC. El encadenamiento CBC se corta en cada sector y se reinicializa con el número de sector como vector inicial (convertido a 32 bits y little endian). Este modo se especifica en [Fru05b], Capítulo 4.
• cbc-essiv: hash : el cifrado se opera en modo ESSIV utilizando hash para generar la clave IV para la clave original. Por ejemplo, cuando se usa sha256 como hash, la especificación del modo de cifrado es "cbcessiv: sha256". ESSIV se especifica en [Fru05b], Capítulo 4.
• xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 es la versión de 64 bits del vector inicial simple

Tabla 3: especificaciones de hash válidas

• sha1 - RFC 3174 - Algoritmo de hash seguro de EE. UU. 1 (SHA1)
• sha256 - variante SHA según FIPS 180-2
• sha512 - variante SHA según FIPS 180-2
• ripemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html    (Ver más abajo)

Nota del editor: lo anterior se copia de la especificación. Después de su redacción, las URL de estos documentos han cambiado:

• Twofish: un cifrado de bloque de 128 bits    (nueva URL)
• La función hash RIPEMD-160    (nueva URL)

Puede enumerar los cifrados admitidos por sus núcleos con el siguiente comando,

[root@arif]# ls /lib/modules/[your kernel version]/kernel/crypto/
algif_rng.ko.xz   blowfish_common.ko.xz   cmac.ko.xz               cts.ko.xz          gf128mul.ko.xz           michael_mic.ko.xz  rsa_generic.ko.xz      tgr192.ko.xz           xts.ko.xz
ansi_cprng.ko.xz  blowfish_generic.ko.xz  crc32_generic.ko.xz      deflate.ko.xz      ghash-generic.ko.xz      pcbc.ko.xz         salsa20_generic.ko.xz  twofish_common.ko.xz   zlib.ko.xz
anubis.ko.xz      camellia_generic.ko.xz  crct10dif_common.ko.xz   des_generic.ko.xz  jitterentropy_rng.ko.xz  pcrypt.ko.xz       seed.ko.xz             twofish_generic.ko.xz
arc4.ko.xz        cast5_generic.ko.xz     crct10dif_generic.ko.xz  dh_generic.ko.xz   khazad.ko.xz             rmd128.ko.xz       serpent_generic.ko.xz  vmac.ko.xz
async_tx          cast6_generic.ko.xz     cryptd.ko.xz             drbg.ko.xz         lrw.ko.xz                rmd160.ko.xz       sha512_generic.ko.xz   wp512.ko.xz
authencesn.ko.xz  cast_common.ko.xz       crypto_null.ko.xz        fcrypt.ko.xz       mcryptd.ko.xz            rmd256.ko.xz       tcrypt.ko.xz           xcbc.ko.xz
authenc.ko.xz     ccm.ko.xz               crypto_user.ko.xz        gcm.ko.xz          md4.ko.xz                rmd320.ko.xz       tea.ko.xz              xor.ko.xz

Puede enumerar los cifrados y hash que puede usar y su comparación de E / S luksmediante el siguiente comando,

[root@arif arif]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       289342 iterations per second for 256-bit key
PBKDF2-sha256     353293 iterations per second for 256-bit key
PBKDF2-sha512     227555 iterations per second for 256-bit key
PBKDF2-ripemd160  233224 iterations per second for 256-bit key
PBKDF2-whirlpool  236165 iterations per second for 256-bit key
argon2i       4 iterations, 917485 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 951672 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       642.2 MiB/s      2495.8 MiB/s
    serpent-cbc        128b        89.3 MiB/s       542.6 MiB/s
    twofish-cbc        128b       100.4 MiB/s       343.1 MiB/s
        aes-cbc        256b       477.2 MiB/s      1979.2 MiB/s
    serpent-cbc        256b        89.3 MiB/s       538.9 MiB/s
    twofish-cbc        256b       173.3 MiB/s       343.1 MiB/s
        aes-xts        256b      1668.0 MiB/s      1664.1 MiB/s
    serpent-xts        256b       535.7 MiB/s       523.4 MiB/s
    twofish-xts        256b       332.6 MiB/s       339.8 MiB/s
        aes-xts        512b      1384.5 MiB/s      1380.7 MiB/s
    serpent-xts        512b       539.3 MiB/s       524.4 MiB/s
    twofish-xts        512b       335.0 MiB/s       340.1 MiB/s

Puede comparar cifrados específicos con el siguiente comando,

[root@arif]# ciphers="aes-xts serpent-xts anubis-xts"

[root@arif]# echo "#     Algorithm |       Key |      Encryption |      Decryption";for i in $ciphers ; do cryptsetup benchmark --cipher $i|tail -n 1; done

#     Algorithm |       Key |      Encryption |      Decryption
        aes-xts        256b      1613.9 MiB/s      1642.8 MiB/s
    serpent-xts        256b       538.9 MiB/s       521.9 MiB/s
     anubis-xts        256b       182.0 MiB/s       182.1 MiB/s

El núcleo 5.1, actual en el momento en que escribo esto, tiene dos formatos diferentes: cadena de cifrado, el formato "antiguo" y el formato "nuevo". Todo en esta pregunta hasta ahora, y aparentemente todos los documentos también, trata con el formato "antiguo", así que lo describiré aquí. Esto es solo para el cifrado. Si se usa integridad con dm-crypt, entonces uno debe considerar los cifrados AEAD y se vuelve aún más complicado.

El formato analizado por el núcleo es " cifrado [ :clave ] -modo -ivmode [ :ivopts ]". Ejemplos: aes-xts-plain64, blowfish-cbc-essiv:sha256, aes:64-cbc-lmk.

• cifrar el cifrado de uso, ejemplos sonaes,anubis,twofish,arc4, etc. El conductor dm-crypt núcleo no tiene una lista de sistemas de cifrado. Esto se pasa a través de la API de cifrado de Linux, por lo que se puede utilizar cualquier cifrado adecuado admitido por el núcleo.

• recuento de teclas Potencia opcional de dos números de claves para usar con cifrado. Este valor predeterminado es 1 para todo excepto el modolmkiv, donde el valor predeterminado es 64. Esto realmente solo se aplica a LMK y los valores que no sean 1 no funcionarán correctamente con otros modos.

• mode El modo de encadenamiento de bloques para usar con el cifrado. Ejemplos de ello sonecb,cbc,xts. Además de saber queecbno usa IV, el controlador md-crypt pasa esto a la API de cifrado de Linux y puede usar cualquier modo de encadenamiento compatible con el núcleo.

• ivmode El algoritmo utilizado para generar el vector de inicialización (IV) para cada sector. En el cifrado de clave simétrica típico, a diferencia de dm-crypt, el IV es otro bit de datos que se pasa al cifrado junto con la clave al cifrar o descifrar. Solo se pasa una IV para toda la operación. Dado que dm-crypt necesita poder leer y escribir cada sector individualmente, no cifra todo el disco como una sola operación. En cambio, hay un IV para cada sector. En lugar de pasar el IV como datos, aquí se especifica un algoritmo para crear los IV. Esto no es parte de la API de cifrado de Linux, ya que la generación de IV no se realiza mediante el cifrado, y losvalores ivmode permitidosse definen en el controlador dm-crypt. Son:

  • plain, plain64, plain64be, benbi Estos simplemente usan el número de sector, en diversos formatos, como el IV. Diseñado para modos de bloqueo como XTS que están diseñados para resistir ataques como marcas de agua cuando se usa un IV simple y predecible. plain64parece ser el más comúnmente recomendado.
  • nullIV siempre es cero. Para pruebas y compatibilidad con versiones anteriores, no debe usar esto.
  • lmk Compatible con el esquema de cifrado Loop-AES.
  • tcw Compatible con TrueCrypt.
  • essivUtiliza el número de sector cifrado con un hash de la clave. Indicado para modos, como CBC, que no son resistentes a varios ataques cuando se usa un IV simple plain64.

• ivopts El hash que se usará conessiv ivmode , ignorado para todos los demás modos.

Como caso especial, " cifrado-plain " o simplemente " cifrado " se interpretan como " cifrado-cbc-plain ". Otro caso especial es que el ecbmodo no tiene ivmode para especificar.

Cómo se relaciona esto con /proc/crypto

Con respecto a /proc/crypto, solo el cifrado y el modo son relevantes. dm-crypt con construye una especificación Crypto API del formulario " cifrado de modo " y solicita esto desde el núcleo. Esto es lo que uno debe buscar como un . Ejemplo:()/proc/cryptonameskcipher

name         : xts(aes)
driver       : xts-aes-aesni
module       : kernel
priority     : 401
refcnt       : 1
selftest     : passed
internal     : no
type         : skcipher
async        : yes
blocksize    : 16
min keysize  : 32
max keysize  : 64
ivsize       : 16
chunksize    : 16
walksize     : 16

El typede skcipherindica que xts(aes)se trata de un cifrado de clave simétrica, qué utiliza dm-crypt y el nombre de se escribiría aes-xtscuando se especifique con dm-crypt. Los keysizecampos también nos dicen qué tamaños de clave se pueden usar con este cifrado.

Si esto era de un módulo, el nombre del módulo podría aparecer en la modulelínea. Sin embargo, muchos cifrados (generalmente aquellos en software que no tienen ningún código específico de hardware) se implementan como un cifrado genérico que se combina con un código genérico de encadenamiento de bloques para producir el skcipher final. Por ejemplo:

name         : xts(anubis)
driver       : xts(ecb(anubis-generic))
module       : kernel
type         : skcipher

name         : anubis
driver       : anubis-generic
module       : anubis
type         : cipher

En este caso, el cifrado de anubis se combina con el código de modo de encadenamiento de bloques XTS del núcleo para producir el cifrado final xts(anbuis), al que se le ha asignado un módulo kernel. Pero para tener esto disponible, necesitamos el cifrado genérico Anubis, que es del anubismódulo. La mayoría de los cifrados tienen un alias de módulo de " crypto-cifrado " que se puede usar para cargarlos, por ejemplo modprobe crypto-anubis, cargarían el módulo que proporciona el cifrado anubis.

Cuando se usa el cryptsetup benchmarkcomando, solo importan el cifrado y el modo , ya que eso es todo lo que se compara. Si el modo no se especifica que los valores predeterminados de CBC. El ivmode es totalmente ignorado. Por lo tanto, para la evaluación comparativa, aes, aes-cbc, y aes-cbc-foobarson todas equivalentes.