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.
/lib/modules/*/kernel/crypto/est un endroit où chercher, mais les modules peuvent être n'importe où sur le système de fichiers.