Como determino quais cifras e modos de cifra posso usar no dm-crypt / LUKS?

Estou usando um sistema baseado no Ubuntu e estou tendo dificuldades para determinar quais cifras e modos de cifra estão disponíveis para mim.

A página do manual cryptsetup diz:

"Consulte / proc / crypto para obter uma lista de opções disponíveis. Pode ser necessário carregar módulos criptográficos adicionais do kernel para obter mais opções."

Meu / proc / crypto tem muito pouco. Como descubro quais módulos criptográficos extras do kernel estão disponíveis para carregar?

Existem muitos documentos e páginas de manual para ler, mas um documento que pode interessá-lo particularmente é a Especificação de formato em disco (PDF) da LUKS .

O Apêndice B (que está, naturalmente, perto do fim) diz:

Registro de especificação de cifra e hash

Mesmo que as seqüências de nome e modo de cifra não sejam interpretadas por nenhuma operação LUKS, elas devem ter o mesmo significado para todas as implementações para obter compatibilidade entre diferentes implementações baseadas em LUKS. O LUKS deve garantir que o sistema de cifra subjacente possa utilizar as seqüências de nome e modo de cifra e, como essas cadeias nem sempre podem ser nativas para o sistema de codificação, a LUKS pode precisar mapeá-las para algo apropriado.

Os nomes de cifras válidos estão listados na Tabela 1.

Os modos de cifra válidos estão listados na Tabela 2. Por contrato, os modos de cifra que usam IVs e ajustes devem começar a partir de IV / ajustes totalmente zero. Isso se aplica a todas as chamadas para as primitivas criptografar / descriptografar, especialmente ao manusear o material principal. Além disso, esses modos de cifra IVs / tweaks geralmente cortam o fluxo de cifra em blocos independentes, realimentando tweaks / IVs nos limites do setor. O requisito IV / tweak totalmente zero para o primeiro bloco criptografado / descriptografado é equivalente ao requisito de que o primeiro bloco seja definido para permanecer no setor 0.

A Tabela 3 lista especificações válidas de hash para o campo hash-spec . Uma implementação compatível não precisa oferecer suporte a todas as especificações de codificação, modo de codificação ou hash.

Tabela 1: Nomes de Cifras Válidos

• aes - Padrão Avançado de Criptografia - FIPS PUB 197
• twofish - Twofish: uma cifra de bloco de 128 bits - http://www.schneier.com/paper-twofish-paper.html     (veja abaixo)
• serpent - http://www.cl.cam.ac.uk/~rja14/serpent.html
• cast5 - RFC 2144
• cast6 - RFC 2612

Tabela 2: Modos de criptografia válidos

• ecb - A saída de cifra é usada diretamente
• cbc-plain - A cifra é operada no modo CBC. O encadeamento da CBC é cortado em todos os setores e reinicializado com o número do setor como vetor inicial (convertido em 32 bits e em little endian). Este modo é especificado em [Fru05b], capítulo 4.
• cbc-essiv: hash - A cifra é operada no modo ESSIV usando hash para gerar a chave IV para a chave original. Por exemplo, ao usar sha256 como hash, a especificação do modo de cifra é "cbcessiv: sha256". ESSIV é especificado em [Fru05b], capítulo 4.
• xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 é uma versão de 64 bits do vetor inicial simples

Tabela 3: Especificações de hash válidas

• sha1 - RFC 3174 - Algoritmo de hash seguro 1 dos EUA (SHA1)
• sha256 - Variante SHA de acordo com FIPS 180-2
• sha512 - Variante SHA de acordo com FIPS 180-2
• ripemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html    (veja abaixo)

Nota do Editor: O texto acima é copiado da especificação. Posteriormente à sua escrita, os URLs desses documentos foram alterados:

• Twofish: uma cifra de bloco de 128 bits    (nova URL)
• A função hash RIPEMD-160    (novo URL)

Você pode listar as cifras suportadas pelos seus kernels com o seguinte 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

Você pode listar as cifras e hashes que você pode usar e sua comparação de E / S por for lukspelo seguinte 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

Você pode comparar cifras específicas pelo seguinte 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

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 olmkivmode, 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 queecbnã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. plain64parece ser o mais recomendado.
  • nullIV é 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.
  • essivUsa 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 ecbmodo 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/cryptocomo o namepara 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 typede skcipherindica uma cifra de chave simétrica, o que o dm-crypt usa e o nome de xts(aes)seria escrito aes-xtsquando especificado com o dm-crypt. Os keysizecampos 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 modulelinha. 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 anubismó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 benchmarkcomando, 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-foobarsão todos equivalentes.