Pour LUKS: le chiffre le plus préférable et le plus sûr?
Je suis sur le point de chiffrer deux de mes disques durs en utilisant LUKS, car je ne peux pas vraiment le faire moi-même. J'utilise le guide sur le wiki Arch Linux (qui peut être trouvé ici) . Dans un exemple du guide, le chiffre spécifié est aes-xts-plain avec une taille de clé de 512 bits. Est aes-xts-plain le meilleur choix ou existe-t-il un meilleur chiffrement à utiliser? Je préfère la sécurité à la vitesse.
Il y a trois composants que vous devez comprendre dans toute utilisation de chiffrement par bloc et ils s'appliquent explicitement ici:
- La primitive de chiffrement par blocs. Cela pourrait être l'un de vos chiffres familiers, candidats AES tels que, bien, AES, Serpent, Twofish, Blowfish, ...
- Le mode de fonctionnement. En utilisant un chiffrement par blocs tel quel, bloc par bloc est appelé livre de codes électronique, mais il existe d'autres modes tels que l'enchaînement de blocs de chiffrement et le mode compteur, avec leurs divers avantages et inconvénients.
- Le schéma de génération de vecteur d'initialisation, tel que essiv qui combat les différentes techniques d'empreintes digitales disponibles pour les attaquants contre CBC utilisé pour le chiffrement de disque.
Ainsi, lorsque vous choisissez une option, par exemple aes-cbc-essiv, vous demandez en fait AES, utilisé en mode CBC avec des IV chiffrés basés sur un identifiant par bloc, tandis que aes-xts-plain utilise AES en mode XTS avec d'anciens IV simples générés à partir de certaines informations par bloc.
Cela revient à savoir si vous avez confiance que XTS a une résistance suffisante au blanchiment (que l'ESSIV combat) intégré au mode de cryptage. À ce stade, XTS est un mode plus moderne avec plus d'avantages techniques, mais a subi moins de tests cryptographiques que CBC.
Un point à noter avec XTS, de wikipedia:
En raison de la division, les utilisateurs souhaitant un cryptage AES 256 et AES 128 devront choisir des tailles de clé de 512 bits et 256 bits respectivement.
Il faut choisir avec soin de générer des tailles de clé avec ce mode de sorte que chaque bloc utilise une clé de la taille de bit souhaitée. Je n'ai pas regardé les informations LUKS pour voir comment, ou cryptsetup, divisent ses clés; c'est peut-être quelque chose que vous souhaitez faire pour vous assurer d'avoir le bon niveau de sécurité que vous désirez. En tant que tel, selon votre guide, le cryptage 256 bits a été utilisé par bloc (avec la clé 512 divisée en deux parties).
Comme mentionné sur votre message d'origine sur SU, pour la plupart des cas, le niveau de sécurité requis devrait être suffisant pour qu'un attaquant n'ait aucune chance raisonnable de le casser dans un délai utile (par exemple pour vos données personnelles, vous voudrez peut-être que ce soit un 10 année).
Donc, dans cet exemple, en supposant que vous n'avez pas de secrets nationaux ou de données d'entreprise sensibles sur votre PC, AES-XTS-PLAIN devrait être résistant pendant un délai raisonnable contre un attaquant.
Le chiffre le plus préférable est aes-xts-plain64 et il est utilisé dans toute la distribution (RedHat, CentOS, Oracle Linux, Ubuntu) par défaut. La plupart des gens utilisent aes car une grande partie de l'appliance et des applications la prennent en charge et les performances de aes peuvent être accélérées sur Processeur Intel . Et ce type de fonction d'accélération donne à aes beaucoup d'avantages sur les autres chiffres. Vous pouvez lire la comparaison des performances entre simple implementation of aes contre hardware accelerated aesici . Et une chose la mention, si vous utilisez aes il y a un autre avantage qu'il est largement utilisé, donc s'il y a une attaque disponible sur Internet, vous le saurez rapidement et vous obtiendrez probablement une mise à jour rapidement. Et il y a quelques attaques passives disponibles sur l'implémentation de aes comme cryptage de disque que vous pouvez lire ici
Mais votre choix peut être différent. Et tout en choisissant le chiffre, vous devez simplement vous assurer que le chiffre que vous choisissez n'est pas encore compromis. Vous pouvez le vérifier depuis ici . Il existe d'autres algorithmes similaires disponibles qui ne sont pas efficaces (du point de vue des E/S) comme aes mais de bonnes alternatives. Si vous ne prévoyez pas d'utiliser aes, il y a deux successeurs de aes qui sont sécurisé queaes est Anubis = et serpent car vous pouvez sacrifier la vitesse pour la sécurité. Heureusement, vous pouvez les utiliser dans luks. Et si vous voulez protéger le secret de la nation, aes suffit, je suppose que aes est préféré dans FISMA et NIST-Special-Publication-800-53- Révision-4 .
Avec l'algorithme de chiffrement, vous devriez être sérieux à propos de l'algorithme de hachage à mon avis. Si vous utilisez un hachage faible, votre algorithme super sécurisé ne vous aidera pas beaucoup. Parce que le hachage joue un rôle essentiel dans le processus de cryptage luks. Vous ne devez donc pas utiliser sha1 mais sha512 est suffisamment sécurisé. Mais vous pouvez également utiliser whirepool ou le gagnant du récent concours de hachage de mot de passe argon2i .
De mon autre réponse à propos de Luks,
Vous pouvez répertorier les chiffres pris en charge par vos noyaux avec la commande suivante,
[root@arif]# ls /lib/modules/$(uname -r)/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 chiffres et les hachages que vous pouvez utiliser et leur comparaison d'E/S pour luks à l'aide de 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