J'ai décidé de crypter ma partition racine avec LUKS + LVM.
Ma configuration ThinkPad:
- Samsung 830 128GB SSD
- Disque dur de 750 Go
- Core 2 Duo 2,5 GHz P9500
- 8 Go de RAM
Mais plus je lis, moins je comprends les deux sujets suivants:
1a. Le chiffre
J'allais utiliser SHA1 au lieu de 2/512 (comme certains le suggèrent), à cause de cette citation de la cryptsetupFAQ:
5.20 LUKS est cassé! Il utilise SHA-1!
Non, ça ne l'est pas. SHA-1 est (académiquement) rompu pour trouver des collisions, mais pas pour l'utiliser dans une fonction de dérivation de clé. Et cette vulnérabilité de collision est réservée à un usage non itéré. Et vous avez besoin de la valeur de hachage in extenso.
Cela signifie essentiellement que si vous avez déjà une clé d'emplacement et que vous avez défini le nombre d'itérations PBKDF2 sur 1 (il est> 10'000 normalement), vous pouvez (peut-être) dériver une phrase de passe différente qui vous donne le même emplacement- clé. Mais si vous avez la clé, vous pouvez déjà déverrouiller la clé et obtenir la clé principale, tout casser. Donc, fondamentalement, cette vulnérabilité SHA-1 vous permet d'ouvrir un conteneur LUKS avec un effort élevé lorsque vous l'avez déjà ouvert.
Le vrai problème ici est que les gens ne comprennent pas la crypto et prétendent que les choses sont cassées simplement parce qu'un mécanisme est utilisé qui a été cassé pour une utilisation différente spécifique. La façon dont le mécanisme est utilisé est très importante. Un hachage qui est cassé pour une utilisation peut être complètement sécurisé pour d'autres utilisations et le voici.
Ce que je lis comme "il n'y a aucun intérêt à utiliser autre chose que SHA-1". Mais alors certaines personnes me disent que ce n'est pas exactement comme ça. Donc je ne sais plus quoi penser.
1b.
De plus, je n'ai pu trouver aucune information indiquant si le chiffrement a une influence sur les performances de lecture / écriture / recherche du disque une fois le disque déverrouillé et le système connecté.
La complexité du chiffrement n'affecte-t-elle donc que les "performances" à l'étape de la saisie du mot de passe, ou également lors d'une utilisation normale du système?
2. L'algorithme
Je lis à ce sujet depuis quelques jours, mais plus je lis, plus je suis confus. Tout ce que j'ai lu dit que l'AES est le plus rapide et que Serpent est le plus lent. Mais pas selon mon portable:
$ cryptsetup benchmark
Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 344926 iterations per second
PBKDF2-sha256 198593 iterations per second
PBKDF2-sha512 129007 iterations per second
PBKDF2-ripemd160 271933 iterations per second
PBKDF2-whirlpool 134295 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 149.8 MiB/s 147.9 MiB/s
serpent-cbc 128b 51.0 MiB/s 196.4 MiB/s
twofish-cbc 128b 127.6 MiB/s 152.5 MiB/s
aes-cbc 256b 114.3 MiB/s 113.8 MiB/s
serpent-cbc 256b 51.2 MiB/s 198.9 MiB/s
twofish-cbc 256b 129.8 MiB/s 167.5 MiB/s
aes-xts 256b 153.3 MiB/s 150.6 MiB/s
serpent-xts 256b 176.4 MiB/s 184.1 MiB/s
twofish-xts 256b 160.8 MiB/s 159.8 MiB/s
aes-xts 512b 115.4 MiB/s 112.1 MiB/s
serpent-xts 512b 178.6 MiB/s 184.2 MiB/s
twofish-xts 512b 160.7 MiB/s 158.9 MiB/s
Il semble donc que Serpent n'est pas seulement le plus rapide, mais en plus c'est le plus rapide avec la clé la plus complexe.
Cela ne devrait-il pas être l'inverse? Suis-je en train de mal lire, ou quelque chose?