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 modolmk
iv, 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 queecb
no 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. plain64
parece ser el más comúnmente recomendado.
null
IV 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.
essiv
Utiliza 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 ecb
modo 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/crypto
name
skcipher
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 type
de skcipher
indica que xts(aes)
se trata de un cifrado de clave simétrica, qué utiliza dm-crypt y el nombre de se escribiría aes-xts
cuando se especifique con dm-crypt. Los keysize
campos 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 module
lí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 anubis
mó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 benchmark
comando, 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-foobar
son todas equivalentes.
/lib/modules/*/kernel/crypto/
es un lugar probable para buscar, pero los módulos pueden estar en cualquier parte del sistema de archivos.