Bonjour,
Je recherche à chiffrer mon disque dur externe de 1 To mais je me pose quelques questions. Je suis sous Jessie KDE. Le disque sera un disque de sauvegarde.
Quel format de fichier choisir ?
Quel logiciel utiliser ? En CLI ou GUI, peu importe.
Quelle méthode de chiffrement utiliser ?
Quelle type de clé ? 128 ? 256 ? 1024 ? 4096 ?
Il faudrait qu’il soit assez simple à monter (phrase de passe, et voilà).
Si vous avez d’autres conseils, je suis preneur, merci pour votre attention.
Bonsoir,
Regardes du côté de cryptsetup - dm_crypt / LUKS
Bonjour,
J’ai trouvé ce tutoriel :
Tuto Cryptsetup / LUKS
Bon, c’est assez simple à faire, même si je n’ai pas pu choisir la taille du chiffrement (je fouillerai). Autre chose, sur un disque de 1To, j’imagine que cela va prendre très longtemps. Je détaillerai ici.
Si bien sûr, mais il faut passer des options à cryptsetup lors de la 1ere commande (cryptsetup luksFormat). Tu peux fouiller dans le man de cryptsetup. Ce tuto est simplifié.
Quelques exemples de lecture :
Qu’est-ce qui va prendre longtemps ?
dm-crypt ne chiffre pas le disque, mais les données qu’on y écrit.
Cela ne chiffre pas le contenu en clair existant.
Alors, ce qui prend du temps est l’écriture de zéros sur le disque dur, ou alors, de données aléatoires avec /dev/urandom comme le suggère le lien fourni par GOGI.
Il semblerait que l’écriture de données aléatoires soit davantage conseillée que l’écriture de zéros, du coup, j’ai annulé. J’avais une moyenne de 19,5 Mo/s en écriture.
Ce n’est pas terrible comme débit d’écriture, même en USB 2 high-speed. Forcément, à cette vitesse ça va prendre du temps de remplir 1 To.
Note que le débit de sortie de /dev/urandom peut être encore plus faible et devenir le facteur limitant.
L’écriture de zéros peut être plus rapide mais a l’inconvénient qu’on voit facilement quels sont les blocs vides (contenant des zéros) et le blocs chiffrés (contenant des données d’apparence pseudo-aléatoire). Cela facilite le travail d’un attaquant qui sait quels blocs il n’a pas besoin d’essayer de décrypter.
Une question me vient à l’esprit…
Vaut-il mieux remplir d’abord son DD avec /dev/urandom, puis crypter et/ou faire ses partitons? Ou bien crypter et/ou faire ses partitions, puis remplir chaque partition avec /dev/urandom?
Ou bien l’ordre des opérations n’a t-il aucune importance sur le résultat?
Bon, de toute façon, c’est pour de la sécurité basique : perte ou vol du disque dur externe. Je n’ai rien de très sensible, mais beaucoup de données personnelles.
D’ailleurs, le disque sera assez vite “rempli”. Je ne comprends pas trop en quoi c’est plus facile pour un attaquant de connaître le “contenu des blocs” ?
C’est de l’USB3, d’ailleurs.
Je pense qu’il n’y aura pas une grande différence dans le résultat. Ce sera juste un peu moins rapide de remplir le volume chiffré que la partition sous-jacente puisque la surcharge du chiffrement s’applique.
Par contre cela me donne une autre idée : remplir le volume chiffré avec /dev/zero. Sur ma (vieille) machine, c’est plus rapide (40 Mo/s) que le débit de /dev/urandom (5 Mo/s).
Si les blocs vides sont à zéro et si le disque est peu rempli, alors l’attaquant sait quels blocs sont remplis et peut se concentrer sur leur décryptage sans perdre de temps sur les blocs vides. En matière de décryptage, le temps est un facteur crucial : aucun chiffrement n’est inviolable si on a assez de puissance de calcul et de temps. En revanche une fois que tout le disque a été écrit, ça ne fait plus une grande différence.
Edit : à noter que ce problème se pose aussi avec la fonction TRIM (discard) qui permet d’optimiser les performances en écriture et la durée de vie des SSD. Si elle est utilisée avec un volume chiffré, alors là aussi un attaquant peut être capable de déterminer quels blocs sont vides et quels blocs sont occupés.
Le meilleur (je parle dans le cas où l’on recherche le meilleur résultat) serait d’utiliser une deuxième machine sur laquelle on branche le DD en question, puis d’utiliser un générateur d’entropie en combinaison avec /dev/random ou /dev/urandom?
Selon quel critère ? (comique de répétition)
Par rapport à ce qui est dit plus haut, le fait de remplir avec des données aléatoires plutot que des zéros renforce le niveau de sécurité en chiffrement face à une éventuelle attaque.
Bien entendu tu me diras tout dépend de ce que l’on a à cacher, en fonction de ça on optimisera la solution “fonction de coût” 
La fonction de coût n’est pas la solution, c’est la formule qui permet de comparer les solutions entre elles.
Si on ne veut pas que n’importe qui puisse ni savoir quelles parties du disque contient des information chiffrées ni récupérer les données qui étaient sur le disque avant qu’on ne crée de partition chiffrée, on a trois solutions (au moins).
On peut écrire des zéros à l’intérieur de la partition chiffrée (en supposant que l’algorithme de chiffrement est bon, mais pour luks, c’est bon par défaut) puisque les données réellement écrites sur le disque seront des zéros chiffrés donc pas des zéros 
… (Ça me semble être la meilleure solution.)
Une alternative est d’écrire des données aléatoires avant de chiffrer, a priori, c’est quasiment aussi sûr mais probablement plus lent (si c’est pas le cas, cette solution est également valide ; urandom ne peut pas fournir 1 To d’aléa de qualité en temps raisonnable sur une machine normale mais c’est pas un drame en général, tant qu’on ne parle pas de données extrêmement sensibles).
La dernière possibilité est d’écrire des données aléatoires dans la partition chiffrée. Ça semble juste plus lent pour un gain en principe nul (si l’algo de chiffrement n’est pas bon, ça peut avoir un vague intérêt, mais en général, on est suffisamment ennuyé par le fait que nos données puissent être lues pour ne plus se préoccuper du fait qu’in puisse savoir où il y a de l’espace vide 
).
Merci pour les explications.
Je commence à comprendre. Il y a-t-il un intérêt à chiffrer avec une clé supérieure à 128 bits ? Mes données ne sont que personnelles, rien de très sensible mais bien évidemment, je tiens quand même à les protéger.
Question inverse : une clé de grande taille présente-t-elle des inconvénients ?
Bon, je parviens à monter mes disques mais impossible d’écrire dessus, l’accès est refusé. À cause de l’ext4 ? 
Que se passe-t-il exactement ?
Je dois me connecter en root pour pouvoir créer des dossiers ou copier des fichiers, en fait. C’est un peu gênant. Il y a un dossier lost+found aussi. J’imagine que je n’ai qu’à autoriser tout le monde à y écrire, non ? Le disque sera utilisé sur plusieurs ordinateurs d’ailleurs.