Comment déterminer quels chiffrements et modes de chiffrement je peux utiliser dans dm-crypt / LUKS?

J'utilise un système basé sur Ubuntu, et j'ai du mal à déterminer quels chiffrements et modes de chiffrement sont à ma disposition.

La page de manuel de cryptsetup indique:

"Voir / proc / crypto pour une liste des options disponibles. Vous devrez peut-être charger des modules de chiffrement du noyau supplémentaires pour obtenir plus d'options."

Mon / proc / crypto en contient très peu. Comment savoir quels modules de chiffrement du noyau supplémentaires sont disponibles pour que je puisse les charger?

Il existe de très nombreux documents et pages de manuel à lire, mais un document qui pourrait vous intéresser particulièrement est la spécification de format sur disque LUKS (PDF).

L'annexe B (qui est, naturellement, près de la fin) dit:

Registre des spécifications de chiffrement et de hachage

Même si les chaînes de nom de chiffrement et de mode de chiffrement ne sont interprétées par aucune opération LUKS, elles doivent avoir la même signification pour toutes les implémentations pour assurer la compatibilité entre différentes implémentations basées sur LUKS. LUKS doit s'assurer que le système de chiffrement sous-jacent peut utiliser le nom de chiffrement et les chaînes de mode de chiffrement, et comme ces chaînes ne sont pas toujours natives du système de chiffrement, LUKS peut avoir besoin de les mapper en quelque chose de approprié.

Les noms de chiffrement valides sont répertoriés dans le tableau 1.

Les modes de chiffrement valides sont répertoriés dans le tableau 2. Par contrat, les modes de chiffrement utilisant des IV et des réglages doivent commencer à partir du IV / réglage tout à zéro. Cela s'applique à tous les appels aux primitives de chiffrement / déchiffrement, en particulier lors de la manipulation des éléments clés. En outre, ces modes de chiffrement IVs / Tweaks coupent généralement le flux de chiffrement en blocs indépendants en réensemencant les tweaks / IVs aux limites des secteurs. L'exigence IV / tweak tout à zéro pour le premier bloc chiffré / déchiffré équivaut à l'exigence que le premier bloc soit défini pour reposer au secteur 0.

Le tableau 3 répertorie les spécifications de hachage valides pour le champ de spécification de hachage . Une implémentation conforme ne doit pas prendre en charge toutes les spécifications de chiffrement, de mode de chiffrement ou de hachage.

Tableau 1: Noms de chiffrement valides

• aes - Advanced Encryption Standard - FIPS PUB 197
• twofish - Twofish: A 128-Bit Block Cipher - http://www.schneier.com/paper-twofish-paper.html     (voir ci-dessous)
• serpent - http://www.cl.cam.ac.uk/~rja14/serpent.html
• cast5 - RFC 2144
• cast6 - RFC 2612

Tableau 2: modes de chiffrement valides

• ecb - La sortie de chiffrement est utilisée directement
• cbc-plain - Le chiffrement fonctionne en mode CBC. Le chaînage CBC est coupé dans chaque secteur et réinitialisé avec le numéro de secteur comme vecteur initial (converti en 32 bits et en petit-boutien). Ce mode est spécifié dans [Fru05b], Chapitre 4.
• cbc-essiv: hash - Le chiffrement est exploité en mode ESSIV en utilisant le hachage pour générer la clé IV pour la clé d'origine. Par exemple, lorsque vous utilisez sha256 comme hachage, la spécification du mode de chiffrement est «cbcessiv: sha256». L'ESSIV est spécifié dans [Fru05b], Chapitre 4.
• xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 est une version 64 bits du vecteur initial brut

Tableau 3: Spécifications de hachage valides

• sha1 - RFC 3174 - US Secure Hash Algorithm 1 (SHA1)
• sha256 - Variante SHA selon FIPS 180-2
• sha512 - Variante SHA selon FIPS 180-2
• ripemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html    (voir ci-dessous)

Note de l'éditeur: ce qui précède est copié de la spécification. Suite à sa rédaction, les URL de ces documents ont changé:

• Twofish: un chiffrement à 128 bits    (nouvelle URL)
• La fonction de hachage RIPEMD-160    (nouvelle URL)

Vous pouvez répertorier les chiffres pris en charge par vos noyaux avec la commande suivante,

[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

Vous pouvez répertorier les chiffrements et hachages que vous pouvez utiliser et leur comparaison d'E / S pour lukspar la commande suivante,

[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

Vous pouvez comparer des chiffrements spécifiques à l'aide de la commande suivante,

[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

Le noyau 5.1, actuel au moment où j'écris ceci, a deux formats différents: la chaîne de chiffrement pour, "l'ancien" format et le "nouveau" format. Jusqu'à présent, tout dans cette question, et apparemment tous les documents, traitent de "l'ancien" format, je vais donc le décrire ici. C'est juste pour le cryptage. Si vous utilisez l'intégrité avec dm-crypt, alors il faut considérer les chiffrements AEAD et cela devient encore plus compliqué.

Le format analysé par le noyau est " chiffrement [ :keycount ] -Mode -ivmode [ :ivopts ]". Exemples: aes-xts-plain64, blowfish-cbc-essiv:sha256, aes:64-cbc-lmk.

• chiffrer Le chiffrement àutilisation,exemples sontaes,anubis,twofish,arc4, etc. Le noyau pilote dm-crypt ne dispose pasune liste de chiffrements. Ceci est transmis à l'API Linux Crypto, donc tout chiffrement approprié pris en charge par le noyau peut être utilisé.

• keycount Puissance optionnelle de deux nombres de clés à utiliser avec le chiffrement. Cette valeur par défaut est 1 pour tout sauf le modelmkiv, où il est par défaut 64. Cela ne s'applique vraiment qu'à LMK et les valeurs autres que 1 ne fonctionneront pas correctement avec d'autres modes.

• mode Mode de chaînage de blocs à utiliser avec le chiffrement. Les exemples sontecb,cbc,xts. En plus de savoir qu'ilecbn'utilise pas d'IV, le pilote md-crypt le transmet à l'API Linux Crypto et peut utiliser n'importe quel mode de chaînage pris en charge par le noyau.

• ivmode L'algorithme utilisé pour générer le vecteur d'initialisation (IV) pour chaque secteur. Dans le chiffrement à clé symétrique typique, contrairement à dm-crypt, l'IV est un autre bit de données transmis au chiffrement avec la clé lors du chiffrement ou du déchiffrement. Il n'y a qu'un seul IV passé pour toute l'opération. Étant donné que dm-crypt doit pouvoir lire et écrire chaque secteur individuellement, il ne crypte pas le disque entier en une seule opération. Au lieu de cela, il y a une IV pour chaque secteur. Plutôt que de transmettre l'IV en tant que données, un algorithme pour créer les IV est spécifié ici. Cela ne fait pas partie de l'API Linux Crypto, car la génération IV n'est pas effectuée par le chiffrement, et lesvaleurs ivmode autoriséessont définies par le pilote dm-crypt. Elles sont:

  • plain, plain64, plain64be, benbi Ceux - ci utilisent simplement le numéro du secteur, dans différents formats, comme IV. Conçu pour les modes de bloc comme XTS qui sont conçus pour résister aux attaques comme le filigrane lors de l'utilisation d'un IV simple et prévisible. plain64semble être le plus recommandé.
  • nullIV est toujours nul. Pour les tests et la compatibilité descendante, vous ne devriez pas utiliser cela.
  • lmk Compatible avec le schéma de cryptage Loop-AES.
  • tcw Compatible avec TrueCrypt.
  • essivUtilise le numéro de secteur chiffré avec un hachage de la clé. Destiné aux modes, comme CBC, qui ne résistent pas à diverses attaques lors de l'utilisation d'un simple IV comme plain64.

• ivopts Le hachage à utiliser avecessiv ivmode , ignoré pour tous les autres modes.

Dans un cas particulier, « chiffrement-plain » ou simplement « chiffrement » sont interprétés comme « chiffrement-cbc-plain ». Un autre cas particulier est que le ecbmode n'a pas de mode iv à spécifier.

Comment cela se rapporte /proc/crypto

En ce qui concerne /proc/crypto, seuls le chiffrement et le mode sont pertinents. dm-crypt avec construction d'une spécification API Crypto de la forme " chiffrement de mode " et demande cela au noyau. C'est ce que l'on doit rechercher en tant que pour a . Exemple:()/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

Le typeof skcipherindique qu'il s'agit d'un chiffrement à clé symétrique, de ce que dm-crypt utilise et le nom de xts(aes)serait écrit aes-xtslorsqu'il est spécifié avec dm-crypt. Les keysizechamps nous indiquent également quelles tailles de clés peuvent être utilisées avec ce chiffrement.

S'il s'agissait d'un module, le nom du module pourrait apparaître dans la moduleligne. Cependant, de nombreux chiffrements (généralement ceux des logiciels qui n'ont pas de code spécifique au matériel) sont implémentés comme un chiffrement générique qui est combiné avec un code de chaînage de blocs générique pour produire le chiffrement final. Par exemple:

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

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

Dans ce cas, le chiffrement anubis est combiné avec le code du mode de chaînage de blocs XTS du noyau pour produire le chiffrement final xts(anbuis), auquel un module de kernel. Mais pour que cela soit disponible, nous avons besoin du chiffrement générique anubis, qui provient du anubismodule. La plupart des chiffrements ont un alias de module de " crypto-chiffrement " qui peut être utilisé pour les charger, par exemple modprobe crypto-anubis, chargerait le module qui fournit le chiffrement anubis.

Lorsque vous utilisez la cryptsetup benchmarkcommande, seul le chiffrement et le mode importent, car c'est tout ce qui est comparé. Si le mode n'est pas spécifié, il s'agit par défaut de CBC. Le mode iv est totalement ignoré. Ainsi, pour l' analyse comparative, aes, aes-cbcet aes-cbc-foobarsont tous équivalents.