O kernel 5.1, atual no momento em que escrevo isso, tem dois formatos diferentes, a string for cipher, o formato "antigo" e o formato "novo". Tudo nesta pergunta até agora, e aparentemente todos os documentos também, lida com o formato "antigo", então vou descrevê-lo aqui. Isso é apenas para criptografia. Se estiver usando integridade com o dm-crypt, é preciso considerar as cifras do AEAD e isso fica ainda mais complicado.
O formato analisado pelo kernel é " cipher [ :
keycount ] -
modo -
ivmode [ :
ivopts ]". Exemplos: aes-xts-plain64
, blowfish-cbc-essiv:sha256
, aes:64-cbc-lmk
.
cifra
A cifra de uso, os exemplos sãoaes
,anubis
,twofish
,arc4
, etc. O motorista dm-crypt do kernel não tem uma lista de cifras. Isso é passado para a API do Linux Crypto, para que qualquer cifra adequada suportada pelo kernel possa ser usada.
keycount
de alimentação opcional de dois número de teclas para usar com cifra. O padrão é 1 para tudo, exceto olmk
ivmode, onde o padrão é 64. Isso realmente se aplica apenas ao LMK e valores diferentes de 1 não funcionarão corretamente com outros modos.
mode O modo de encadeamento de blocos a ser usado com a cifra. Exemplos sãoecb
,cbc
,xts
. Além de saber queecb
não usa IV, o driver md-crypt passa isso para a API Linux Crypto e pode usar qualquer modo de encadeamento suportado pelo kernel.
ivmode O algoritmo usado para gerar o vetor de inicialização (IV) para cada setor. Na criptografia de chave simétrica típica, diferentemente do dm-crypt, o IV é outro bit de dados transmitidos para a cifra junto com a chave ao criptografar ou descriptografar. Há apenas um IV passado para toda a operação. Como o dm-crypt precisa poder ler e gravar cada setor individualmente, ele não criptografa o disco inteiro como uma única operação. Em vez disso, há um IV para cada setor. Em vez de passar o IV como dados, um algoritmo para criar os IVs é especificado aqui. Isso não faz parte da API Linux Crypto, uma vez que a geração IV não é feita pela cifra, e osvalores ivmode permitidossão definidos como o driver dm-crypt. Eles são:
plain
, plain64
, plain64be
, benbi
Estes simplesmente usar o número do setor, em vários formatos, como o IV. Destinado a modos de bloco como o XTS, projetados para resistir a ataques como marcas d'água ao usar um IV simples e previsível. plain64
parece ser o mais recomendado.
null
IV é sempre zero. Para teste e compatibilidade com versões anteriores, você não deve usar isso.
lmk
Compatível com o esquema de criptografia Loop-AES.
tcw
Compatível com TrueCrypt.
essiv
Usa o número do setor criptografado com um hash da chave. Destinado a modos, como o CBC, que não são resistentes a vários ataques ao usar um simples IV plain64
.
ivopts O hash a ser usado comessiv
ivmode , ignorado para todos os outros modos.
Como um caso especial, " cifrar-plain
" ou apenas " cifrar " são interpretados como " cifrar-cbc-plain
". Outro caso especial é que o ecb
modo não possui ivmode para especificar.
Como isso se relaciona com /proc/crypto
Com relação a /proc/crypto
, apenas a cifra e o modo são relevantes. O dm-crypt constrói uma especificação da API Crypto no formato " mode (
cipher)
" e solicita isso ao kernel. Isto é o que se deve procurar /proc/crypto
como o name
para a skcipher
. Exemplo:
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
O type
de skcipher
indica uma cifra de chave simétrica, o que o dm-crypt usa e o nome de xts(aes)
seria escrito aes-xts
quando especificado com o dm-crypt. Os keysize
campos também nos dizem quais tamanhos de chave podem ser usados com essa cifra.
Se for de um módulo, o nome do módulo poderá aparecer na module
linha. No entanto, muitas cifras (geralmente as de software que não possuem nenhum código específico de hardware) são implementadas como uma cifra genérica combinada com o código genérico de encadeamento de blocos para produzir a skcipher final. Por exemplo:
name : xts(anubis)
driver : xts(ecb(anubis-generic))
module : kernel
type : skcipher
name : anubis
driver : anubis-generic
module : anubis
type : cipher
Nesse caso, a cifra anubis é combinada com o código do modo de encadeamento do bloco XTS do kernel para produzir a cifra final xts(anbuis)
, à qual foi atribuído um módulo de kernel
. Mas, para disponibilizá-lo, precisamos da cifra anubis genérica, que é do anubis
módulo. A maioria das cifras possui um apelido de módulo de " crypto-
cifra " que pode ser usado para carregá-las, por exemplo modprobe crypto-anubis
, carregaria o módulo que fornece a cifra de anubis.
Ao usar o cryptsetup benchmark
comando, apenas a cifra e o modo são importantes, pois é tudo o que é comparado. Se o modo não for especificado, o padrão é CBC. O ivmode é totalmente ignorado. Assim, para aferir, aes
, aes-cbc
, e aes-cbc-foobar
são todos equivalentes.
/lib/modules/*/kernel/crypto/
é um local provável para procurar, mas os módulos podem estar em qualquer lugar do sistema de arquivos.